From munna.hadoop at gmail.com Sun Mar 1 04:03:19 2015 From: munna.hadoop at gmail.com (Hadoop Solutions) Date: Sun, 1 Mar 2015 12:03:19 +0800 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: References: <54F1360B.2080807@redhat.com> <54F15D9E.10806@redhat.com> Message-ID: Hi, IPA required SELinux enabled on the system? Thanks, Shaik On 28 February 2015 at 16:49, Hadoop Solutions wrote: > 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 umarzuki at gmail.com Sun Mar 1 13:56:49 2015 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Sun, 1 Mar 2015 21:56:49 +0800 Subject: [Freeipa-users] Failed to start Identity, Policy, Audit Message-ID: After rebooting freeipa server, I cannot log in to its web interface and when I try to start it, it failed More info: [root at ipa ~]# systemctl start ipa.service Job for ipa.service failed. See 'systemctl status ipa.service' and 'journalctl -n' for details. [root at ipa ~]# systemctl status ipa.service ipa.service - Identity, Policy, Audit Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled) Active: failed (Result: exit-code) since Sun, 2015-03-01 21:36:49 MYT; 15s ago Process: 1918 ExecStart=/usr/sbin/ipactl start (code=exited, status=1/FAILURE) CGroup: name=systemd:/system/ipa.service Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Aborting ipactl Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting Directory Service Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting krb5kdc Service Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting kadmin Service Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting ipa_memcached Service Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting httpd Service Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting pki-tomcatd Service Mar 01 21:36:49 ipa.domain.com systemd[1]: ipa.service: main process exited, code=exited, status=1/FAILURE Mar 01 21:36:49 ipa.domain.com systemd[1]: Failed to start Identity, Policy, Audit. Mar 01 21:36:49 ipa.domain.com systemd[1]: Unit ipa.service entered failed state [root at ipa ~]# KRB5_TRACE=/dev/stdout kinit admin [2324] 1425217336.627346: Getting initial credentials for admin at domain.com [2324] 1425217336.630877: Sending request (155 bytes) to domain.com [2324] 1425217336.631163: Sending initial UDP request to dgram 192.168.1.100:88 [2324] 1425217336.631265: UDP error receiving from dgram 192.168.1.100:88: 111/Connection refused [2324] 1425217336.631301: Initiating TCP connection to stream 192.168.1.100:88 [2324] 1425217336.631351: Terminating TCP connection to stream 192.168.1.100:88 kinit: Cannot contact any KDC for realm 'domain.com' while getting initial credentials [root at ipa ~]# rpm -qa | grep ipa freeipa-admintools-3.1.0-2.fc18.x86_64 freeipa-server-3.1.0-2.fc18.x86_64 libipa_hbac-python-1.9.3-1.fc18.x86_64 python-iniparse-0.4-6.fc18.noarch freeipa-client-3.1.0-2.fc18.x86_64 freeipa-server-selinux-3.1.0-2.fc18.x86_64 freeipa-python-3.1.0-2.fc18.x86_64 libipa_hbac-1.9.3-1.fc18.x86_64 What is my next course of action to solve this? From umarzuki at gmail.com Sun Mar 1 14:59:40 2015 From: umarzuki at gmail.com (Umarzuki Mochlis) Date: Sun, 1 Mar 2015 22:59:40 +0800 Subject: [Freeipa-users] Failed to start Identity, Policy, Audit In-Reply-To: References: Message-ID: When I checked at /var/log/dirsrv/slapd-DOMAIN-COM/errors [root at ipa ~]# tail -20 /var/log/dirsrv/slapd-DOMAIN-COM/errors [01/Mar/2015:21:36:00 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas online, retrying in 20 seconds... [01/Mar/2015:21:36:00 +0800] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [01/Mar/2015:21:36:00 +0800] NSMMReplicationPlugin - agmt="cn=meToiparepl.domain.com" (ipakl:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) ((null)) [01/Mar/2015:21:36:00 +0800] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [01/Mar/2015:21:36:00 +0800] NSMMReplicationPlugin - agmt="cn=meToiparepl.domain.com" (ipakl:389): Replication bind with SIMPLE auth failed: LDAP error -1 (Can't contact LDAP server) ((null)) [01/Mar/2015:21:36:00 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Replica not online (agmt="cn=meToiparepl.domain.com" (ipakl:389)) [01/Mar/2015:21:36:00 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas online, retrying in 20 seconds... [01/Mar/2015:21:36:00 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Replica not online (agmt="cn=meToiparepl.domain.com" (ipakl:389)) [01/Mar/2015:21:36:00 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Not all replicas online, retrying in 20 seconds... [01/Mar/2015:21:36:14 +0800] - slapd shutting down - signaling operation threads [01/Mar/2015:21:36:14 +0800] - slapd shutting down - waiting for 29 threads to terminate [01/Mar/2015:21:36:14 +0800] - slapd shutting down - closing down internal subsystems and plugins [01/Mar/2015:21:36:20 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Server shutting down. Process will resume at server startup [01/Mar/2015:21:36:20 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Server shutting down. Process will resume at server startup [01/Mar/2015:21:36:20 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Server shutting down. Process will resume at server startup [01/Mar/2015:21:36:20 +0800] NSMMReplicationPlugin - CleanAllRUV Task: Server shutting down. Process will resume at server startup [01/Mar/2015:21:36:47 +0800] slapi_ldap_bind - Error: could not send startTLS request: error -1 (Can't contact LDAP server) errno 107 (Transport endpoint is not connected) [01/Mar/2015:21:36:47 +0800] - Waiting for 4 database threads to stop [01/Mar/2015:21:36:48 +0800] - All database threads now stopped [01/Mar/2015:21:36:48 +0800] - slapd stopped. How do I suppose to bring up replica when master itself could not be started? 2015-03-01 21:56 GMT+08:00 Umarzuki Mochlis : > After rebooting freeipa server, I cannot log in to its web interface > and when I try to start it, it failed > From dpal at redhat.com Mon Mar 2 02:40:26 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 01 Mar 2015 21:40:26 -0500 Subject: [Freeipa-users] Fwd: 2-Factor and services In-Reply-To: References: <54EF99A9.1070701@redhat.com> Message-ID: <54F3CD9A.4080309@redhat.com> On 02/27/2015 11:37 AM, Matt Wells wrote: > 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 Mac and Windows you would not get SSO anyways because Kerberos on thos platforms does not support latest RFCs related to 2FA at least yet and since they are proprietary it is unclear what their plans are. The problem we also have is that there is no way to be selective on the KDC/DS side - there is no way to determine what the client is and associate some policies to it. It would have to be the client that would have to have capability to enforce or not enforce 2FA if the server supports both. But again that means that Mac and Windows would have to keep up with this capability. Bottom line it is a popular request but it is unclear how we can satisfy it. > > > 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 > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mlasevich at gmail.com Mon Mar 2 06:19:52 2015 From: mlasevich at gmail.com (Michael Lasevich) Date: Sun, 1 Mar 2015 22:19:52 -0800 Subject: [Freeipa-users] Fwd: 2-Factor and services In-Reply-To: <54F3CD9A.4080309@redhat.com> References: <54EF99A9.1070701@redhat.com> <54F3CD9A.4080309@redhat.com> Message-ID: There is actually a way to achieve what you most likely want to but not what you are asking for. I do not think there is currently a way to force 2fa based on service or host being authenticated - it is all or nothing. However, if all you want is ability to use 2fa against FreeIPA for OpenVPN authentication and use just password everywhere else - that is actually possible. This is how I achieved this - may not be an ideal setup but it works. As suggested, set up users to support both 2fa and password authentication. Forget about using PAM for OpenVPN authentication - instead use a plug-in script with credentials passed using via-env. You can write the plugin in any language you want (I used Python) and your logic should be something along the lines of: Parse password to separate OTP token from password. Use LDAP to authenticate with just password and then again with password AND OTP token. LDAP authentication happens on the IPA server and will support both methods. Authenticating twice is important to guarantee you do not have a smart-alec user who sets their password to end in 6 digits instead of actually enabling 2fa. Once you have successful authentication, you can use it to perform additional verifications - like checking membership(or lack thereof) in specific group, etc., etc. So, here is something else to think about. You may not want to allow the same accounts access to VPN and to the internal network. There is a reason why this is generally considered a bad practice. If someone, by some means (say another heartbleed-like exploit or some MITM attack or by gaining root access to the VPN serve) gains access to your user's VPN login credentials - the last thing you want is them having a full run of the network using those exact same credentials. Ideally it would be nice if 2fa "pin" (the non OTP portion of the 2fa) would be DIFFERENT from the password on the same account, but FreeIPA does not support that - at least not at this time. So what I would recommend is using a completely separate account in FreeIPA for VPN access. You can standardize this by using a standard prefix (so that for example user "username" would have an "ext-username" account for 2fa use with external authentication) - "ext" account would have no permissions to any data or internal login, just to access the network from outside and the main account would have no external access. To hack you, someone would then need to hack your OpenVPN box and then would still need to hack your internal authentication - which should be encrypted by TLS/SSH even over the VPN. You can also add the prefix automatically behind the scenes with the OpenVPN authentication script, as well as have the script only allow access for accounts that have no other privileges besides external access. Something to think about. HTH, -M On Sun, Mar 1, 2015 at 6:40 PM, Dmitri Pal wrote: > On 02/27/2015 11:37 AM, Matt Wells wrote: > >> 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 Mac and Windows you would not get SSO anyways because Kerberos on thos > platforms does not support latest RFCs related to 2FA at least yet and > since they are proprietary it is unclear what their plans are. > > The problem we also have is that there is no way to be selective on the > KDC/DS side - there is no way to determine what the client is and associate > some policies to it. > It would have to be the client that would have to have capability to > enforce or not enforce 2FA if the server supports both. But again that > means that Mac and Windows would have to keep up with this capability. > > Bottom line it is a popular request but it is unclear how we can satisfy > it. > > > >> >> 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 >>> >> >> >> > > -- > 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 pspacek at redhat.com Mon Mar 2 07:41:33 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Mar 2015 08:41:33 +0100 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <1425067497.9346.8.camel@willson.usersys.redhat.com> References: <54F0B548.8050902@ast.cam.ac.uk> <1425062007.9346.6.camel@willson.usersys.redhat.com> <54F0BE7E.4000001@ast.cam.ac.uk> <1425067497.9346.8.camel@willson.usersys.redhat.com> Message-ID: <54F4142D.7040601@redhat.com> On 27.2.2015 21:04, Simo Sorce wrote: > 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. Let me clarify it: FreeIPA can manage DNS for you, which is easy thing to do if your corporate policy allows that. start with $ ipa-dns-install and then add NS and glue records to the parent zones to have proper delegation to FreeIPA DNS servers. DNS auto-management makes adding hosts and replicas easier but it is not required in any way. If you do not want to manage DNS in FreeIPA you do no have to. For aliases, ask your DNS admin to use CNAME records to create aliases for the canonical host name (used in ipa host-add command). Have a nice day! -- Petr^2 Spacek From pspacek at redhat.com Mon Mar 2 07:44:06 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Mar 2015 08:44:06 +0100 Subject: [Freeipa-users] Using Domain Names In-Reply-To: <54F1371D.6090703@redhat.com> References: <54F1371D.6090703@redhat.com> Message-ID: <54F414C6.5070609@redhat.com> On 28.2.2015 04:33, Rob Crittenden wrote: > 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. I would use stronger words: *Never ever* use conflicting DNS names, just create new sub-domain. Conflicts are hard to manage and it will most likely blow up in your face when DNSSEC validation is enabled (some day in the future). -- Petr^2 Spacek From jhrozek at redhat.com Mon Mar 2 09:12:39 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 2 Mar 2015 10:12:39 +0100 Subject: [Freeipa-users] issues with secondary groups? (sssd) In-Reply-To: <54F211E8.9090407@gmail.com> References: <54F211E8.9090407@gmail.com> Message-ID: <20150302091239.GR9792@hendrix.redhat.com> On Sat, Feb 28, 2015 at 11:07:20AM -0800, Janelle wrote: > 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 Was the client installed with ipa-client-install? There I would suggest to just use the defaults and everything should work. Can you try again, this time with default configuration of id_provider=ipa ? You might need to clear the cache (rm /var/lib/sss/db/cache_*) if you were playing around with the schema.. From janellenicole80 at gmail.com Mon Mar 2 12:09:34 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 2 Mar 2015 04:09:34 -0800 Subject: [Freeipa-users] issues with secondary groups? (sssd) In-Reply-To: <20150302091239.GR9792@hendrix.redhat.com> References: <54F211E8.9090407@gmail.com> <20150302091239.GR9792@hendrix.redhat.com> Message-ID: <6E96473E-CEE7-4983-B38E-F907F5A6735B@gmail.com> That was the point. The clients were not installed with IPA client install. I have 2000 clients and still working on a simple way to automate the client install with ansible or puppet. Currently just trying to get it working with simple sssd/ldap only auth. ~J > On Mar 2, 2015, at 01:12, Jakub Hrozek wrote: > >> On Sat, Feb 28, 2015 at 11:07:20AM -0800, Janelle wrote: >> 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 > > Was the client installed with ipa-client-install? There I would suggest > to just use the defaults and everything should work. > > Can you try again, this time with default configuration of > id_provider=ipa ? You might need to clear the cache (rm > /var/lib/sss/db/cache_*) if you were playing around with the schema.. > > -- > 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 jhrozek at redhat.com Mon Mar 2 12:25:37 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 2 Mar 2015 13:25:37 +0100 Subject: [Freeipa-users] issues with secondary groups? (sssd) In-Reply-To: <6E96473E-CEE7-4983-B38E-F907F5A6735B@gmail.com> References: <54F211E8.9090407@gmail.com> <20150302091239.GR9792@hendrix.redhat.com> <6E96473E-CEE7-4983-B38E-F907F5A6735B@gmail.com> Message-ID: <20150302122537.GD9792@hendrix.redhat.com> On Mon, Mar 02, 2015 at 04:09:34AM -0800, Janelle wrote: > That was the point. The clients were not installed with IPA client install. > I have 2000 clients and still working on a simple way to automate the client install with ansible or puppet. Currently just trying to get it working with simple sssd/ldap only auth. I would recommend against enrolling clients in any other way than with ipa-client-install. I've CC-ed James Shubin, who worked on automating client installs with Puppet (and Puppet-iting IPA in general), I wonder if there's some howto we can link to? From rmj at ast.cam.ac.uk Mon Mar 2 12:29:17 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Mon, 02 Mar 2015 12:29:17 +0000 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <1425067497.9346.8.camel@willson.usersys.redhat.com> References: <54F0B548.8050902@ast.cam.ac.uk> <1425062007.9346.6.camel@willson.usersys.redhat.com> <54F0BE7E.4000001@ast.cam.ac.uk> <1425067497.9346.8.camel@willson.usersys.redhat.com> Message-ID: <54F4579D.6030206@ast.cam.ac.uk> On 27/02/15 20:04, Simo Sorce wrote: > 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 Thanks for your response. We do have delegated access to update to the DNS for our domain and also run a couple of name servers ourselves. The problem is really my ignorance of what any issues might be with having ipa manage more name servers in our domain which contains many hosts that will not ipa managed. We already have a DNS infrastructure and I have seen the "Benefits of integrated DNS" section at http://www.freeipa.org/page/DNS. With regard to each bullet point number, my comments and queries are: 1) Our clients will have static addresses so this doesn't seem relevant in our case. 2) In my current testing setup we don't have SRV records because DNS is not managed by ipa and ipa seems to work ok. I guess we will need to add SRV records to our DNS manually when we bring on line some ipa server replicas, so there could be a win here although I wouldn't anticipate the replicas changing much, so maybe this is a one-off manual setup without ipa managing DNS. Did I understand this correctly? 3) We do not have any AD to trust, at least for the forseeable future so this does not seem relevant in our sitution. 4) I'm not sure about this one. Things seem to work at the moment. Is this again about managing the records more easily when we bring on line replica servers? Thanks for any clarification or pointers to docs or discussion that you can offer. Roderick From rmj at ast.cam.ac.uk Mon Mar 2 12:29:24 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Mon, 02 Mar 2015 12:29:24 +0000 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <54F4142D.7040601@redhat.com> References: <54F0B548.8050902@ast.cam.ac.uk> <1425062007.9346.6.camel@willson.usersys.redhat.com> <54F0BE7E.4000001@ast.cam.ac.uk> <1425067497.9346.8.camel@willson.usersys.redhat.com> <54F4142D.7040601@redhat.com> Message-ID: <54F457A4.6020209@ast.cam.ac.uk> On 02/03/15 07:41, Petr Spacek wrote: > On 27.2.2015 21:04, Simo Sorce wrote: >> 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. > > Let me clarify it: > FreeIPA can manage DNS for you, which is easy thing to do if your corporate > policy allows that. > > start with > $ ipa-dns-install > and then add NS and glue records to the parent zones to have proper delegation > to FreeIPA DNS servers. > > DNS auto-management makes adding hosts and replicas easier but it is not > required in any way. > > If you do not want to manage DNS in FreeIPA you do no have to. For aliases, > ask your DNS admin to use CNAME records to create aliases for the canonical > host name (used in ipa host-add command). > > Have a nice day! > Peter Thanks for the clarification on host aliases. In my response to Simo I am really asking if the benefit is mainly in the handling of replicas which is what you seem to be saying. Roderick From jbaird at follett.com Mon Mar 2 12:33:50 2015 From: jbaird at follett.com (Baird, Josh) Date: Mon, 2 Mar 2015 12:33:50 +0000 Subject: [Freeipa-users] issues with secondary groups? (sssd) In-Reply-To: <20150302122537.GD9792@hendrix.redhat.com> References: <54F211E8.9090407@gmail.com> <20150302091239.GR9792@hendrix.redhat.com> <6E96473E-CEE7-4983-B38E-F907F5A6735B@gmail.com> <20150302122537.GD9792@hendrix.redhat.com> Message-ID: There is active development on the puppet-ipaclient module [1]. You should see a new release in the next few days that adds better support for ipa4, exposes sssd options and more. [1] https://forge.puppetlabs.com/stbenjam/ipaclient We will be using this module to automate the client install on a group of ~500 RHEL servers. Thanks, Josh > -----Original Message----- > From: freeipa-users-bounces at redhat.com [mailto:freeipa-users- > bounces at redhat.com] On Behalf Of Jakub Hrozek > Sent: Monday, March 02, 2015 7:26 AM > To: Janelle > Cc: James Shubin; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] issues with secondary groups? (sssd) > > On Mon, Mar 02, 2015 at 04:09:34AM -0800, Janelle wrote: > > That was the point. The clients were not installed with IPA client install. > > I have 2000 clients and still working on a simple way to automate the client > install with ansible or puppet. Currently just trying to get it working with > simple sssd/ldap only auth. > > I would recommend against enrolling clients in any other way than with ipa- > client-install. > > I've CC-ed James Shubin, who worked on automating client installs with > Puppet (and Puppet-iting IPA in general), I wonder if there's some howto > we can link to? > > -- > 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 jpazdziora at redhat.com Mon Mar 2 12:49:12 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 2 Mar 2015 13:49:12 +0100 Subject: [Freeipa-users] issues with secondary groups? (sssd) In-Reply-To: <6E96473E-CEE7-4983-B38E-F907F5A6735B@gmail.com> References: <54F211E8.9090407@gmail.com> <20150302091239.GR9792@hendrix.redhat.com> <6E96473E-CEE7-4983-B38E-F907F5A6735B@gmail.com> Message-ID: <20150302124912.GB23856@redhat.com> On Mon, Mar 02, 2015 at 04:09:34AM -0800, Janelle wrote: > That was the point. The clients were not installed with IPA client install. > I have 2000 clients and still working on a simple way to automate the client install with ansible or puppet. Currently just trying to get it working with simple sssd/ldap only auth. You might want to check Foreman and its realm feature: http://theforeman.org/manuals/1.7/index.html#4.3.9Realm That way OTP authentication will be used. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From pspacek at redhat.com Mon Mar 2 13:14:40 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 02 Mar 2015 14:14:40 +0100 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <54F4579D.6030206@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> <1425067497.9346.8.camel@willson.usersys.redhat.com> <54F4579D.6030206@ast.cam.ac.uk> Message-ID: <54F46240.7070705@redhat.com> On 2.3.2015 13:29, Roderick Johnstone wrote: > On 27/02/15 20:04, Simo Sorce wrote: >> 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 > > Thanks for your response. We do have delegated access to update to the DNS for > our domain and also run a couple of name servers ourselves. > > The problem is really my ignorance of what any issues might be with having ipa > manage more name servers in our domain which contains many hosts that will not > ipa managed. > > We already have a DNS infrastructure and I have seen the "Benefits of > integrated DNS" section at http://www.freeipa.org/page/DNS. With regard to > each bullet point number, my comments and queries are: > > 1) Our clients will have static addresses so this doesn't seem relevant in our > case. > > 2) In my current testing setup we don't have SRV records because DNS is not > managed by ipa and ipa seems to work ok. > > I guess we will need to add SRV records to our DNS manually when we bring on > line some ipa server replicas, so there could be a win here although I > wouldn't anticipate the replicas changing much, so maybe this is a one-off > manual setup without ipa managing DNS. Did I understand this correctly? Well, SRV records should be *always* present. It is possible to make it work without them (as you did) but AFAIK such setup not tested by us and is not supported (in RHEL). Also, by manual configuration you are losing things like failover between replicas / ability to add-remove replicas at will without client reconfiguration. Please note that you can add SRV records to your DNS servers without any need to introduce IPA DNS servers. > 3) We do not have any AD to trust, at least for the forseeable future so this > does not seem relevant in our sitution. > > 4) I'm not sure about this one. Things seem to work at the moment. Is this > again about managing the records more easily when we bring on line replica > servers? Yes. IPA DNS servers bring convenience but it is not mandatory in any way (especially if you do not want to use dynamic updates). > Thanks for any clarification or pointers to docs or discussion that you can > offer. Have a nice day! -- Petr^2 Spacek From christian.bonato at free.fr Sun Mar 1 12:53:24 2015 From: christian.bonato at free.fr (Christian) Date: Sun, 1 Mar 2015 12:53:24 +0000 (UTC) Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix References: Message-ID: Stephen Ingram writes: > 2. Configuration - With Postfix, you can set all different areas (e.g. > virtual, aliases, etc.) to use LDAP lookup of configuration > information. You are typically searching for the email address (mail > attribute in IPA) and your search will generally return the userid > (uid attribute) of where the mail is to be stored. .../... > Steve Playing with IPA too in order to better understand what it provides and how to use it, I realized that like almost any other solution that is bringing its own LDAP back-end, IPA make it "?? la Microsoft", which means that IPA LDAP server is used for IPA purpose only (for what I understand so far). If you want to rely on LDAP for mail delivery, e.g. havio??????????????????)????????????????????????????????????????????????????????????????????????????)???????????????????????1@????????????????????????????????(???????????????????????????????????????????????????????????????????????%A)1@??????1@?????????????????????A?????????????????????()$??????????????????????????????????????????????????%A?1@????????????)???????????????????????????????????????????????????????????????9???????????)??????????????????????????????????????????????????????????????????????????)??????????????????????????????????????????()=????????????????????????????????%A?1@?????????????????????????????)???????????????????????????????????????????????????????(( From matt.wells at mosaic451.com Mon Mar 2 05:49:28 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Sun, 1 Mar 2015 21:49:28 -0800 Subject: [Freeipa-users] Fwd: 2-Factor and services In-Reply-To: <54F3CD9A.4080309@redhat.com> References: <54EF99A9.1070701@redhat.com> <54F3CD9A.4080309@redhat.com> Message-ID: Is Kerberos the only mechanism in IDM using OTP? On Sun, Mar 1, 2015 at 6:40 PM, Dmitri Pal wrote: > On 02/27/2015 11:37 AM, Matt Wells wrote: > >> 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 Mac and Windows you would not get SSO anyways because Kerberos on thos > platforms does not support latest RFCs related to 2FA at least yet and > since they are proprietary it is unclear what their plans are. > > The problem we also have is that there is no way to be selective on the > KDC/DS side - there is no way to determine what the client is and associate > some policies to it. > It would have to be the client that would have to have capability to > enforce or not enforce 2FA if the server supports both. But again that > means that Mac and Windows would have to keep up with this capability. > > Bottom line it is a popular request but it is unclear how we can satisfy > it. > > > >> >> 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 >>> >> >> >> > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -- [image: Mosaic451] Matt WellsChief Systems Architect RHCVA, RHCA #110-000-353 (702) 8 <7028080424>08-0424 matt.wells at mosaic451.com Las Vegas | Phoenix | Portland Mosaic451.com [image: Facebook] [image: Twitter] [image: Google Plus] [image: LinkedIn] 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Mar 2 15:47:27 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Mar 2015 10:47:27 -0500 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: References: <54F1360B.2080807@redhat.com> <54F15D9E.10806@redhat.com> Message-ID: <54F4860F.7090201@redhat.com> Hadoop Solutions wrote: > Hi, > > IPA required SELinux enabled on the system? No, SELinux is not required, just very strongly recommended. We need a dogtag developer to take a look at the log to see if he can figure out the failure. He may also need the debug log from the CA to do this. rob > > Thanks, > Shaik > > On 28 February 2015 at 16:49, Hadoop Solutions > wrote: > > 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 > > > > > ,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 simo at redhat.com Mon Mar 2 16:06:35 2015 From: simo at redhat.com (Simo Sorce) Date: Mon, 02 Mar 2015 11:06:35 -0500 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <54F4579D.6030206@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> <1425067497.9346.8.camel@willson.usersys.redhat.com> <54F4579D.6030206@ast.cam.ac.uk> Message-ID: <1425312395.13900.7.camel@willson.usersys.redhat.com> On Mon, 2015-03-02 at 12:29 +0000, Roderick Johnstone wrote: > On 27/02/15 20:04, Simo Sorce wrote: > > 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 > > Thanks for your response. We do have delegated access to update to the > DNS for our domain and also run a couple of name servers ourselves. > > The problem is really my ignorance of what any issues might be with > having ipa manage more name servers in our domain which contains many > hosts that will not ipa managed. > > We already have a DNS infrastructure and I have seen the "Benefits of > integrated DNS" section at http://www.freeipa.org/page/DNS. With regard > to each bullet point number, my comments and queries are: > > 1) Our clients will have static addresses so this doesn't seem relevant > in our case. Ok, that means you do not expect to need DNS Updates, and I guess you'll provide DNS entries before the machines are joined to IPA. That works. > 2) In my current testing setup we don't have SRV records because DNS is > not managed by ipa and ipa seems to work ok. > > I guess we will need to add SRV records to our DNS manually when we > bring on line some ipa server replicas, so there could be a win here > although I wouldn't anticipate the replicas changing much, so maybe this > is a one-off manual setup without ipa managing DNS. Did I understand > this correctly? W/o SRV records you probably had to specify the server manually on the ipa-client-install command, this means your machines are already tied to that specific server. So you'll have to also apply modifications to the machien's sssd.conf file to allow them to find fallback replicas. > 3) We do not have any AD to trust, at least for the forseeable future so > this does not seem relevant in our sitution. ok, we just make sure people are aware that their choice of DNS domain name affects potentially interesting scenarios down the road. > 4) I'm not sure about this one. Things seem to work at the moment. Is > this again about managing the records more easily when we bring on line > replica servers? It is only about ease of use indeed, if you manage your servers manually, and keep them properly up to date, all should be fine. > Thanks for any clarification or pointers to docs or discussion that you > can offer. You are welcome, thanks for using FreeIPA Simo. -- Simo Sorce * Red Hat, Inc * New York From bentech4you at gmail.com Mon Mar 2 18:15:39 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Mon, 2 Mar 2015 21:15:39 +0300 Subject: [Freeipa-users] ipa group-add-member failed Message-ID: HI i am getting below error. please anyone tell me what does it mean [root at kwttstfreipa01 ~]# ipa group-add-member ad_admins_external --external 'KWTTESTDC\Domain Admins' [member user]: [member group]: Group name: ad_admins_external Description: kwttestdc.com admins external map Failed members: member user: member group: KWTTESTDC\Domain Admins: trusted domain object not found ------------------------- Number of members added 0 Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From purpleidea at redhat.com Mon Mar 2 17:32:35 2015 From: purpleidea at redhat.com (James Shubin) Date: Mon, 02 Mar 2015 12:32:35 -0500 Subject: [Freeipa-users] issues with secondary groups? (sssd) In-Reply-To: <20150302122537.GD9792@hendrix.redhat.com> References: <54F211E8.9090407@gmail.com> <20150302091239.GR9792@hendrix.redhat.com> <6E96473E-CEE7-4983-B38E-F907F5A6735B@gmail.com> <20150302122537.GD9792@hendrix.redhat.com> Message-ID: <1425317555.3627.3.camel@redhat.com> On Mon, 2015-03-02 at 13:25 +0100, Jakub Hrozek wrote: > On Mon, Mar 02, 2015 at 04:09:34AM -0800, Janelle wrote: > > That was the point. The clients were not installed with IPA client install. > > I have 2000 clients and still working on a simple way to automate the client install with ansible or puppet. Currently just trying to get it working with simple sssd/ldap only auth. > > I would recommend against enrolling clients in any other way than with > ipa-client-install. > > I've CC-ed James Shubin, who worked on automating client installs with > Puppet (and Puppet-iting IPA in general), I wonder if there's some howto > we can link to? The Puppet-IPA module has documentation: https://github.com/purpleidea/puppet-ipa/blob/master/DOCUMENTATION.md It has a client section too. HTH, James -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From dpal at redhat.com Mon Mar 2 19:07:39 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 02 Mar 2015 14:07:39 -0500 Subject: [Freeipa-users] Getting virtual aliases and domains via freeipa with Postfix In-Reply-To: References: Message-ID: <54F4B4FB.90305@redhat.com> On 03/01/2015 07:53 AM, Christian wrote: > Stephen Ingram writes: > > >> 2. Configuration - With Postfix, you can set all different areas (e.g. >> virtual, aliases, etc.) to use LDAP lookup of configuration >> information. You are typically searching for the email address (mail >> attribute in IPA) and your search will generally return the userid >> (uid attribute) of where the mail is to be stored. .../... >> Steve > > Playing with IPA too in order to better understand what it provides and how > to use it, I realized that like almost any other solution that is bringing > its own LDAP back-end, IPA make it "? la Microsoft", which means that IPA > LDAP server is used for IPA purpose only (for what I understand so far). > If you want to rely on LDAP for mail delivery, e.g. havio???????????????)????????????????????????a``????????????????????????????????????)???????O.-?????????1@????a``?a``???????????a``??(????????????????????????????????????????????????????%A)1@????1@????a``????????a``A???????????????()$????????????????????????????????????????%A?1@??????????)??5???????????????????????????????????????????????9??????????)??????????????????????????????????????????????????????????)???????????????????5??????????????()=??????????????????????????%A?1@???????????????????????)?????????????????????????????????????????(( > > > This seams to be a mangled message. -- 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 Mon Mar 2 19:10:51 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Mar 2015 21:10:51 +0200 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: References: Message-ID: <20150302191051.GG25455@redhat.com> On Mon, 02 Mar 2015, Ben .T.George wrote: >HI > >i am getting below error. please anyone tell me what does it mean > >[root at kwttstfreipa01 ~]# ipa group-add-member ad_admins_external --external >'KWTTESTDC\Domain Admins' >[member user]: >[member group]: > Group name: ad_admins_external > Description: kwttestdc.com admins external map > Failed members: > member user: > member group: KWTTESTDC\Domain Admins: trusted domain object not found >------------------------- >Number of members added 0 This looks like you don't have trust established. -- / Alexander Bokovoy From dpal at redhat.com Mon Mar 2 19:13:55 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 02 Mar 2015 14:13:55 -0500 Subject: [Freeipa-users] Fwd: 2-Factor and services In-Reply-To: References: <54EF99A9.1070701@redhat.com> <54F3CD9A.4080309@redhat.com> Message-ID: <54F4B673.9040901@redhat.com> On 03/02/2015 01:19 AM, Michael Lasevich wrote: > There is actually a way to achieve what you most likely want to but > not what you are asking for. > > I do not think there is currently a way to force 2fa based on service > or host being authenticated - it is all or nothing. However, if all > you want is ability to use 2fa against FreeIPA for OpenVPN > authentication and use just password everywhere else - that is > actually possible. > > This is how I achieved this - may not be an ideal setup but it works. > As suggested, set up users to support both 2fa and password > authentication. Forget about using PAM for OpenVPN authentication - > instead use a plug-in script with credentials passed using via-env. > You can write the plugin in any language you want (I used Python) and > your logic should be something along the lines of: > > Parse password to separate OTP token from password. Use LDAP to > authenticate with just password and then again with password AND OTP > token. LDAP authentication happens on the IPA server and will support > both methods. Authenticating twice is important to guarantee you do > not have a smart-alec user who sets their password to end in 6 digits > instead of actually enabling 2fa. Once you have successful > authentication, you can use it to perform additional verifications - > like checking membership(or lack thereof) in specific group, etc., etc. > > So, here is something else to think about. You may not want to allow > the same accounts access to VPN and to the internal network. There is > a reason why this is generally considered a bad practice. If someone, > by some means (say another heartbleed-like exploit or some MITM attack > or by gaining root access to the VPN serve) gains access to your > user's VPN login credentials - the last thing you want is them having > a full run of the network using those exact same credentials. Ideally > it would be nice if 2fa "pin" (the non OTP portion of the 2fa) would > be DIFFERENT from the password on the same account, but FreeIPA does > not support that - at least not at this time. So what I would > recommend is using a completely separate account in FreeIPA for VPN > access. You can standardize this by using a standard prefix (so that > for example user "username" would have an "ext-username" account for > 2fa use with external authentication) - "ext" account would have no > permissions to any data or internal login, just to access the network > from outside and the main account would have no external access. To > hack you, someone would then need to hack your OpenVPN box and then > would still need to hack your internal authentication - which should > be encrypted by TLS/SSH even over the VPN. You can also add the prefix > automatically behind the scenes with the OpenVPN authentication > script, as well as have the script only allow access for accounts that > have no other privileges besides external access. Something to think > about. This customization is very specific to the conventions that you choose for yourself to follow. It is not a bad solution, just a bit too custom. > > HTH, > > -M > > On Sun, Mar 1, 2015 at 6:40 PM, Dmitri Pal > wrote: > > On 02/27/2015 11:37 AM, Matt Wells wrote: > > 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 Mac and Windows you would not get SSO anyways because Kerberos > on thos platforms does not support latest RFCs related to 2FA at > least yet and since they are proprietary it is unclear what their > plans are. > > The problem we also have is that there is no way to be selective > on the KDC/DS side - there is no way to determine what the client > is and associate some policies to it. > It would have to be the client that would have to have capability > to enforce or not enforce 2FA if the server supports both. But > again that means that Mac and Windows would have to keep up with > this capability. > > Bottom line it is a popular request but it is unclear how we can > satisfy it. > > > > > 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 > > > > > > -- > 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 rcritten at redhat.com Mon Mar 2 19:14:19 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 02 Mar 2015 14:14:19 -0500 Subject: [Freeipa-users] Failed to start Identity, Policy, Audit In-Reply-To: References: Message-ID: <54F4B68B.9090502@redhat.com> Umarzuki Mochlis wrote: > After rebooting freeipa server, I cannot log in to its web interface > and when I try to start it, it failed > > More info: > > [root at ipa ~]# systemctl start ipa.service > Job for ipa.service failed. See 'systemctl status ipa.service' and > 'journalctl -n' for details. > > [root at ipa ~]# systemctl status ipa.service > ipa.service - Identity, Policy, Audit > Loaded: loaded (/usr/lib/systemd/system/ipa.service; enabled) > Active: failed (Result: exit-code) since Sun, 2015-03-01 > 21:36:49 MYT; 15s ago > Process: 1918 ExecStart=/usr/sbin/ipactl start (code=exited, > status=1/FAILURE) > CGroup: name=systemd:/system/ipa.service > > Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Aborting ipactl > Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting Directory Service > Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting krb5kdc Service > Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting kadmin Service > Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting ipa_memcached Service > Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting httpd Service > Mar 01 21:36:49 ipa.domain.com ipactl[1918]: Starting pki-tomcatd Service > Mar 01 21:36:49 ipa.domain.com systemd[1]: ipa.service: main process > exited, code=exited, status=1/FAILURE > Mar 01 21:36:49 ipa.domain.com systemd[1]: Failed to start Identity, > Policy, Audit. > Mar 01 21:36:49 ipa.domain.com systemd[1]: Unit ipa.service entered failed state > > [root at ipa ~]# KRB5_TRACE=/dev/stdout kinit admin > [2324] 1425217336.627346: Getting initial credentials for admin at domain.com > [2324] 1425217336.630877: Sending request (155 bytes) to domain.com > [2324] 1425217336.631163: Sending initial UDP request to dgram 192.168.1.100:88 > [2324] 1425217336.631265: UDP error receiving from dgram > 192.168.1.100:88: 111/Connection refused > [2324] 1425217336.631301: Initiating TCP connection to stream 192.168.1.100:88 > [2324] 1425217336.631351: Terminating TCP connection to stream 192.168.1.100:88 > kinit: Cannot contact any KDC for realm 'domain.com' while getting > initial credentials > > [root at ipa ~]# rpm -qa | grep ipa > freeipa-admintools-3.1.0-2.fc18.x86_64 > freeipa-server-3.1.0-2.fc18.x86_64 > libipa_hbac-python-1.9.3-1.fc18.x86_64 > python-iniparse-0.4-6.fc18.noarch > freeipa-client-3.1.0-2.fc18.x86_64 > freeipa-server-selinux-3.1.0-2.fc18.x86_64 > freeipa-python-3.1.0-2.fc18.x86_64 > libipa_hbac-1.9.3-1.fc18.x86_64 > > What is my next course of action to solve this? > Two suggestions: # getcert list See if you have a bunch of expired certificates. I'm thinking probably not the problem since Apache appears to have started. It is failing with the CA so I'd look in those logs, /var/log/pki-ca IIRC with 3.1 (or /var/log/pki-something, should be obvious. You may also want to look for SELinux errors: # ausearch -m AVC -ts recent Assuming expired certificates aren't the problem you can manually start the other services to get your infrastructure back up while you investigate the CA startup failure. rob From guertin at middlebury.edu Mon Mar 2 19:32:54 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Mon, 2 Mar 2015 19:32:54 +0000 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users Message-ID: <1425324774568.82792@middlebury.edu> I'm trying to set up a trust relationship between IPA and our Active Directory environment so that our AD users can log in to our Linux machines. The two-way trust relationship appears to be set up correctly, with no errors reported, and everything looking normal in the GUI and the CLI. For example: # klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: admin at CSNS.MIDDLEBURY.EDU Valid starting Expires Service principal 03/02/15 10:13:40 03/03/15 10:13:10 krbtgt/CSNS.MIDDLEBURY.EDU at CSNS.MIDDLEBURY.EDU 03/02/15 10:15:13 03/03/15 10:13:10 host/ipa1.csns.middlebury.edu at CSNS.MIDDLEBURY.EDU 03/02/15 10:15:35 03/03/15 10:13:10 krbtgt/MIDDLEBURY.EDU at CSNS.MIDDLEBURY.EDU 03/02/15 10:15:46 03/02/15 20:15:46 host/ad1.middlebury.edu at MIDDLEBURY.EDU 03/02/15 10:56:55 03/03/15 10:13:10 HTTP/ipa1.csns.middlebury.edu at CSNS.MIDDLEBURY.EDU In this case, middlebury.edu is our AD domain, and csns.middlebury.edu is our new IPA domain, set up as a subdomain. I have created IPA and AD groups for AD users, and set them up according the documentation: ipa group-add --desc='AD users external map' ad_users_external --external ipa group-add --desc='AD users' ad_users ipa group-add-member ad_users_external --external "\IPA group" ipa group-add-member ad_users --groups ad_users_external So now the AD group "IPA group" is a member of the IPA group ad_users_external , which is in turn a member of ad_users. I would expect that any AD users I put into the group "IPA group" should show up as valid users in IPA, but they don't. And when I try to add an AD user directly into the ad_users_external group, it is added without error (and the correct SID shows up), but the user still can't log in. If the user tries to SSH in the logs show: Mar 2 11:13:42 ipa1 sshd[31720]: Invalid user testuser from *.*.*.* Mar 2 11:13:42 ipa1 sshd[31721]: input_userauth_request: invalid user testuser And if root tries to su to the user, it also fails: su: user testuser does not exist I would expect the user to show up. What have I missed? David Guertin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Mon Mar 2 19:36:57 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Mon, 2 Mar 2015 22:36:57 +0300 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: <20150302191051.GG25455@redhat.com> References: <20150302191051.GG25455@redhat.com> Message-ID: HI trust was successful ipa trust-add --type=ad *ad_domain* --admin Administrator --password and i got output like below Active directory domain administrator's password: ------------------------------------------------------ Added Active Directory trust for realm "KWTTESTDC.COM" ------------------------------------------------------ Realm name: KWTTESTDC.COM Domain NetBIOS name: KWTTESTDC Domain Security Identifier: S-1-5-21-3779563847-208264455-1888173826 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 this is what it should give noe? How can i check the trust is correct or not.? Regards, Ben On Mon, Mar 2, 2015 at 10:10 PM, Alexander Bokovoy wrote: > On Mon, 02 Mar 2015, Ben .T.George wrote: > >> HI >> >> i am getting below error. please anyone tell me what does it mean >> >> [root at kwttstfreipa01 ~]# ipa group-add-member ad_admins_external >> --external >> 'KWTTESTDC\Domain Admins' >> [member user]: >> [member group]: >> Group name: ad_admins_external >> Description: kwttestdc.com admins external map >> Failed members: >> member user: >> member group: KWTTESTDC\Domain Admins: trusted domain object not found >> ------------------------- >> Number of members added 0 >> > This looks like you don't have trust established. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Mar 2 20:11:12 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Mar 2015 22:11:12 +0200 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: References: <20150302191051.GG25455@redhat.com> Message-ID: <20150302201112.GH25455@redhat.com> On Mon, 02 Mar 2015, Ben .T.George wrote: >HI > >trust was successful > >ipa trust-add --type=ad *ad_domain* --admin Administrator --password > >and i got output like below > >Active directory domain administrator's password: >------------------------------------------------------ >Added Active Directory trust for realm "KWTTESTDC.COM" >------------------------------------------------------ > Realm name: KWTTESTDC.COM > Domain NetBIOS name: KWTTESTDC > Domain Security Identifier: S-1-5-21-3779563847-208264455-1888173826 > 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 > >this is what it should give noe? > >How can i check the trust is correct or not.? Try: $ kinit admin $ KRB5_TRACE=/dev/stderr kvno -S cifs ad.domain.controller.fqdn and show the output. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Mar 2 20:17:24 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Mar 2015 22:17:24 +0200 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <1425324774568.82792@middlebury.edu> References: <1425324774568.82792@middlebury.edu> Message-ID: <20150302201724.GI25455@redhat.com> On Mon, 02 Mar 2015, Guertin, David S. wrote: >I'm trying to set up a trust relationship between IPA and our Active >Directory environment so that our AD users can log in to our Linux >machines. The two-way trust relationship appears to be set up >correctly, with no errors reported, and everything looking normal in >the GUI and the CLI. For example: > > ># klist >Ticket cache: FILE:/tmp/krb5cc_0 >Default principal: admin at CSNS.MIDDLEBURY.EDU > >Valid starting Expires Service principal >03/02/15 10:13:40 03/03/15 10:13:10 krbtgt/CSNS.MIDDLEBURY.EDU at CSNS.MIDDLEBURY.EDU >03/02/15 10:15:13 03/03/15 10:13:10 host/ipa1.csns.middlebury.edu at CSNS.MIDDLEBURY.EDU >03/02/15 10:15:35 03/03/15 10:13:10 krbtgt/MIDDLEBURY.EDU at CSNS.MIDDLEBURY.EDU >03/02/15 10:15:46 03/02/15 20:15:46 host/ad1.middlebury.edu at MIDDLEBURY.EDU >03/02/15 10:56:55 03/03/15 10:13:10 HTTP/ipa1.csns.middlebury.edu at CSNS.MIDDLEBURY.EDU > >In this case, middlebury.edu is our AD domain, and csns.middlebury.edu >is our new IPA domain, set up as a subdomain. > > >I have created IPA and AD groups for AD users, and set them up >according the documentation: > > >ipa group-add --desc='AD users external map' ad_users_external --external > >ipa group-add --desc='AD users' ad_users > >ipa group-add-member ad_users_external --external "\IPA group" > >ipa group-add-member ad_users --groups ad_users_external > > >So now the AD group "IPA group" is a member of the IPA group >ad_users_external , which is in turn a member of ad_users. > > >I would expect that any AD users I put into the group "IPA group" >should show up as valid users in IPA, but they don't. And when I try to >add an AD user directly into the ad_users_external group, it is added >without error (and the correct SID shows up), but the user still can't >log in. Lets separate issues. 1. Adding AD user to "IPA group" in AD. Did you re-login as that user on Windows side and then tried to logon to IPA server? 2. What do SSSD logs say about the login attempt? You need to set debug_level = 10 in [domain/..], [nss] and [pam] sections of /etc/sssd/sssd.conf and restart sssd. >And if root tries to su to the user, it also fails: > >su: user testuser does not exist > > >I would expect the user to show up. What have I missed? If 'su' says that user does not exist, it means SSSD does not see the user as existing. There may be multiple reasons for that, sssd logs should tell exactly what has happened. You can try 'id testuser' to reduce use case for sssd logs. -- / Alexander Bokovoy From bentech4you at gmail.com Mon Mar 2 20:15:18 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Mon, 2 Mar 2015 23:15:18 +0300 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: <20150302201112.GH25455@redhat.com> References: <20150302191051.GG25455@redhat.com> <20150302201112.GH25455@redhat.com> Message-ID: Hi please find below output [root at kwttstfreipa01 ~]# kinit admin Password for admin at SOLIPA.LOCAL: [root at kwttstfreipa01 ~]# id admin uid=756800000(admin) gid=756800000(admins) groups=756800000(admins) [root at kwttstfreipa01 ~]# KRB5_TRACE=/dev/stderr kvno -S cifs kwttestdc001.kwttestdc.com [16898] 1425327238.662939: Convert service cifs (service with host as instance) on host kwttestdc001.kwttestdc.com to principal [16898] 1425327238.663650: Remote host after forward canonicalization: kwttestdc001.kwttestdc.com [16898] 1425327238.663684: Remote host after reverse DNS processing: kwttestdc001.kwttestdc.com [16898] 1425327238.663728: Get host realm for kwttestdc001.kwttestdc.com [16898] 1425327238.663742: Use local host kwttestdc001.kwttestdc.com to get host realm [16898] 1425327238.663749: Look up kwttestdc001.kwttestdc.com in the domain_realm map [16898] 1425327238.663757: Look up .kwttestdc.com in the domain_realm map [16898] 1425327238.663764: Temporary realm is KWTTESTDC.COM [16898] 1425327238.663771: Got realm KWTTESTDC.COM for host kwttestdc001.kwttestdc.com [16898] 1425327238.663792: Got service principal cifs/ kwttestdc001.kwttestdc.com at KWTTESTDC.COM [16898] 1425327238.663818: Getting credentials admin at SOLIPA.LOCAL -> cifs/ kwttestdc001.kwttestdc.com at KWTTESTDC.COM using ccache KEYRING:persistent:0:0 [16898] 1425327238.664257: Retrieving admin at SOLIPA.LOCAL -> cifs/ kwttestdc001.kwttestdc.com at KWTTESTDC.COM from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16898] 1425327238.664381: Retrieving admin at SOLIPA.LOCAL -> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16898] 1425327238.664500: Retrieving admin at SOLIPA.LOCAL -> krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL from KEYRING:persistent:0:0 with result: 0/Success [16898] 1425327238.664516: Starting with TGT for client realm: admin at SOLIPA.LOCAL -> krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL [16898] 1425327238.664608: Retrieving admin at SOLIPA.LOCAL -> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 with result: -1765328243/Matching credential not found [16898] 1425327238.664622: Requesting TGT krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL using TGT krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL [16898] 1425327238.664690: Generated subkey for TGS request: aes256-cts/F74E [16898] 1425327238.664818: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts [16898] 1425327238.665062: Encoding request body and padata into FAST request [16898] 1425327238.665256: Sending request (1486 bytes) to SOLIPA.LOCAL [16898] 1425327238.665597: Initiating TCP connection to stream 172.16.107.250:88 [16898] 1425327238.665802: Sending TCP request to stream 172.16.107.250:88 [16898] 1425327238.673061: Received answer from stream 172.16.107.250:88 [16898] 1425327238.673285: Response was from master KDC [16898] 1425327238.673342: Decoding FAST response [16898] 1425327238.673574: FAST reply key: aes256-cts/9134 [16898] 1425327238.673650: TGS reply is for admin at SOLIPA.LOCAL -> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL with session key aes256-cts/4F6F [16898] 1425327238.673691: TGS request result: 0/Success [16898] 1425327238.673753: Removing admin at SOLIPA.LOCAL -> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 [16898] 1425327238.673768: Storing admin at SOLIPA.LOCAL -> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL in KEYRING:persistent:0:0 [16898] 1425327238.673933: Received TGT for service realm: krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL [16898] 1425327238.673950: Requesting tickets for cifs/ kwttestdc001.kwttestdc.com at KWTTESTDC.COM, referrals on [16898] 1425327238.673998: Generated subkey for TGS request: aes256-cts/8623 [16898] 1425327238.674084: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts [16898] 1425327238.674238: Encoding request body and padata into FAST request [16898] 1425327238.674395: Sending request (1531 bytes) to KWTTESTDC.COM [16898] 1425327238.676086: Resolving hostname kwttestdc001.kwttestdc.com. [16898] 1425327238.678096: Resolving hostname kwttestdc001.kwttestdc.com. [16898] 1425327238.678907: Initiating TCP connection to stream 172.16.104.231:88 [16898] 1425327238.679404: Sending TCP request to stream 172.16.104.231:88 [16898] 1425327238.681292: Received answer from stream 172.16.104.231:88 [16898] 1425327238.682088: Response was not from master KDC [16898] 1425327238.682142: TGS request result: -1765328372/KDC policy rejects request [16898] 1425327238.682161: Requesting tickets for cifs/ kwttestdc001.kwttestdc.com at KWTTESTDC.COM, referrals off [16898] 1425327238.682212: Generated subkey for TGS request: aes256-cts/50DA [16898] 1425327238.682283: etypes requested in TGS request: aes256-cts, aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts [16898] 1425327238.682391: Encoding request body and padata into FAST request [16898] 1425327238.682499: Sending request (1531 bytes) to KWTTESTDC.COM [16898] 1425327238.683871: Resolving hostname kwttestdc001.kwttestdc.com. [16898] 1425327238.684756: Resolving hostname kwttestdc001.kwttestdc.com. [16898] 1425327238.685461: Initiating TCP connection to stream 172.16.104.231:88 [16898] 1425327238.685864: Sending TCP request to stream 172.16.104.231:88 [16898] 1425327238.687136: Received answer from stream 172.16.104.231:88 [16898] 1425327238.687793: Response was not from master KDC [16898] 1425327238.687832: TGS request result: -1765328372/KDC policy rejects request kvno: KDC policy rejects request while getting credentials for cifs/ kwttestdc001.kwttestdc.com at KWTTESTDC.COM On Mon, Mar 2, 2015 at 11:11 PM, Alexander Bokovoy wrote: > On Mon, 02 Mar 2015, Ben .T.George wrote: > >> HI >> >> trust was successful >> >> ipa trust-add --type=ad *ad_domain* --admin Administrator --password >> >> and i got output like below >> >> Active directory domain administrator's password: >> ------------------------------------------------------ >> Added Active Directory trust for realm "KWTTESTDC.COM" >> ------------------------------------------------------ >> Realm name: KWTTESTDC.COM >> Domain NetBIOS name: KWTTESTDC >> Domain Security Identifier: S-1-5-21-3779563847-208264455-1888173826 >> 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 >> >> this is what it should give noe? >> >> How can i check the trust is correct or not.? >> > Try: > > $ kinit admin > $ KRB5_TRACE=/dev/stderr kvno -S cifs ad.domain.controller.fqdn > > and show the output. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Mar 2 20:27:45 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 2 Mar 2015 22:27:45 +0200 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: References: <20150302191051.GG25455@redhat.com> <20150302201112.GH25455@redhat.com> Message-ID: <20150302202745.GJ25455@redhat.com> On Mon, 02 Mar 2015, Ben .T.George wrote: >Hi please find below output > >[root at kwttstfreipa01 ~]# kinit admin >Password for admin at SOLIPA.LOCAL: > >[root at kwttstfreipa01 ~]# id admin >uid=756800000(admin) gid=756800000(admins) groups=756800000(admins) > > >[root at kwttstfreipa01 ~]# KRB5_TRACE=/dev/stderr kvno -S cifs >kwttestdc001.kwttestdc.com >[16898] 1425327238.662939: Convert service cifs (service with host as >instance) on host kwttestdc001.kwttestdc.com to principal >[16898] 1425327238.663650: Remote host after forward canonicalization: >kwttestdc001.kwttestdc.com >[16898] 1425327238.663684: Remote host after reverse DNS processing: >kwttestdc001.kwttestdc.com >[16898] 1425327238.663728: Get host realm for kwttestdc001.kwttestdc.com >[16898] 1425327238.663742: Use local host kwttestdc001.kwttestdc.com to get >host realm >[16898] 1425327238.663749: Look up kwttestdc001.kwttestdc.com in the >domain_realm map >[16898] 1425327238.663757: Look up .kwttestdc.com in the domain_realm map >[16898] 1425327238.663764: Temporary realm is KWTTESTDC.COM >[16898] 1425327238.663771: Got realm KWTTESTDC.COM for host >kwttestdc001.kwttestdc.com >[16898] 1425327238.663792: Got service principal cifs/ >kwttestdc001.kwttestdc.com at KWTTESTDC.COM >[16898] 1425327238.663818: Getting credentials admin at SOLIPA.LOCAL -> cifs/ >kwttestdc001.kwttestdc.com at KWTTESTDC.COM using ccache KEYRING:persistent:0:0 >[16898] 1425327238.664257: Retrieving admin at SOLIPA.LOCAL -> cifs/ >kwttestdc001.kwttestdc.com at KWTTESTDC.COM from KEYRING:persistent:0:0 with >result: -1765328243/Matching credential not found >[16898] 1425327238.664381: Retrieving admin at SOLIPA.LOCAL -> >krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 with result: >-1765328243/Matching credential not found >[16898] 1425327238.664500: Retrieving admin at SOLIPA.LOCAL -> >krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL from KEYRING:persistent:0:0 with result: >0/Success >[16898] 1425327238.664516: Starting with TGT for client realm: >admin at SOLIPA.LOCAL -> krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL >[16898] 1425327238.664608: Retrieving admin at SOLIPA.LOCAL -> >krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 with result: >-1765328243/Matching credential not found >[16898] 1425327238.664622: Requesting TGT krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL >using TGT krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL >[16898] 1425327238.664690: Generated subkey for TGS request: aes256-cts/F74E >[16898] 1425327238.664818: etypes requested in TGS request: aes256-cts, >aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts >[16898] 1425327238.665062: Encoding request body and padata into FAST >request >[16898] 1425327238.665256: Sending request (1486 bytes) to SOLIPA.LOCAL >[16898] 1425327238.665597: Initiating TCP connection to stream >172.16.107.250:88 >[16898] 1425327238.665802: Sending TCP request to stream 172.16.107.250:88 >[16898] 1425327238.673061: Received answer from stream 172.16.107.250:88 >[16898] 1425327238.673285: Response was from master KDC >[16898] 1425327238.673342: Decoding FAST response >[16898] 1425327238.673574: FAST reply key: aes256-cts/9134 >[16898] 1425327238.673650: TGS reply is for admin at SOLIPA.LOCAL -> >krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL with session key aes256-cts/4F6F >[16898] 1425327238.673691: TGS request result: 0/Success >[16898] 1425327238.673753: Removing admin at SOLIPA.LOCAL -> >krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 >[16898] 1425327238.673768: Storing admin at SOLIPA.LOCAL -> >krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL in KEYRING:persistent:0:0 >[16898] 1425327238.673933: Received TGT for service realm: >krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL >[16898] 1425327238.673950: Requesting tickets for cifs/ >kwttestdc001.kwttestdc.com at KWTTESTDC.COM, referrals on >[16898] 1425327238.673998: Generated subkey for TGS request: aes256-cts/8623 >[16898] 1425327238.674084: etypes requested in TGS request: aes256-cts, >aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts >[16898] 1425327238.674238: Encoding request body and padata into FAST >request >[16898] 1425327238.674395: Sending request (1531 bytes) to KWTTESTDC.COM >[16898] 1425327238.676086: Resolving hostname kwttestdc001.kwttestdc.com. >[16898] 1425327238.678096: Resolving hostname kwttestdc001.kwttestdc.com. >[16898] 1425327238.678907: Initiating TCP connection to stream >172.16.104.231:88 >[16898] 1425327238.679404: Sending TCP request to stream 172.16.104.231:88 >[16898] 1425327238.681292: Received answer from stream 172.16.104.231:88 >[16898] 1425327238.682088: Response was not from master KDC >[16898] 1425327238.682142: TGS request result: -1765328372/KDC policy >rejects request >[16898] 1425327238.682161: Requesting tickets for cifs/ >kwttestdc001.kwttestdc.com at KWTTESTDC.COM, referrals off >[16898] 1425327238.682212: Generated subkey for TGS request: aes256-cts/50DA >[16898] 1425327238.682283: etypes requested in TGS request: aes256-cts, >aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts >[16898] 1425327238.682391: Encoding request body and padata into FAST >request >[16898] 1425327238.682499: Sending request (1531 bytes) to KWTTESTDC.COM >[16898] 1425327238.683871: Resolving hostname kwttestdc001.kwttestdc.com. >[16898] 1425327238.684756: Resolving hostname kwttestdc001.kwttestdc.com. >[16898] 1425327238.685461: Initiating TCP connection to stream >172.16.104.231:88 >[16898] 1425327238.685864: Sending TCP request to stream 172.16.104.231:88 >[16898] 1425327238.687136: Received answer from stream 172.16.104.231:88 >[16898] 1425327238.687793: Response was not from master KDC >[16898] 1425327238.687832: TGS request result: -1765328372/KDC policy >rejects request >kvno: KDC policy rejects request while getting credentials for cifs/ >kwttestdc001.kwttestdc.com at KWTTESTDC.COM Last line tells that trust is not working. Read discussion in this thread: https://www.redhat.com/archives/freeipa-users/2015-February/msg00397.html and follow recommendations there, it was just last week here. -- / Alexander Bokovoy From leigh.moulder at sri.com Mon Mar 2 20:48:58 2015 From: leigh.moulder at sri.com (Leigh Moulder) Date: Mon, 2 Mar 2015 12:48:58 -0800 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: References: <54F1360B.2080807@redhat.com> Message-ID: <54F4CCBA.5050004@sri.com> Hi Shaik, Out of curiosity, what version of Java are you running? I had a similar problem on one of my RHEL 6 boxes that was running Java 1.8. When I downgraded to 1.7, I was able to run the installation as expected. Regards, Leigh On 2/27/2015 10:01 PM, Hadoop Solutions wrote: > 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: smime.p7s Type: application/pkcs7-signature Size: 4027 bytes Desc: S/MIME Cryptographic Signature URL: From guertin at middlebury.edu Mon Mar 2 21:33:04 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Mon, 2 Mar 2015 21:33:04 +0000 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <20150302201724.GI25455@redhat.com> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> Message-ID: <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> > Lets separate issues. > > 1. Adding AD user to "IPA group" in AD. > Did you re-login as that user on Windows side and then tried to logon > to IPA server? Yes. > 2. What do SSSD logs say about the login attempt? You need to set > debug_level = 10 in [domain/..], [nss] and [pam] sections of > /etc/sssd/sssd.conf and restart sssd. > If 'su' says that user does not exist, it means SSSD does not see the user as > existing. There may be multiple reasons for that, sssd logs should tell > exactly what has happened. You can try 'id testuser' to reduce use case for > sssd logs. OK, here's what shows up in /var/log/sssd_nss.log after "id testuser at middlebury.edu": (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'testuser at middlebury.edu' matched expression for domain 'middlebury.edu', user is testuser (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [testuser] from [middlebury.edu] (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at middlebury.edu] (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 1432158221, Account info lookup failed Will try to return what we have in cache (Mon Mar 2 15:34:34 2015) [sssd[nss]] [client_recv] (0x0200): Client disconnected! That makes it look like AD is not sending the user info to IPA. But if the trust is set up, why is it not sending it? BTW, if I don't include the domain name with the username, i.e. I do "id testuser", I see: (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'testuser' matched without domain, user is testuser (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [testuser] from [] (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at csns.middlebury.edu] (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at csns.middlebury.edu] (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0040): No results for getpwnam call (Mon Mar 2 15:35:49 2015) [sssd[nss]] [client_recv] (0x0200): Client disconnected! Thanks, David Guertin From dpal at redhat.com Tue Mar 3 00:56:55 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 02 Mar 2015 19:56:55 -0500 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> Message-ID: <54F506D7.2090207@redhat.com> On 03/02/2015 04:33 PM, Guertin, David S. wrote: >> Lets separate issues. >> >> 1. Adding AD user to "IPA group" in AD. >> Did you re-login as that user on Windows side and then tried to logon >> to IPA server? > Yes. > >> 2. What do SSSD logs say about the login attempt? You need to set >> debug_level = 10 in [domain/..], [nss] and [pam] sections of >> /etc/sssd/sssd.conf and restart sssd. >> If 'su' says that user does not exist, it means SSSD does not see the user as >> existing. There may be multiple reasons for that, sssd logs should tell >> exactly what has happened. You can try 'id testuser' to reduce use case for >> sssd logs. > OK, here's what shows up in /var/log/sssd_nss.log after "id testuser at middlebury.edu": > > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'testuser at middlebury.edu' matched expression for domain 'middlebury.edu', user is testuser > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [testuser] from [middlebury.edu] > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at middlebury.edu] > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider > Error: 3, 1432158221, Account info lookup failed The trust is established using one protocol while the lookup happens using another. Can it be that there is a FW and LDAP calls might not go through between IPA server and AD? > Will try to return what we have in cache > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [client_recv] (0x0200): Client disconnected! > > That makes it look like AD is not sending the user info to IPA. But if the trust is set up, why is it not sending it? > > BTW, if I don't include the domain name with the username, i.e. I do "id testuser", I see: > > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'testuser' matched without domain, user is testuser > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [testuser] from [] > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at csns.middlebury.edu] > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at csns.middlebury.edu] > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0040): No results for getpwnam call > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [client_recv] (0x0200): Client disconnected! In this case it assumes that the user is IPA user and does not try to lookup user in AD. > > Thanks, > David Guertin > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jprouty at cctus.com Tue Mar 3 04:38:48 2015 From: jprouty at cctus.com (Jason Prouty) Date: Mon, 2 Mar 2015 21:38:48 -0700 (MST) Subject: [Freeipa-users] Auto disable users In-Reply-To: <855174596.25289.1425357483501.JavaMail.zimbra@cctus.com> Message-ID: <1192409290.25294.1425357528157.JavaMail.zimbra@cctus.com> Is there a method to auto disable users who have logged in 90 days. I have a security requirement to auto disable users who have not logged in after 90 days. From bentech4you at gmail.com Tue Mar 3 09:15:18 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 3 Mar 2015 12:15:18 +0300 Subject: [Freeipa-users] how can i avoid error :ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides Message-ID: HI i am getting below error while trying* ipa trust-fetch-domains kwttestdc.com * ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides time is synced through ntpd and there is no time difference between ad ans IPA server but if i am getting [root at kwtpocpbis01 ~]# ipa trust-fetch-domains kwttestdc.com ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example [root at kwtpocpbis01 ~]# ipa trustdomain-find "kwttestdc.com" Domain name: kwttestdc.com Domain NetBIOS name: KWTTESTDC Domain Security Identifier: S-1-5-21-3321666283-4099738591-2270060621 Domain enabled: True ---------------------------- Number of entries returned 1 pleaswe help me solve this issue -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Mar 3 09:55:26 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 3 Mar 2015 10:55:26 +0100 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> Message-ID: <20150303095526.GC4026@hendrix.arn.redhat.com> On Mon, Mar 02, 2015 at 09:33:04PM +0000, Guertin, David S. wrote: > > Lets separate issues. > > > > 1. Adding AD user to "IPA group" in AD. > > Did you re-login as that user on Windows side and then tried to logon > > to IPA server? > > Yes. > > > 2. What do SSSD logs say about the login attempt? You need to set > > debug_level = 10 in [domain/..], [nss] and [pam] sections of > > /etc/sssd/sssd.conf and restart sssd. > > > If 'su' says that user does not exist, it means SSSD does not see the user as > > existing. There may be multiple reasons for that, sssd logs should tell > > exactly what has happened. You can try 'id testuser' to reduce use case for > > sssd logs. > > OK, here's what shows up in /var/log/sssd_nss.log after "id testuser at middlebury.edu": > > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'testuser at middlebury.edu' matched expression for domain 'middlebury.edu', user is testuser > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [testuser] from [middlebury.edu] > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at middlebury.edu] > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider > Error: 3, 1432158221, Account info lookup failed > Will try to return what we have in cache > (Mon Mar 2 15:34:34 2015) [sssd[nss]] [client_recv] (0x0200): Client disconnected! > > That makes it look like AD is not sending the user info to IPA. But if the trust is set up, why is it not sending it? The request was actually sent by the NSS front-end, but the Unable to get information from Data provider line says the sssd_be back end process was unable to connect to the server and fetch the data. Do these logs come from a client or the IPA server? Are you able to look up the user on the IPA server at least? Can you paste (sanitized) logs from the sssd_be process as well? They would be located at /var/log/sssd/sssd_middlebury.edu.log If the logs are from the client and the back end logs would say something about extended operation failing, then we need to take a look at the sssd logs on the server as well. > > BTW, if I don't include the domain name with the username, i.e. I do "id testuser", I see: > > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'testuser' matched without domain, user is testuser > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [testuser] from [] > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at csns.middlebury.edu] > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [testuser at csns.middlebury.edu] > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0040): No results for getpwnam call > (Mon Mar 2 15:35:49 2015) [sssd[nss]] [client_recv] (0x0200): Client disconnected! Right, the code paths for retrieving IPA users and AD users are mostly separate on the sssd_be side. From abokovoy at redhat.com Tue Mar 3 10:16:48 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 Mar 2015 12:16:48 +0200 Subject: [Freeipa-users] how can i avoid error :ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides In-Reply-To: References: Message-ID: <20150303101648.GK25455@redhat.com> On Tue, 03 Mar 2015, Ben .T.George wrote: >HI > >i am getting below error while trying* ipa trust-fetch-domains >kwttestdc.com * > >ipa: ERROR: AD domain controller complains about communication sequence. It >may mean unsynchronized time on both sides > >time is synced through ntpd and there is no time difference between ad ans >IPA server > >but if i am getting > >[root at kwtpocpbis01 ~]# ipa trust-fetch-domains kwttestdc.com >ipa: ERROR: AD domain controller complains about communication sequence. It >may mean unsynchronized time on both sides, for example >[root at kwtpocpbis01 ~]# ipa trustdomain-find "kwttestdc.com" > Domain name: kwttestdc.com > Domain NetBIOS name: KWTTESTDC > Domain Security Identifier: S-1-5-21-3321666283-4099738591-2270060621 > Domain enabled: True >---------------------------- >Number of entries returned 1 > >pleaswe help me solve this issue First fix the problems like I referred in the previous discussion, this one is a direct consequence of non-working trust. -- / Alexander Bokovoy From bentech4you at gmail.com Tue Mar 3 10:33:37 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 3 Mar 2015 13:33:37 +0300 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: <20150302202745.GJ25455@redhat.com> References: <20150302191051.GG25455@redhat.com> <20150302201112.GH25455@redhat.com> <20150302202745.GJ25455@redhat.com> Message-ID: HI thanks for the replay. iwas going through the replays and find that you suggested to check firewall and DNS *[root at kwtpocpbis01 ~]# systemctl status firewalld* *firewalld.service - firewalld - dynamic firewall daemon* * Loaded: loaded (/usr/lib/systemd/system/firewalld.service; disabled)* * Active: inactive (dead)* *[root at kwtpocpbis01 ~]# systemctl status iptables* *iptables.service - IPv4 firewall with iptables* * Loaded: loaded (/usr/lib/systemd/system/iptables.service; disabled)* * Active: inactive (dead)* *[root at kwtpocpbis01 ~]# sestatus* *SELinux status: disabled* >From windows (AD) nslookup command like below: *C:\Windows\system32>nslookup.exe* *Default Server: kwttestdc001.kwttestdc.com * *Address: 172.16.104.231* *> set type=srv* *> _ldap._tcp.kwttestdc.com * *Server: kwttestdc001.kwttestdc.com * *Address: 172.16.104.231* *_ldap._tcp.kwttestdc.com SRV service location:* * priority = 0* * weight = 100* * port = 389* * svr hostname = kwttestdc001.kwttestdc.com * *kwttestdc001.kwttestdc.com internet address = 172.16.104.231* *> _ldap._tcp.solipa.local* *Server: kwttestdc001.kwttestdc.com * *Address: 172.16.104.231* *Non-authoritative answer:* *_ldap._tcp.solipa.local SRV service location:* * priority = 0* * weight = 100* * port = 389* * svr hostname = kwtpocpbis01.solipa.local* *kwtpocpbis01.solipa.local internet address = 172.16.107.244* Thsi is from IPA server *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.solipa.local* *; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> SRV _ldap._tcp.solipa.local* *;; global options: +cmd* *;; Got answer:* *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 65274* *;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* *;; OPT PSEUDOSECTION:* *; EDNS: version: 0, flags:; udp: 4000* *;; QUESTION SECTION:* *;_ldap._tcp.solipa.local. IN SRV* *;; ANSWER SECTION:* *_ldap._tcp.solipa.local. 81125 IN SRV 0 100 389 kwtpocpbis01.solipa.local.* *;; ADDITIONAL SECTION:* *kwtpocpbis01.solipa.local. 1101 IN A 172.16.107.244* *;; Query time: 0 msec* *;; SERVER: 172.16.104.231#53(172.16.104.231)* *;; WHEN: Tue Mar 03 13:28:35 AST 2015* *;; MSG SIZE rcvd: 113* *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.kwttestdc.com * *; <<>> DiG 9.9.4-RedHat-9.9.4-14.el7 <<>> SRV _ldap._tcp.kwttestdc.com * *;; global options: +cmd* *;; Got answer:* *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 43860* *;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* *;; OPT PSEUDOSECTION:* *; EDNS: version: 0, flags:; udp: 4000* *;; QUESTION SECTION:* *;_ldap._tcp.kwttestdc.com . IN SRV* *;; ANSWER SECTION:* *_ldap._tcp.kwttestdc.com . 600 IN SRV 0 100 389 kwttestdc001.kwttestdc.com .* *;; ADDITIONAL SECTION:* *kwttestdc001.kwttestdc.com . 3600 IN A 172.16.104.231* *;; Query time: 0 msec* *;; SERVER: 172.16.104.231#53(172.16.104.231)* *;; WHEN: Tue Mar 03 13:28:43 AST 2015* *;; MSG SIZE rcvd: 115* and there is no replica server too Regards, Ben On Mon, Mar 2, 2015 at 11:27 PM, Alexander Bokovoy wrote: > On Mon, 02 Mar 2015, Ben .T.George wrote: > >> Hi please find below output >> >> [root at kwttstfreipa01 ~]# kinit admin >> Password for admin at SOLIPA.LOCAL: >> >> [root at kwttstfreipa01 ~]# id admin >> uid=756800000(admin) gid=756800000(admins) groups=756800000(admins) >> >> >> [root at kwttstfreipa01 ~]# KRB5_TRACE=/dev/stderr kvno -S cifs >> kwttestdc001.kwttestdc.com >> [16898] 1425327238.662939: Convert service cifs (service with host as >> instance) on host kwttestdc001.kwttestdc.com to principal >> [16898] 1425327238.663650: Remote host after forward canonicalization: >> kwttestdc001.kwttestdc.com >> [16898] 1425327238.663684: Remote host after reverse DNS processing: >> kwttestdc001.kwttestdc.com >> [16898] 1425327238.663728: Get host realm for kwttestdc001.kwttestdc.com >> [16898] 1425327238.663742: Use local host kwttestdc001.kwttestdc.com to >> get >> host realm >> [16898] 1425327238.663749: Look up kwttestdc001.kwttestdc.com in the >> domain_realm map >> [16898] 1425327238.663757: Look up .kwttestdc.com in the domain_realm map >> [16898] 1425327238.663764: Temporary realm is KWTTESTDC.COM >> [16898] 1425327238.663771: Got realm KWTTESTDC.COM for host >> kwttestdc001.kwttestdc.com >> [16898] 1425327238.663792: Got service principal cifs/ >> kwttestdc001.kwttestdc.com at KWTTESTDC.COM >> [16898] 1425327238.663818: Getting credentials admin at SOLIPA.LOCAL -> >> cifs/ >> kwttestdc001.kwttestdc.com at KWTTESTDC.COM using ccache >> KEYRING:persistent:0:0 >> [16898] 1425327238.664257: Retrieving admin at SOLIPA.LOCAL -> cifs/ >> kwttestdc001.kwttestdc.com at KWTTESTDC.COM from KEYRING:persistent:0:0 with >> result: -1765328243/Matching credential not found >> [16898] 1425327238.664381: Retrieving admin at SOLIPA.LOCAL -> >> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 with >> result: >> -1765328243/Matching credential not found >> [16898] 1425327238.664500: Retrieving admin at SOLIPA.LOCAL -> >> krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL from KEYRING:persistent:0:0 with result: >> 0/Success >> [16898] 1425327238.664516: Starting with TGT for client realm: >> admin at SOLIPA.LOCAL -> krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL >> [16898] 1425327238.664608: Retrieving admin at SOLIPA.LOCAL -> >> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 with >> result: >> -1765328243/Matching credential not found >> [16898] 1425327238.664622: Requesting TGT krbtgt/KWTTESTDC.COM at SOLIPA. >> LOCAL >> using TGT krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL >> [16898] 1425327238.664690: Generated subkey for TGS request: >> aes256-cts/F74E >> [16898] 1425327238.664818: etypes requested in TGS request: aes256-cts, >> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts >> [16898] 1425327238.665062: Encoding request body and padata into FAST >> request >> [16898] 1425327238.665256: Sending request (1486 bytes) to SOLIPA.LOCAL >> [16898] 1425327238.665597: Initiating TCP connection to stream >> 172.16.107.250:88 >> [16898] 1425327238.665802: Sending TCP request to stream >> 172.16.107.250:88 >> [16898] 1425327238.673061: Received answer from stream 172.16.107.250:88 >> [16898] 1425327238.673285: Response was from master KDC >> [16898] 1425327238.673342: Decoding FAST response >> [16898] 1425327238.673574: FAST reply key: aes256-cts/9134 >> [16898] 1425327238.673650: TGS reply is for admin at SOLIPA.LOCAL -> >> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL with session key aes256-cts/4F6F >> [16898] 1425327238.673691: TGS request result: 0/Success >> [16898] 1425327238.673753: Removing admin at SOLIPA.LOCAL -> >> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL from KEYRING:persistent:0:0 >> [16898] 1425327238.673768: Storing admin at SOLIPA.LOCAL -> >> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL in KEYRING:persistent:0:0 >> [16898] 1425327238.673933: Received TGT for service realm: >> krbtgt/KWTTESTDC.COM at SOLIPA.LOCAL >> [16898] 1425327238.673950: Requesting tickets for cifs/ >> kwttestdc001.kwttestdc.com at KWTTESTDC.COM, referrals on >> [16898] 1425327238.673998: Generated subkey for TGS request: >> aes256-cts/8623 >> [16898] 1425327238.674084: etypes requested in TGS request: aes256-cts, >> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts >> [16898] 1425327238.674238: Encoding request body and padata into FAST >> request >> [16898] 1425327238.674395: Sending request (1531 bytes) to KWTTESTDC.COM >> [16898] 1425327238.676086: Resolving hostname kwttestdc001.kwttestdc.com. >> [16898] 1425327238.678096: Resolving hostname kwttestdc001.kwttestdc.com. >> [16898] 1425327238.678907: Initiating TCP connection to stream >> 172.16.104.231:88 >> [16898] 1425327238.679404: Sending TCP request to stream >> 172.16.104.231:88 >> [16898] 1425327238.681292: Received answer from stream 172.16.104.231:88 >> [16898] 1425327238.682088: Response was not from master KDC >> [16898] 1425327238.682142: TGS request result: -1765328372/KDC policy >> rejects request >> [16898] 1425327238.682161: Requesting tickets for cifs/ >> kwttestdc001.kwttestdc.com at KWTTESTDC.COM, referrals off >> [16898] 1425327238.682212: Generated subkey for TGS request: >> aes256-cts/50DA >> [16898] 1425327238.682283: etypes requested in TGS request: aes256-cts, >> aes128-cts, des3-cbc-sha1, rc4-hmac, camellia128-cts, camellia256-cts >> [16898] 1425327238.682391: Encoding request body and padata into FAST >> request >> [16898] 1425327238.682499: Sending request (1531 bytes) to KWTTESTDC.COM >> [16898] 1425327238.683871: Resolving hostname kwttestdc001.kwttestdc.com. >> [16898] 1425327238.684756: Resolving hostname kwttestdc001.kwttestdc.com. >> [16898] 1425327238.685461: Initiating TCP connection to stream >> 172.16.104.231:88 >> [16898] 1425327238.685864: Sending TCP request to stream >> 172.16.104.231:88 >> [16898] 1425327238.687136: Received answer from stream 172.16.104.231:88 >> [16898] 1425327238.687793: Response was not from master KDC >> [16898] 1425327238.687832: TGS request result: -1765328372/KDC policy >> rejects request >> kvno: KDC policy rejects request while getting credentials for cifs/ >> kwttestdc001.kwttestdc.com at KWTTESTDC.COM >> > Last line tells that trust is not working. > > Read discussion in this thread: > https://www.redhat.com/archives/freeipa-users/2015-February/msg00397.html > and follow recommendations there, it was just last week here. > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 3 10:37:45 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 Mar 2015 12:37:45 +0200 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: References: <20150302191051.GG25455@redhat.com> <20150302201112.GH25455@redhat.com> <20150302202745.GJ25455@redhat.com> Message-ID: <20150303103745.GM25455@redhat.com> On Tue, 03 Mar 2015, Ben .T.George wrote: >HI > >thanks for the replay. > >iwas going through the replays and find that you suggested to check >firewall and DNS What do you see in /var/log/httpd/error_log as result of dumping netr_LogonControl2Ex structure? You never showed that. Like in https://www.redhat.com/archives/freeipa-users/2015-February/msg00404.html -- / Alexander Bokovoy From bentech4you at gmail.com Tue Mar 3 10:45:39 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 3 Mar 2015 13:45:39 +0300 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: <20150303103745.GM25455@redhat.com> References: <20150302191051.GG25455@redhat.com> <20150302201112.GH25455@redhat.com> <20150302202745.GJ25455@redhat.com> <20150303103745.GM25455@redhat.com> Message-ID: HI Alexander, please find below error_log [Tue Mar 03 11:32:15.786252 2015] [suexec:notice] [pid 4754] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Mar 03 11:32:15.936866 2015] [auth_digest:notice] [pid 4754] AH01757: generating secret for digest authentication ... [Tue Mar 03 11:32:15.937438 2015] [lbmethod_heartbeat:notice] [pid 4754] AH02282: No slotmem from mod_heartmonitor [Tue Mar 03 11:32:15.942887 2015] [mpm_prefork:notice] [pid 4754] AH00163: Apache/2.4.6 (CentOS) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.4 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations [Tue Mar 03 11:32:15.942907 2015] [core:notice] [pid 4754] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Tue Mar 03 11:32:18.292758 2015] [:error] [pid 4757] ipa: INFO: *** PROCESS START *** [Tue Mar 03 11:32:18.294084 2015] [:error] [pid 4756] ipa: INFO: *** PROCESS START *** [Tue Mar 03 11:33:30.826970 2015] [mpm_prefork:notice] [pid 4754] AH00170: caught SIGWINCH, shutting down gracefully [Tue Mar 03 11:33:31.977789 2015] [suexec:notice] [pid 5227] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Mar 03 11:33:32.135520 2015] [auth_digest:notice] [pid 5227] AH01757: generating secret for digest authentication ... [Tue Mar 03 11:33:32.136094 2015] [lbmethod_heartbeat:notice] [pid 5227] AH02282: No slotmem from mod_heartmonitor [Tue Mar 03 11:33:32.140750 2015] [mpm_prefork:notice] [pid 5227] AH00163: Apache/2.4.6 (CentOS) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.4 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations [Tue Mar 03 11:33:32.140775 2015] [core:notice] [pid 5227] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Tue Mar 03 11:33:34.118337 2015] [:error] [pid 5229] ipa: INFO: *** PROCESS START *** [Tue Mar 03 11:33:34.216507 2015] [:error] [pid 5229] ipa: INFO: host/kwtpocpbis01.solipa.local at SOLIPA.LOCAL: ping(version=u'2.51'): SUCCESS [Tue Mar 03 11:33:34.260966 2015] [:error] [pid 5229] ipa: INFO: host/kwtpocpbis01.solipa.local at SOLIPA.LOCAL: env(None, server=True, version=u'2.0'): SUCCESS [Tue Mar 03 11:33:34.364965 2015] [:error] [pid 5230] ipa: INFO: *** PROCESS START *** [Tue Mar 03 11:33:34.533853 2015] [:error] [pid 5229] ipa: INFO: host/kwtpocpbis01.solipa.local at SOLIPA.LOCAL: host_mod(u'kwtpocpbis01.solipa.local', ipasshpubkey=(u'ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQCva/juHXDSpThhcaVgntCgycTCI6sDWXHPAcr6KsRhPeiXQ4ndW4BtUIT6EPLR1AHO8vUsZ7/rY3Ug2KtGdYLoJYDfuJkvePTGJsMpFnwlk4yfd/GNBqeN4dRYBs6iFUGXc1VWyvCEcU4zvdAmySVz6cK37JS5EGj2uekpxt9lQ4S1/QxaGtzmTscjBPkyGc8UXVv/9fqlnQRwmA1HeqYkYImDlQ4IXN3sRs1kd3nYyrJjX/DC14KvXfVK7Wshcnrzg7K99kb4qvl2OQARMGUk17eG80cQMPgn4obALKMviQDgZI11NCZxdOWaATXCfKbOQoVotN/ZHRW5EwvouOh3', u'ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBMWd02Oy89LapjVTyJIAMs18M+7T4R1jyxw3S0TsLb/zgO581bXjiFllcncXxoH1hUrFgw9rnjl3jJEz/l7jsZQ='), updatedns=False, version=u'2.26'): SUCCESS [Tue Mar 03 11:59:31.106076 2015] [mpm_prefork:notice] [pid 5227] AH00170: caught SIGWINCH, shutting down gracefully [Tue Mar 03 11:59:32.257238 2015] [suexec:notice] [pid 5640] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Mar 03 11:59:32.422464 2015] [auth_digest:notice] [pid 5640] AH01757: generating secret for digest authentication ... [Tue Mar 03 11:59:32.423101 2015] [lbmethod_heartbeat:notice] [pid 5640] AH02282: No slotmem from mod_heartmonitor [Tue Mar 03 11:59:32.428874 2015] [mpm_prefork:notice] [pid 5640] AH00163: Apache/2.4.6 (CentOS) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.4 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations [Tue Mar 03 11:59:32.428900 2015] [core:notice] [pid 5640] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Tue Mar 03 11:59:34.007708 2015] [:error] [pid 5642] ipa: INFO: *** PROCESS START *** [Tue Mar 03 11:59:34.011510 2015] [:error] [pid 5643] ipa: INFO: *** PROCESS START *** [Tue Mar 03 12:00:41.123161 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: dnszone_add(u'kwttestdc.com', idnssoamname=u' kwttestdc001.kwttestdc.com', idnssoarname=u'ben\\\\.george.alshaya.com.', idnssoaserial=1425373240, idnssoarefresh=3600, idnssoaretry=900, idnssoaexpire=1209600, idnssoaminimum=3600, idnsupdatepolicy=u'grant SOLIPA.LOCAL krb5-self * A; grant SOLIPA.LOCAL krb5-self * AAAA; grant SOLIPA.LOCAL krb5-self * SSHFP;', idnsallowdynupdate=False, idnsallowquery=u'any;', idnsallowtransfer=u'none;', idnsforwarders=(u'172.16.104.231',), idnsforwardpolicy=u'only', force=True, ip_address=u'172.16.104.231', all=False, raw=False, version=u'2.65'): SUCCESS [Tue Mar 03 12:08:04.303874 2015] [:error] [pid 5643] ipa: INFO: admin at SOLIPA.LOCAL: trust_add(u'kwttestdc.com', trust_type=u'ad', realm_admin=u'adm-ben.george', realm_passwd=u'********', all=False, raw=False, version=u'2.65'): SUCCESS [Tue Mar 03 12:08:33.999720 2015] [:error] [pid 5648] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:08:47.551853 2015] [:error] [pid 5646] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:09:34.575636 2015] [:error] [pid 5645] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:09:37.139651 2015] [:error] [pid 5648] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:09:38.097289 2015] [:error] [pid 5644] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:09:38.661205 2015] [:error] [pid 5646] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:10:14.552788 2015] [:error] [pid 5645] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:10:36.286938 2015] [:error] [pid 5648] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:11:51.977242 2015] [:error] [pid 5644] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:11:52.744281 2015] [:error] [pid 5646] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:11:53.469238 2015] [:error] [pid 5742] SSL Library Error: -12271 SSL client cannot verify your certificate [Tue Mar 03 12:12:47.169966 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 12:14:47.496828 2015] [:error] [pid 5643] ipa: INFO: admin at SOLIPA.LOCAL: trustdomain_find(u'kwttestdc.com', None, all=False, raw=False, version=u'2.65', pkey_only=False): SUCCESS [Tue Mar 03 12:17:42.475926 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 12:17:53.987719 2015] [:error] [pid 5643] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'S-1-5-21-3321666283-4099738591-2270060621', rights=False, all=False, raw=False, version=u'2.65'): NotFound [Tue Mar 03 12:18:00.631755 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 12:21:16.841559 2015] [:error] [pid 5648] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate [Tue Mar 03 12:21:23.288682 2015] [:error] [pid 5646] SSL Library Error: -12195 Peer does not recognize and trust the CA that issued your certificate [Tue Mar 03 12:21:34.492765 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: i18n_messages(): SUCCESS [Tue Mar 03 12:21:34.498549 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: config_show(): SUCCESS [Tue Mar 03 12:21:34.518631 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: user_find(None, whoami=True, all=True): SUCCESS [Tue Mar 03 12:21:34.519030 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: env(None): SUCCESS [Tue Mar 03 12:21:34.521096 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: dns_is_enabled(): SUCCESS [Tue Mar 03 12:21:34.523237 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: trustconfig_show(): SUCCESS [Tue Mar 03 12:21:34.523490 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch(({u'params': [[], {}], u'method': u'i18n_messages'}, {u'params': [[], {}], u'method': u'config_show'}, {u'params': [[], {u'all': True, u'whoami': True}], u'method': u'user_find'}, {u'params': [[], {}], u'method': u'env'}, {u'params': [[], {}], u'method': u'dns_is_enabled'}, {u'params': [[], {}], u'method': u'trustconfig_show'})): SUCCESS [Tue Mar 03 12:21:34.667686 2015] [:error] [pid 5643] ipa: INFO: admin at SOLIPA.LOCAL: json_metadata(None, None, object=u'all'): SUCCESS [Tue Mar 03 12:21:35.002795 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: json_metadata(None, None, command=u'all'): SUCCESS [Tue Mar 03 12:21:35.607923 2015] [:error] [pid 5643] ipa: INFO: admin at SOLIPA.LOCAL: user_find(u'', sizelimit=0, pkey_only=True): SUCCESS [Tue Mar 03 12:21:35.695390 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: user_show(u'admin', no_members=True): SUCCESS [Tue Mar 03 12:21:35.695725 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch(({u'params': [[u'admin'], {u'no_members': True}], u'method': u'user_show'},)): SUCCESS [Tue Mar 03 12:21:41.369089 2015] [:error] [pid 5643] ipa: INFO: admin at SOLIPA.LOCAL: role_find(u'', sizelimit=0, pkey_only=True): SUCCESS [Tue Mar 03 12:21:41.426571 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: role_show(u'IT Security Specialist', no_members=True): SUCCESS [Tue Mar 03 12:21:41.428475 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: role_show(u'IT Specialist', no_members=True): SUCCESS [Tue Mar 03 12:21:41.430391 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: role_show(u'Security Architect', no_members=True): SUCCESS [Tue Mar 03 12:21:41.432380 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: role_show(u'User Administrator', no_members=True): SUCCESS [Tue Mar 03 12:21:41.434401 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch: role_show(u'helpdesk', no_members=True): SUCCESS [Tue Mar 03 12:21:41.434791 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: batch(({u'params': [[u'IT Security Specialist'], {u'no_members': True}], u'method': u'role_show'}, {u'params': [[u'IT Specialist'], {u'no_members': True}], u'method': u'role_show'}, {u'params': [[u'Security Architect'], {u'no_members': True}], u'method': u'role_show'}, {u'params': [[u'User Administrator'], {u'no_members': True}], u'method': u'role_show'}, {u'params': [[u'helpdesk'], {u'no_members': True}], u'method': u'role_show'})): SUCCESS [Tue Mar 03 12:21:44.887796 2015] [:error] [pid 5643] ipa: INFO: admin at SOLIPA.LOCAL: trust_find(u'', sizelimit=0, pkey_only=True): SUCCESS [Tue Mar 03 12:21:46.551033 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: trust_show(u'kwttestdc.com', rights=True, all=True): SUCCESS [Tue Mar 03 12:21:50.277095 2015] [:error] [pid 5643] ipa: INFO: admin at SOLIPA.LOCAL: trustdomain_find(u'kwttestdc.com', u'', sizelimit=0): SUCCESS [Tue Mar 03 12:23:40.322942 2015] [:error] [pid 5642] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 12:24:33.747970 2015] [mpm_prefork:notice] [pid 5640] AH00170: caught SIGWINCH, shutting down gracefully [Tue Mar 03 12:24:34.897235 2015] [suexec:notice] [pid 5928] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Mar 03 12:24:35.054320 2015] [auth_digest:notice] [pid 5928] AH01757: generating secret for digest authentication ... [Tue Mar 03 12:24:35.054895 2015] [lbmethod_heartbeat:notice] [pid 5928] AH02282: No slotmem from mod_heartmonitor [Tue Mar 03 12:24:35.062223 2015] [mpm_prefork:notice] [pid 5928] AH00163: Apache/2.4.6 (CentOS) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.4 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations [Tue Mar 03 12:24:35.062253 2015] [core:notice] [pid 5928] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Tue Mar 03 12:24:36.548124 2015] [:error] [pid 5930] ipa: INFO: *** PROCESS START *** [Tue Mar 03 12:24:36.705261 2015] [:error] [pid 5931] ipa: INFO: *** PROCESS START *** [Tue Mar 03 12:24:40.680284 2015] [:error] [pid 5930] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 12:27:09.118008 2015] [:error] [pid 5931] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 12:30:11.090164 2015] [:error] [pid 5930] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 12:31:41.802566 2015] [:error] [pid 5931] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 12:59:20.926434 2015] [:error] [pid 5930] ipa: INFO: admin at SOLIPA.LOCAL: group_add(u'ad_users_external', description=u' kwttestdc.com users external map', nonposix=False, external=True, all=False, raw=False, version=u'2.65', no_members=False): SUCCESS [Tue Mar 03 12:59:37.431092 2015] [:error] [pid 5931] ipa: INFO: admin at SOLIPA.LOCAL: group_add(u'ad_users', description=u'kwttestdc.com users', nonposix=False, external=False, all=False, raw=False, version=u'2.65', no_members=False): SUCCESS [Tue Mar 03 12:59:51.013947 2015] [:error] [pid 5930] ipa: WARNING: Search on AD DC KWTTESTDC001.kwttestdc.com:3268 failed with: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC policy rejects request) [Tue Mar 03 12:59:51.016172 2015] [:error] [pid 5930] ipa: INFO: admin at SOLIPA.LOCAL: group_add_member(u'ad_users_external', ipaexternalmember=(u'KWTTESTDC\\\\Domain Users',), all=False, raw=False, version=u'2.65', no_members=False): SUCCESS [Tue Mar 03 13:02:26.166599 2015] [:error] [pid 5931] ipa: WARNING: Search on AD DC KWTTESTDC001.kwttestdc.com:3268 failed with: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC policy rejects request) [Tue Mar 03 13:02:26.168967 2015] [:error] [pid 5931] ipa: INFO: admin at SOLIPA.LOCAL: group_add_member(u'ad_users_external', ipaexternalmember=(u'KWTTESTDC\\\\Domain Users',), all=False, raw=False, version=u'2.65', no_members=False): SUCCESS [Tue Mar 03 13:03:01.402913 2015] [mpm_prefork:notice] [pid 5928] AH00170: caught SIGWINCH, shutting down gracefully [Tue Mar 03 13:03:02.552272 2015] [suexec:notice] [pid 6259] AH01232: suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Tue Mar 03 13:03:02.717818 2015] [auth_digest:notice] [pid 6259] AH01757: generating secret for digest authentication ... [Tue Mar 03 13:03:02.718405 2015] [lbmethod_heartbeat:notice] [pid 6259] AH02282: No slotmem from mod_heartmonitor [Tue Mar 03 13:03:02.722947 2015] [mpm_prefork:notice] [pid 6259] AH00163: Apache/2.4.6 (CentOS) mod_auth_kerb/5.4 mod_nss/2.4.6 NSS/3.15.4 Basic ECC mod_wsgi/3.4 Python/2.7.5 configured -- resuming normal operations [Tue Mar 03 13:03:02.722971 2015] [core:notice] [pid 6259] AH00094: Command line: '/usr/sbin/httpd -D FOREGROUND' [Tue Mar 03 13:03:04.176015 2015] [:error] [pid 6261] ipa: INFO: *** PROCESS START *** [Tue Mar 03 13:03:04.372111 2015] [:error] [pid 6262] ipa: INFO: *** PROCESS START *** [Tue Mar 03 13:04:11.740356 2015] [:error] [pid 6261] ipa: INFO: admin at SOLIPA.LOCAL: trust_add(u'kwttestdc.com', trust_type=u'ad', realm_admin=u'adm-ben.george', realm_passwd=u'********', all=False, raw=False, version=u'2.65'): SUCCESS [Tue Mar 03 13:04:39.190084 2015] [:error] [pid 6262] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError [Tue Mar 03 13:05:02.725135 2015] [:error] [pid 6261] ipa: INFO: admin at SOLIPA.LOCAL: trust_fetch_domains(u'kwttestdc.com', rights=False, all=False, raw=False, version=u'2.65'): RemoteRetrieveError the last 2 lines only getting updated while giving ipa trust-fetch-domains " kwttestdc.com" On Tue, Mar 3, 2015 at 1:37 PM, Alexander Bokovoy wrote: > On Tue, 03 Mar 2015, Ben .T.George wrote: > >> HI >> >> thanks for the replay. >> >> iwas going through the replays and find that you suggested to check >> firewall and DNS >> > What do you see in /var/log/httpd/error_log as result of dumping > netr_LogonControl2Ex structure? You never showed that. > > Like in https://www.redhat.com/archives/freeipa-users/2015- > February/msg00404.html > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 3 11:04:22 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 Mar 2015 13:04:22 +0200 Subject: [Freeipa-users] ipa group-add-member failed In-Reply-To: References: <20150302191051.GG25455@redhat.com> <20150302201112.GH25455@redhat.com> <20150302202745.GJ25455@redhat.com> <20150303103745.GM25455@redhat.com> Message-ID: <20150303110422.GN25455@redhat.com> On Tue, 03 Mar 2015, Ben .T.George wrote: >HI Alexander, >please find below error_log Sorry Ben, this is unusable. You need to follow http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust, where it asks you to enable debugging in smb.conf.empty and re-establish trust. Given that trust is not working, you need to re-establish it anyway. -- / 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 mkosek at redhat.com Tue Mar 3 12:06:15 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Mar 2015 13:06:15 +0100 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: <54F5A3B7.6010308@redhat.com> On 02/28/2015 07:18 AM, 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 With regards to PKI and SELinux, I can only recall that pki-selinux package required the most up to date selinux-policy package, otherwise it printed SELinux related error during installation. Your bug also reminds me of https://fedorahosted.org/pki/ticket/1282 which was caused by HTTPD not having some of the modules (AJP proxy module) enabled. Can you please check /var/log/httpd/error_log if there are any related interesting error messages? Thanks, Martin From mkosek at redhat.com Tue Mar 3 12:22:33 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Mar 2015 13:22:33 +0100 Subject: [Freeipa-users] Auto disable users In-Reply-To: <1192409290.25294.1425357528157.JavaMail.zimbra@cctus.com> References: <1192409290.25294.1425357528157.JavaMail.zimbra@cctus.com> Message-ID: <54F5A789.3050007@redhat.com> On 03/03/2015 05:38 AM, Jason Prouty wrote: > > > Is there a method to auto disable users who have logged in 90 days. > I have a security requirement to auto disable users who have not logged in after 90 days. > There is no such facility implemented in vanilla FreeIPA. I think there was another user request, but I could not find any Bugzilla or Trac ticket. I see 3 options how to do what you propose: 1) Implement a cron script that will LDAP search for such users and disable them when the account is inactive for too long (based on krblastsuccessfulauth). 2) Configure 389 Directory Server Account Policy Plug-In to do what you want. This is it's doc: https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/account-policy-plugin.html However, I am slightly afraid that it may collide with other FreeIPA user lockout or password policy plugins. CCing Ludwig and Thierry for reference. 3) File RFE and work with FreeIPA development team to help and implement an extension of the lockout policy, to implement what you want. Martin From munna.hadoop at gmail.com Tue Mar 3 13:42:39 2015 From: munna.hadoop at gmail.com (Hadoop Solutions) Date: Tue, 3 Mar 2015 21:42:39 +0800 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: <54F5A3B7.6010308@redhat.com> References: <54F1360B.2080807@redhat.com> <54F15D9E.10806@redhat.com> <54F5A3B7.6010308@redhat.com> Message-ID: Hi Martin, please find the below HTTPD error logs [Sun Mar 01 04:27:57 2015] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 [Sun Mar 01 04:27:57 2015] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Sun Mar 01 04:27:57 2015] [warn] Init: ( sv2lxbdp2kfstd02.corp.equinix.com:443) You configured HTTP(80) on the standard HTTPS(443) port! [Sun Mar 01 04:29:02 2015] [notice] SELinux policy enabled; httpd running as context unconfined_u:system_r:httpd_t:s0 [Sun Mar 01 04:29:02 2015] [notice] suEXEC mechanism enabled (wrapper: /usr/sbin/suexec) [Sun Mar 01 04:29:03 2015] [warn] Init: ( sv2lxbdp2kfstd02.corp.equinix.com:443) You configured HTTP(80) on the standard HTTPS(443) port! Thanks, Shaik On 3 March 2015 at 20:06, Martin Kosek wrote: > On 02/28/2015 07:18 AM, 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 > > With regards to PKI and SELinux, I can only recall that pki-selinux package > required the most up to date selinux-policy package, otherwise it printed > SELinux related error during installation. > > Your bug also reminds me of > https://fedorahosted.org/pki/ticket/1282 > which was caused by HTTPD not having some of the modules (AJP proxy module) > enabled. Can you please check /var/log/httpd/error_log if there are any > related > interesting error messages? > > Thanks, > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From edewata at redhat.com Tue Mar 3 14:19:45 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Tue, 03 Mar 2015 21:19:45 +0700 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: References: <54F1360B.2080807@redhat.com> Message-ID: <54F5C301.60604@redhat.com> On 2/28/2015 1:01 PM, Hadoop Solutions wrote: > Hi Rob, > > please find the attached log of /var/log/ipaserver-install.log > > kindly let me know the solution for this.. > > Thanks, > Shaik Hi, I see this near the bottom of the ipaserver-install.log. ############################################# Attempting to connect to: sv2lxdpdsedi02.corp.equinix.com:9445 Connected. Posting Query = https://sv2lxdpdsedi02.corp.equinix.com:9445//ca/admin/console/config/wizard?p=9&op=next&xml=true&host=sv2lxdpdsedi02.corp.equinix.com&port=7389&binddn=cn%3DDirectory+Manager&__bindpwd=XXXXXXXX&basedn=o%3Dipaca&database=ipaca&display=%24displayStr RESPONSE STATUS: HTTP/1.1 404 Not Found RESPONSE HEADER: Server: Apache-Coyote/1.1 RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 RESPONSE HEADER: Date: Sat, 28 Feb 2015 05:57:35 GMT RESPONSE HEADER: Connection: close ERROR: unable to parse xml ERROR XML = ERROR: Tag='updateStatus' has no values Error in LdapConnectionPanel(): updateStatus value is null ERROR: ConfigureCA: LdapConnectionPanel() failure ERROR: unable to create CA ####################################################################### 2015-02-28T05:57:35Z DEBUG stderr=[Fatal Error] :-1:-1: Premature end of file. org.xml.sax.SAXParseException: Premature end of file. at org.apache.xerces.parsers.DOMParser.parse(xerces-j2-2.7.1.jar.so) at org.apache.xerces.jaxp.DocumentBuilderImpl.parse(xerces-j2-2.7.1.jar.so) at javax.xml.parsers.DocumentBuilder.parse(libgcj.so.10) at ParseXML.parse(ParseXML.java:258) at ConfigureCA.getStatus(ConfigureCA.java:205) at ConfigureCA.checkStatus(ConfigureCA.java:221) at ConfigureCA.checkStatus(ConfigureCA.java:216) at ConfigureCA.LdapConnectionPanel(ConfigureCA.java:510) at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1225) at ConfigureCA.main(ConfigureCA.java:1672) Could you post the /var/log/pki-ca/debug? Thanks. -- Endi S. Dewata From mkosek at redhat.com Tue Mar 3 14:27:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Mar 2015 15:27:16 +0100 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: References: <54F1360B.2080807@redhat.com> <54F15D9E.10806@redhat.com> <54F5A3B7.6010308@redhat.com> Message-ID: <54F5C4C4.8050907@redhat.com> I do not think these are related, this should be just mod_ssl, thinking that port 443 does not use SSL (slightly related bug - https://bugzilla.redhat.com/show_bug.cgi?id=1023168). If you uninstall mod_ssl, the warning should disappear. I see Endi just replied in other part of this thread, so let us continue there. Martin On 03/03/2015 02:42 PM, Hadoop Solutions wrote: > Hi Martin, > > please find the below HTTPD error logs > > > [Sun Mar 01 04:27:57 2015] [notice] SELinux policy enabled; httpd running > as context unconfined_u:system_r:httpd_t:s0 > [Sun Mar 01 04:27:57 2015] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Sun Mar 01 04:27:57 2015] [warn] Init: ( > sv2lxbdp2kfstd02.corp.equinix.com:443) You configured HTTP(80) on the > standard HTTPS(443) port! > [Sun Mar 01 04:29:02 2015] [notice] SELinux policy enabled; httpd running > as context unconfined_u:system_r:httpd_t:s0 > [Sun Mar 01 04:29:02 2015] [notice] suEXEC mechanism enabled (wrapper: > /usr/sbin/suexec) > [Sun Mar 01 04:29:03 2015] [warn] Init: ( > sv2lxbdp2kfstd02.corp.equinix.com:443) You configured HTTP(80) on the > standard HTTPS(443) port! > > > > Thanks, > Shaik > > On 3 March 2015 at 20:06, Martin Kosek wrote: > >> On 02/28/2015 07:18 AM, 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 >> >> With regards to PKI and SELinux, I can only recall that pki-selinux package >> required the most up to date selinux-policy package, otherwise it printed >> SELinux related error during installation. >> >> Your bug also reminds me of >> https://fedorahosted.org/pki/ticket/1282 >> which was caused by HTTPD not having some of the modules (AJP proxy module) >> enabled. Can you please check /var/log/httpd/error_log if there are any >> related >> interesting error messages? >> >> Thanks, >> Martin >> > From veera.veluchamy at aspiresys.com Tue Mar 3 14:18:32 2015 From: veera.veluchamy at aspiresys.com (Veera Veluchamy) Date: Tue, 3 Mar 2015 14:18:32 +0000 Subject: [Freeipa-users] AD Group policy integration with FreeIPA Message-ID: Hi All, Is it possible to sync Active Directory group policy with FreeIPA server. If yes please tell the steps how to do that. Thanks, 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 jhrozek at redhat.com Tue Mar 3 14:32:23 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 3 Mar 2015 15:32:23 +0100 Subject: [Freeipa-users] AD Group policy integration with FreeIPA In-Reply-To: References: Message-ID: <20150303143223.GO4026@hendrix.arn.redhat.com> On Tue, Mar 03, 2015 at 02:18:32PM +0000, Veera Veluchamy wrote: > Hi All, > > Is it possible to sync Active Directory group policy with FreeIPA server. If yes please tell the steps how to do that. To accomplish what, access control? Currently it's not possible in the trust setup, I think, only when a Linux client running SSSD is directly enrolled to AD. From dpal at redhat.com Tue Mar 3 15:30:13 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Mar 2015 10:30:13 -0500 Subject: [Freeipa-users] AD Group policy integration with FreeIPA In-Reply-To: <20150303143223.GO4026@hendrix.arn.redhat.com> References: <20150303143223.GO4026@hendrix.arn.redhat.com> Message-ID: <54F5D385.1050804@redhat.com> On 03/03/2015 09:32 AM, Jakub Hrozek wrote: > On Tue, Mar 03, 2015 at 02:18:32PM +0000, Veera Veluchamy wrote: >> Hi All, >> >> Is it possible to sync Active Directory group policy with FreeIPA server. If yes please tell the steps how to do that. > To accomplish what, access control? > > Currently it's not possible in the trust setup, I think, only when a > Linux client running SSSD is directly enrolled to AD. > But you can accomplish access control in a different way. So what is the use case? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue Mar 3 15:34:08 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Mar 2015 10:34:08 -0500 Subject: [Freeipa-users] Auto disable users In-Reply-To: <54F5A789.3050007@redhat.com> References: <1192409290.25294.1425357528157.JavaMail.zimbra@cctus.com> <54F5A789.3050007@redhat.com> Message-ID: <54F5D470.4060801@redhat.com> On 03/03/2015 07:22 AM, Martin Kosek wrote: > On 03/03/2015 05:38 AM, Jason Prouty wrote: >> >> Is there a method to auto disable users who have logged in 90 days. >> I have a security requirement to auto disable users who have not logged in after 90 days. >> > There is no such facility implemented in vanilla FreeIPA. I think there was > another user request, but I could not find any Bugzilla or Trac ticket. > > I see 3 options how to do what you propose: > > 1) Implement a cron script that will LDAP search for such users and disable > them when the account is inactive for too long (based on krblastsuccessfulauth). Yes this is probably the most recommended approach. You do an ldap search on all the accounts that have krblastsuccessfulauth more than 90 days ago and then disable them one by one. Should be a very simple script to write. > > 2) Configure 389 Directory Server Account Policy Plug-In to do what you want. > This is it's doc: > > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/account-policy-plugin.html > > However, I am slightly afraid that it may collide with other FreeIPA user > lockout or password policy plugins. CCing Ludwig and Thierry for reference. > > 3) File RFE and work with FreeIPA development team to help and implement an > extension of the lockout policy, to implement what you want. > > Martin > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From gjn at gjn.priv.at Tue Mar 3 15:39:53 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 03 Mar 2015 16:39:53 +0100 Subject: [Freeipa-users] Error with kerberos users Message-ID: <9634801.f8Rp1ygRMO@techz> Hello, what is wrong on my setup? This is a "normal" install with ipa-server-install and ipa-client install on 5 KVM clients. CentOs 7 WARNING: Failed to create krb5 context for user with uid 225200001 for server bbs.gjn.prv Mar 3 16:28:22 smtp1 rpc.gssd[6912]: doing error downcall Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt5) Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 uid=225200001 enctypes=18,17,16,23,3,1,2 ' Mar 3 16:28:22 smtp1 rpc.gssd[6913]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt5) Mar 3 16:28:22 smtp1 rpc.gssd[6913]: process_krb5_upcall: service is '' Mar 3 16:28:22 smtp1 rpc.gssd[6913]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No Kerberos credentials available Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with uid 225200001 for server bbs.gjn.prv Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' being considered, with preferred realm 'GJN.PRV' Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' owned by 0, not 225200001 Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with uid 225200001 for server bbs.gjn.prv Mar 3 16:28:22 smtp1 rpc.gssd[6913]: Error doing scandir on directory '/run/user/225200001': No such file or directory Mar 3 16:28:22 smtp1 rpc.gssd[6913]: WARNING: Failed to create krb5 context for user with uid 225200001 for server bbs.gjn.prv Mar 3 16:28:22 smtp1 rpc.gssd[6913]: doing error downcall Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt5) Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 uid=225200001 enctypes=18,17,16,23,3,1,2 ' Mar 3 16:28:22 smtp1 rpc.gssd[6914]: handling krb5 upcall (/var/lib/nfs/rpc_pipefs/nfs/clnt5) Mar 3 16:28:22 smtp1 rpc.gssd[6914]: process_krb5_upcall: service is '' Mar 3 16:28:22 smtp1 rpc.gssd[6914]: ERROR: GSS-API: error in gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may provide more information) - No Kerberos credentials available Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with uid 225200001 for server bbs.gjn.prv Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' being considered, with preferred realm 'GJN.PRV' Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' owned by 0, not 225200001 Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with uid 225200001 for server bbs.gjn.prv Mar 3 16:28:22 smtp1 rpc.gssd[6914]: Error doing scandir on directory '/run/user/225200001': No such file or directory Mar 3 16:28:22 smtp1 rpc.gssd[6914]: WARNING: Failed to create krb5 context for user with uid 225200001 for server bbs.gjn.prv Thank's for answer. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From mkosek at redhat.com Tue Mar 3 16:02:09 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 03 Mar 2015 17:02:09 +0100 Subject: [Freeipa-users] Auto disable users In-Reply-To: <54F5D470.4060801@redhat.com> References: <1192409290.25294.1425357528157.JavaMail.zimbra@cctus.com> <54F5A789.3050007@redhat.com> <54F5D470.4060801@redhat.com> Message-ID: <54F5DB01.5060204@redhat.com> On 03/03/2015 04:34 PM, Dmitri Pal wrote: > On 03/03/2015 07:22 AM, Martin Kosek wrote: >> On 03/03/2015 05:38 AM, Jason Prouty wrote: >>> >>> Is there a method to auto disable users who have logged in 90 days. >>> I have a security requirement to auto disable users who have not logged in >>> after 90 days. >>> >> There is no such facility implemented in vanilla FreeIPA. I think there was >> another user request, but I could not find any Bugzilla or Trac ticket. >> >> I see 3 options how to do what you propose: >> >> 1) Implement a cron script that will LDAP search for such users and disable >> them when the account is inactive for too long (based on krblastsuccessfulauth). > > Yes this is probably the most recommended approach. > You do an ldap search on all the accounts that have krblastsuccessfulauth more > than 90 days ago and then disable them one by one. > Should be a very simple script to write. Yup, I just did a very simple test, to prove the point: 1) I have 2 users, with different successful log auth: # ipa user-find --all --raw | grep -iE "(dn:|krbLastSuccessfulAuth)" dn: uid=admin,cn=users,cn=accounts,dc=f21 krbLastSuccessfulAuth: 20150303155003Z dn: uid=fbar,cn=users,cn=accounts,dc=f21 krbLastSuccessfulAuth: 20150223114040Z 2) Now I search for acrtive users that did not log after March 1st: # ldapsearch -Y GSSAPI -b "cn=users,cn=accounts,dc=f21" "(&(!(nsaccountlock=TRUE))(krbLastSuccessfulAuth<=20150301000000Z))" dn krbLastSuccessfulAuth nsaccountlock SASL/GSSAPI authentication started SASL username: admin at F21 SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(!(nsaccountlock=TRUE))(krbLastSuccessfulAuth<=20150301000000Z)) # requesting: dn krbLastSuccessfulAuth nsaccountlock # # fbar, users, accounts, f21 dn: uid=fbar,cn=users,cn=accounts,dc=f21 krbLastSuccessfulAuth: 20150223114040Z # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 3) I disable such user: # ipa user-disable fbar ---------------------------- Disabled user account "fbar" ---------------------------- 4) Next search: # ldapsearch -Y GSSAPI -b "cn=users,cn=accounts,dc=f21" "(&(!(nsaccountlock=TRUE))(krbLastSuccessfulAuth<=20150301000000Z))" dn krbLastSuccessfulAuth nsaccountlock SASL/GSSAPI authentication started SASL username: admin at F21 SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(!(nsaccountlock=TRUE))(krbLastSuccessfulAuth<=20150301000000Z)) # requesting: dn krbLastSuccessfulAuth nsaccountlock # # search result search: 4 result: 0 Success # numResponses: 1 Martin From dpal at redhat.com Tue Mar 3 16:15:14 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Mar 2015 11:15:14 -0500 Subject: [Freeipa-users] Error with kerberos users In-Reply-To: <9634801.f8Rp1ygRMO@techz> References: <9634801.f8Rp1ygRMO@techz> Message-ID: <54F5DE12.9000107@redhat.com> On 03/03/2015 10:39 AM, G?nther J. Niederwimmer wrote: > Hello, > > what is wrong on my setup? > This is a "normal" install with ipa-server-install and ipa-client install on 5 > KVM clients. > > CentOs 7 > > > > WARNING: Failed to create krb5 context for user with uid 225200001 for server > bbs.gjn.prv > Mar 3 16:28:22 smtp1 rpc.gssd[6912]: doing error downcall > Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall > (/var/lib/nfs/rpc_pipefs/nfs/clnt5) > Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 > uid=225200001 enctypes=18,17,16,23,3,1,2 ' > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: handling krb5 upcall > (/var/lib/nfs/rpc_pipefs/nfs/clnt5) > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: process_krb5_upcall: service is '' I assume this is a log from the nfs client shoing the attempt to access NFS server. Seems like something is misconfigured in the nfs configuration or there is a mismatch between the acceptable encryption types on the server and on the client. > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: ERROR: GSS-API: error in > gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may > provide more information) - No Kerberos credentials available > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with uid > 225200001 for server bbs.gjn.prv > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' being > considered, with preferred realm 'GJN.PRV' > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' owned by > 0, not 225200001 > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with uid > 225200001 for server bbs.gjn.prv > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: Error doing scandir on directory > '/run/user/225200001': No such file or directory > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: WARNING: Failed to create krb5 context > for user with uid 225200001 for server bbs.gjn.prv > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: doing error downcall > Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall > (/var/lib/nfs/rpc_pipefs/nfs/clnt5) > Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 > uid=225200001 enctypes=18,17,16,23,3,1,2 ' > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: handling krb5 upcall > (/var/lib/nfs/rpc_pipefs/nfs/clnt5) > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: process_krb5_upcall: service is '' > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: ERROR: GSS-API: error in > gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code may > provide more information) - No Kerberos credentials available > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with uid > 225200001 for server bbs.gjn.prv > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' being > considered, with preferred realm 'GJN.PRV' > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' owned by > 0, not 225200001 > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with uid > 225200001 for server bbs.gjn.prv > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: Error doing scandir on directory > '/run/user/225200001': No such file or directory > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: WARNING: Failed to create krb5 context > for user with uid 225200001 for server bbs.gjn.prv > > Thank's for answer. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From guertin at middlebury.edu Tue Mar 3 16:54:49 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 3 Mar 2015 16:54:49 +0000 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <20150303095526.GC4026@hendrix.arn.redhat.com> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> Message-ID: > Do these logs come from a client or the IPA server? Are you able to look up > the user on the IPA server at least? These come from the IPA server. So no, I can't even look up the user on the server. > Can you paste (sanitized) logs from the sssd_be process as well? They would > be located at /var/log/sssd/sssd_middlebury.edu.log Here's the relevant section. It's actually in var/log/sssd/sssd_csns.middlebury.edu.log. Here, csns.middlebury.edu is the IPA subdomain of our middlebury.edu AD domain. (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0xcbdfd0 (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=guertin-s] (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [be_req_set_domain] (0x0400): Changing request domain from [csns.middlebury.edu] to [middlebury.edu] (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 26 (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xcc8f60], connected[1], ops[0xce01f0], ldap[0xcc9a00] (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations error(1), (null) (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_id_op_done] (0x4000): releasing operation connection (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xcc8f60], connected[1], ops[(nil)], ldap[0xcc9a00] (Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > If the logs are from the client and the back end logs would say something > about extended operation failing, then we need to take a look at the sssd > logs on the server as well. So, yes, it looks like ldap_extended_operation failed, and something is going on with our AD server. This actually triggers a realization on my part: I've been testing this with one of our AD domain controllers, but we have three others that I'm not testing it with. I suspect now that IPA is trying to talk to one of the other DCs that does not have a trust relationship established. Eventually I want to set up a trust relationship on all the DCs, but to test for now, is there a way to force IPA to use a particular domain controller? David Guertin From abokovoy at redhat.com Tue Mar 3 17:13:24 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 Mar 2015 19:13:24 +0200 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> Message-ID: <20150303171324.GQ25455@redhat.com> On Tue, 03 Mar 2015, Guertin, David S. wrote: >> Do these logs come from a client or the IPA server? Are you able to look up >> the user on the IPA server at least? > >These come from the IPA server. So no, I can't even look up the user on the server. > >> Can you paste (sanitized) logs from the sssd_be process as well? They would >> be located at /var/log/sssd/sssd_middlebury.edu.log > >Here's the relevant section. It's actually in var/log/sssd/sssd_csns.middlebury.edu.log. Here, csns.middlebury.edu is the IPA subdomain of our middlebury.edu AD domain. > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0xcbdfd0 >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_dispatch] (0x4000): Dispatching. >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=guertin-s] >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [be_req_set_domain] (0x0400): Changing request domain from [csns.middlebury.edu] to [middlebury.edu] >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 26 >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xcc8f60], connected[1], ops[0xce01f0], ldap[0xcc9a00] >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations error(1), (null) >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_id_op_done] (0x4000): releasing operation connection >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xcc8f60], connected[1], ops[(nil)], ldap[0xcc9a00] >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! Can you show us your sssd.conf? When SSSD runs on IPA master it should not use extdom (ipa_s2n_exop_send and friends) at all. > > > If the logs are from the client and the back end logs would say something >> about extended operation failing, then we need to take a look at the sssd >> logs on the server as well. > >So, yes, it looks like ldap_extended_operation failed, and something is >going on with our AD server. This actually triggers a realization on my >part: I've been testing this with one of our AD domain controllers, but >we have three others that I'm not testing it with. I suspect now that >IPA is trying to talk to one of the other DCs that does not have a >trust relationship established. Eventually I want to set up a trust >relationship on all the DCs, but to test for now, is there a way to >force IPA to use a particular domain controller? > >David Guertin > >-- >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 -- / Alexander Bokovoy From guertin at middlebury.edu Tue Mar 3 17:20:23 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 3 Mar 2015 17:20:23 +0000 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <20150303171324.GQ25455@redhat.com> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> <20150303171324.GQ25455@redhat.com> Message-ID: <36ce3e026ae54fa581ae3b4de8afabf5@greyhound.middlebury.edu> > Can you show us your sssd.conf? When SSSD runs on IPA master it should > not use extdom (ipa_s2n_exop_send and friends) at all. Sure, here's my sssd.conf: [domain/csns.middlebury.edu] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = csns.middlebury.edu id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = ipa1.csns.middlebury.edu chpass_provider = ipa ipa_server = ipa1.csns.middlebury.edu ldap_tls_cacert = /etc/ipa/ca.crt subdomains_provider = ipa debug_level = 10 [sssd] services = nss, sudo, pam, ssh, pac config_file_version = 2 debug_level = 5 domains = csns.middlebury.edu [nss] homedir_substring = /home debug_level = 5 [pam] debug_level = 10 [sudo] debug_level = 5 [autofs] debug_level = 5 [ssh] debug_level = 5 [pac] debug_level = 5 [ifp] debug_level = 5 David Guertin From jhrozek at redhat.com Tue Mar 3 17:28:14 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 3 Mar 2015 18:28:14 +0100 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <20150303171324.GQ25455@redhat.com> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> <20150303171324.GQ25455@redhat.com> Message-ID: <20150303172814.GT4026@hendrix.arn.redhat.com> On Tue, Mar 03, 2015 at 07:13:24PM +0200, Alexander Bokovoy wrote: > On Tue, 03 Mar 2015, Guertin, David S. wrote: > >>Do these logs come from a client or the IPA server? Are you able to look up > >>the user on the IPA server at least? > > > >These come from the IPA server. So no, I can't even look up the user on the server. > > > >>Can you paste (sanitized) logs from the sssd_be process as well? They would > >>be located at /var/log/sssd/sssd_middlebury.edu.log > > > >Here's the relevant section. It's actually in var/log/sssd/sssd_csns.middlebury.edu.log. Here, csns.middlebury.edu is the IPA subdomain of our middlebury.edu AD domain. > > > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_dispatch] (0x4000): dbus conn: 0xcbdfd0 > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_dispatch] (0x4000): Dispatching. > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=guertin-s] > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [be_req_set_domain] (0x0400): Changing request domain from [csns.middlebury.edu] to [middlebury.edu] > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_id_op_connect_step] (0x4000): reusing cached connection > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 26 > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xcc8f60], connected[1], ops[0xce01f0], ldap[0xcc9a00] > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Operations error(1), (null) > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_id_op_done] (0x4000): releasing operation connection > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xcc8f60], connected[1], ops[(nil)], ldap[0xcc9a00] > >(Tue Mar 3 11:25:10 2015) [sssd[be[csns.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > Can you show us your sssd.conf? When SSSD runs on IPA master it should > not use extdom (ipa_s2n_exop_send and friends) at all. yes, I'm quite certain this is the client. > > > > >> If the logs are from the client and the back end logs would say something > >>about extended operation failing, then we need to take a look at the sssd > >>logs on the server as well. That's why I proposed to take a look at the server above :-) The server-side sssd logs would show exactly which AD the SSSD talks to and also the errors it is getting. From gjn at gjn.priv.at Tue Mar 3 17:35:17 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Tue, 03 Mar 2015 18:35:17 +0100 Subject: [Freeipa-users] Error with kerberos users In-Reply-To: <54F5DE12.9000107@redhat.com> References: <9634801.f8Rp1ygRMO@techz> <54F5DE12.9000107@redhat.com> Message-ID: <9199894.rDJXoCu3cC@techz> Hello, Am Dienstag, 3. M?rz 2015, 11:15:14 schrieb Dmitri Pal: > On 03/03/2015 10:39 AM, G?nther J. Niederwimmer wrote: > > Hello, > > > > what is wrong on my setup? > > This is a "normal" install with ipa-server-install and ipa-client install > > on 5 KVM clients. > > > > CentOs 7 > > > > > > > > WARNING: Failed to create krb5 context for user with uid 225200001 for > > server bbs.gjn.prv Can this be correct ?? I make a kinit with this user ? > > Mar 3 16:28:22 smtp1 rpc.gssd[6912]: doing error downcall > > Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall > > (/var/lib/nfs/rpc_pipefs/nfs/clnt5) > > Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 > > uid=225200001 enctypes=18,17,16,23,3,1,2 ' > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: handling krb5 upcall > > (/var/lib/nfs/rpc_pipefs/nfs/clnt5) > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: process_krb5_upcall: service is > > '' > I assume this is a log from the nfs client shoing the attempt to access > NFS server. > Seems like something is misconfigured in the nfs configuration or there > is a mismatch between the acceptable encryption types on the server and > on the client. Yes this is a log from nfs-client but on the server I have the same Errors. I have all docs I found read .-(. > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: ERROR: GSS-API: error in > > gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code > > may > > provide more information) - No Kerberos credentials available > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with > > uid 225200001 for server bbs.gjn.prv > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' > > being > > considered, with preferred realm 'GJN.PRV' > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' > > owned by 0, not 225200001 > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with > > uid 225200001 for server bbs.gjn.prv > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: Error doing scandir on directory > > '/run/user/225200001': No such file or directory Why I have no User (?) and this is not created by a kinit ? > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: WARNING: Failed to create krb5 > > context for user with uid 225200001 for server bbs.gjn.prv > > Mar 3 16:28:22 smtp1 rpc.gssd[6913]: doing error downcall > > Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall > > (/var/lib/nfs/rpc_pipefs/nfs/clnt5) > > Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 > > uid=225200001 enctypes=18,17,16,23,3,1,2 ' > > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: handling krb5 upcall > > (/var/lib/nfs/rpc_pipefs/nfs/clnt5) > > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: process_krb5_upcall: service is > > '' Mar 3 16:28:22 smtp1 rpc.gssd[6914]: ERROR: GSS-API: error in > > gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code > > may > > provide more information) - No Kerberos credentials available > > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with > > uid 225200001 for server bbs.gjn.prv > > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' > > being > > considered, with preferred realm 'GJN.PRV' > > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' > > owned by 0, not 225200001 > > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with > > uid 225200001 for server bbs.gjn.prv > > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: Error doing scandir on directory > > '/run/user/225200001': No such file or directory > > Mar 3 16:28:22 smtp1 rpc.gssd[6914]: WARNING: Failed to create krb5 > > context for user with uid 225200001 for server bbs.gjn.prv Thank's for answer. -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From guertin at middlebury.edu Tue Mar 3 17:40:14 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 3 Mar 2015 17:40:14 +0000 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <20150303172814.GT4026@hendrix.arn.redhat.com> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> <20150303171324.GQ25455@redhat.com> <20150303172814.GT4026@hendrix.arn.redhat.com> Message-ID: > yes, I'm quite certain this is the client. Actually, it isn't, or at least it's not supposed to be. I've only ever installed IPA on one machine, and the command I used to install it was ipa-server-install (followed by ipa dnsconfig-mod, ipa-adtrust-install, and ipa trust-add, as described in the documentation). Of course, the ipa-client package is installed too, but if this machine is not acting as a server then something is seriously messed up! David Guertin From abokovoy at redhat.com Tue Mar 3 17:42:31 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 Mar 2015 19:42:31 +0200 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <36ce3e026ae54fa581ae3b4de8afabf5@greyhound.middlebury.edu> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> <20150303171324.GQ25455@redhat.com> <36ce3e026ae54fa581ae3b4de8afabf5@greyhound.middlebury.edu> Message-ID: <20150303174231.GR25455@redhat.com> On Tue, 03 Mar 2015, Guertin, David S. wrote: >> Can you show us your sssd.conf? When SSSD runs on IPA master it should >> not use extdom (ipa_s2n_exop_send and friends) at all. > >Sure, here's my sssd.conf: > >[domain/csns.middlebury.edu] > >cache_credentials = True >krb5_store_password_if_offline = True >ipa_domain = csns.middlebury.edu >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = ipa1.csns.middlebury.edu >chpass_provider = ipa >ipa_server = ipa1.csns.middlebury.edu >ldap_tls_cacert = /etc/ipa/ca.crt >subdomains_provider = ipa >debug_level = 10 >[sssd] >services = nss, sudo, pam, ssh, pac >config_file_version = 2 >debug_level = 5 >domains = csns.middlebury.edu >[nss] >homedir_substring = /home >debug_level = 5 >[pam] >debug_level = 10 >[sudo] >debug_level = 5 >[autofs] >debug_level = 5 >[ssh] >debug_level = 5 >[pac] >debug_level = 5 >[ifp] >debug_level = 5 Ok, thanks. I gather that you are running some version of RHEL 6.x (you never stated your exact setup). What do you get with wbinfo -m wbinfo -i 'AD\user' for some AD\user from active directory. -- / Alexander Bokovoy From dpal at redhat.com Tue Mar 3 17:59:13 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Mar 2015 12:59:13 -0500 Subject: [Freeipa-users] Error with kerberos users In-Reply-To: <9199894.rDJXoCu3cC@techz> References: <9634801.f8Rp1ygRMO@techz> <54F5DE12.9000107@redhat.com> <9199894.rDJXoCu3cC@techz> Message-ID: <54F5F671.4080906@redhat.com> On 03/03/2015 12:35 PM, G?nther J. Niederwimmer wrote: > Hello, > > Am Dienstag, 3. M?rz 2015, 11:15:14 schrieb Dmitri Pal: >> On 03/03/2015 10:39 AM, G?nther J. Niederwimmer wrote: >>> Hello, >>> >>> what is wrong on my setup? >>> This is a "normal" install with ipa-server-install and ipa-client install >>> on 5 KVM clients. >>> >>> CentOs 7 >>> >>> >>> >>> WARNING: Failed to create krb5 context for user with uid 225200001 for >>> server bbs.gjn.prv > Can this be correct ?? > > I make a kinit with this user ? > > >>> Mar 3 16:28:22 smtp1 rpc.gssd[6912]: doing error downcall >>> Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall >>> (/var/lib/nfs/rpc_pipefs/nfs/clnt5) >>> Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 >>> uid=225200001 enctypes=18,17,16,23,3,1,2 ' >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: handling krb5 upcall >>> (/var/lib/nfs/rpc_pipefs/nfs/clnt5) >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: process_krb5_upcall: service is >>> '' >> I assume this is a log from the nfs client shoing the attempt to access >> NFS server. >> Seems like something is misconfigured in the nfs configuration or there >> is a mismatch between the acceptable encryption types on the server and >> on the client. > Yes this is a log from nfs-client but on the server I have the same Errors. > > I have all docs I found read .-(. > >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: ERROR: GSS-API: error in >>> gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code >>> may >>> provide more information) - No Kerberos credentials available >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with >>> uid 225200001 for server bbs.gjn.prv >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' >>> being >>> considered, with preferred realm 'GJN.PRV' >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' >>> owned by 0, not 225200001 >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with >>> uid 225200001 for server bbs.gjn.prv >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: Error doing scandir on directory >>> '/run/user/225200001': No such file or directory > Why I have no User (?) and this is not created by a kinit ? > >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: WARNING: Failed to create krb5 >>> context for user with uid 225200001 for server bbs.gjn.prv > >>> Mar 3 16:28:22 smtp1 rpc.gssd[6913]: doing error downcall >>> Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall >>> (/var/lib/nfs/rpc_pipefs/nfs/clnt5) >>> Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 >>> uid=225200001 enctypes=18,17,16,23,3,1,2 ' >>> Mar 3 16:28:22 smtp1 rpc.gssd[6914]: handling krb5 upcall >>> (/var/lib/nfs/rpc_pipefs/nfs/clnt5) >>> Mar 3 16:28:22 smtp1 rpc.gssd[6914]: process_krb5_upcall: service is >>> '' Mar 3 16:28:22 smtp1 rpc.gssd[6914]: ERROR: GSS-API: error in >>> gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code >>> may >>> provide more information) - No Kerberos credentials available >>> Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with >>> uid 225200001 for server bbs.gjn.prv >>> Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' >>> being >>> considered, with preferred realm 'GJN.PRV' >>> Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' >>> owned by 0, not 225200001 >>> Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with >>> uid 225200001 for server bbs.gjn.prv >>> Mar 3 16:28:22 smtp1 rpc.gssd[6914]: Error doing scandir on directory >>> '/run/user/225200001': No such file or directory >>> Mar 3 16:28:22 smtp1 rpc.gssd[6914]: WARNING: Failed to create krb5 >>> context for user with uid 225200001 for server bbs.gjn.prv > > Thank's for answer. > If this is the client. Let us step back and ask the following questions: a) Are users resolvable using id command and friends? b) Can you do kinit as an ipa user from the client? c) Can you log in to that system? In 7 the credential cache created by SSSD is in kernel keyring but it seems that NFS client is looking for it in /tmp. What is the sequence of operations? What do you actually do before you observe this error (for example: reboot, log into the system using sssd...)? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From guertin at middlebury.edu Tue Mar 3 17:48:21 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 3 Mar 2015 17:48:21 +0000 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: <20150303174231.GR25455@redhat.com> References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> <20150303171324.GQ25455@redhat.com> <36ce3e026ae54fa581ae3b4de8afabf5@greyhound.middlebury.edu> <20150303174231.GR25455@redhat.com> Message-ID: > I gather that you are running some version of RHEL 6.x (you never stated > your exact setup). What do you get with Yes, this is RHEL 6.6 > wbinfo -m # wbinfo -m BUILTIN CSNS MIDD > wbinfo -i 'AD\user' # wbinfo -i 'MIDD\testuser' failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND Could not get info for user MIDD\testuser Is this a winbind problem? David Guertin From abokovoy at redhat.com Tue Mar 3 19:07:57 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 3 Mar 2015 21:07:57 +0200 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> <20150303171324.GQ25455@redhat.com> <36ce3e026ae54fa581ae3b4de8afabf5@greyhound.middlebury.edu> <20150303174231.GR25455@redhat.com> Message-ID: <20150303190757.GS25455@redhat.com> On Tue, 03 Mar 2015, Guertin, David S. wrote: >> I gather that you are running some version of RHEL 6.x (you never stated >> your exact setup). What do you get with > >Yes, this is RHEL 6.6 > >> wbinfo -m > ># wbinfo -m >BUILTIN >CSNS >MIDD > >> wbinfo -i 'AD\user' > ># wbinfo -i 'MIDD\testuser' >failed to call wbcGetpwnam: WBC_ERR_DOMAIN_NOT_FOUND >Could not get info for user MIDD\testuser > >Is this a winbind problem? In RHEL 6.x we are using winbindd for cross-forest trust lookups. If it fails, then the rest will fail too. Let's look at logs. # smbcontrol winbindd debug 100 # wbinfo -i 'MIDD\testuser' # smbcontrol winbindd debug 1 and then send logs from /var/log/samba/ to me. -- / Alexander Bokovoy From simo at redhat.com Tue Mar 3 19:17:41 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 03 Mar 2015 14:17:41 -0500 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> <20150303171324.GQ25455@redhat.com> <20150303172814.GT4026@hendrix.arn.redhat.com> Message-ID: <1425410261.13900.33.camel@willson.usersys.redhat.com> On Tue, 2015-03-03 at 17:40 +0000, Guertin, David S. wrote: > > yes, I'm quite certain this is the client. > > Actually, it isn't, or at least it's not supposed to be. I've only ever installed IPA on one machine, and the command I used to install it was ipa-server-install (followed by ipa dnsconfig-mod, ipa-adtrust-install, and ipa trust-add, as described in the documentation). > > Of course, the ipa-client package is installed too, but if this machine is not acting as a server then something is seriously messed up! > > David Guertin > An IPA server is always also a client of itself. Simo. -- Simo Sorce * Red Hat, Inc * New York From erinn.looneytriggs at gmail.com Tue Mar 3 19:24:47 2015 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 03 Mar 2015 12:24:47 -0700 Subject: [Freeipa-users] Possible for system to be member of both IPA domain and AD domain? Message-ID: <2227766.prxMHhFYh6@scrapy.abaqis.com> Before I go charging down this path too far, I wanted to figure out whether it is possible for a RHEL 7 system to be a member of both an IPA domain and a separate AD domain? At this point trusts are not established between IPA and the AD, this will happen around the 7.1 release, however, I would like the system to use IPA for auth of things like ssh and the AD domain for auth of CIFS/SMB shares via samba 4. Is this possible? Anyone know? Seems like it should be. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dpal at redhat.com Tue Mar 3 19:41:58 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Mar 2015 14:41:58 -0500 Subject: [Freeipa-users] Possible for system to be member of both IPA domain and AD domain? In-Reply-To: <2227766.prxMHhFYh6@scrapy.abaqis.com> References: <2227766.prxMHhFYh6@scrapy.abaqis.com> Message-ID: <54F60E86.7040005@redhat.com> On 03/03/2015 02:24 PM, Erinn Looney-Triggs wrote: > Before I go charging down this path too far, I wanted to figure out whether it > is possible for a RHEL 7 system to be a member of both an IPA domain and a > separate AD domain? > > At this point trusts are not established between IPA and the AD, this will > happen around the 7.1 release, however, I would like the system to use IPA for > auth of things like ssh and the AD domain for auth of CIFS/SMB shares via > samba 4. > > Is this possible? Anyone know? Seems like it should be. It might be possible with some configuration hacks but we have not done them so it is not known. I suspect that the challenge will be making sure that SSSD and winbind do not step on each other regarding users. 7.1 will allow you to do what you want via trust so it would be safer to wait a bit for it than to try to hack something with questionable probability of success. > > -Erinn > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From erinn.looneytriggs at gmail.com Tue Mar 3 19:54:47 2015 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Tue, 03 Mar 2015 12:54:47 -0700 Subject: [Freeipa-users] Possible for system to be member of both IPA domain and AD domain? In-Reply-To: <54F60E86.7040005@redhat.com> References: <2227766.prxMHhFYh6@scrapy.abaqis.com> <54F60E86.7040005@redhat.com> Message-ID: <5342660.gdlnBzk5dW@scrapy.abaqis.com> On Tuesday, March 03, 2015 02:41:58 PM Dmitri Pal wrote: > On 03/03/2015 02:24 PM, Erinn Looney-Triggs wrote: > > Before I go charging down this path too far, I wanted to figure out > > whether it is possible for a RHEL 7 system to be a member of both an IPA > > domain and a separate AD domain? > > > > At this point trusts are not established between IPA and the AD, this will > > happen around the 7.1 release, however, I would like the system to use IPA > > for auth of things like ssh and the AD domain for auth of CIFS/SMB shares > > via samba 4. > > > > Is this possible? Anyone know? Seems like it should be. > > It might be possible with some configuration hacks but we have not done > them so it is not known. I suspect that the challenge will be making > sure that SSSD and winbind do not step on each other regarding users. > > 7.1 will allow you to do what you want via trust so it would be safer to > wait a bit for it than to try to hack something with questionable > probability of success. > > > -Erinn Are you questioning my hacking skills ;) Thanks for the info, it looked possible but difficult, 7.1 should be out real soon now (tm), I'll wait. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From dpal at redhat.com Tue Mar 3 21:48:23 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 03 Mar 2015 16:48:23 -0500 Subject: [Freeipa-users] Possible for system to be member of both IPA domain and AD domain? In-Reply-To: <5342660.gdlnBzk5dW@scrapy.abaqis.com> References: <2227766.prxMHhFYh6@scrapy.abaqis.com> <54F60E86.7040005@redhat.com> <5342660.gdlnBzk5dW@scrapy.abaqis.com> Message-ID: <54F62C27.9070407@redhat.com> On 03/03/2015 02:54 PM, Erinn Looney-Triggs wrote: > On Tuesday, March 03, 2015 02:41:58 PM Dmitri Pal wrote: >> On 03/03/2015 02:24 PM, Erinn Looney-Triggs wrote: >>> Before I go charging down this path too far, I wanted to figure out >>> whether it is possible for a RHEL 7 system to be a member of both an IPA >>> domain and a separate AD domain? >>> >>> At this point trusts are not established between IPA and the AD, this will >>> happen around the 7.1 release, however, I would like the system to use IPA >>> for auth of things like ssh and the AD domain for auth of CIFS/SMB shares >>> via samba 4. >>> >>> Is this possible? Anyone know? Seems like it should be. >> It might be possible with some configuration hacks but we have not done >> them so it is not known. I suspect that the challenge will be making >> sure that SSSD and winbind do not step on each other regarding users. >> >> 7.1 will allow you to do what you want via trust so it would be safer to >> wait a bit for it than to try to hack something with questionable >> probability of success. >> >>> -Erinn > Are you questioning my hacking skills ;) No, just being mindful of your time. > > Thanks for the info, it looked possible but difficult, 7.1 should be out real > soon now (tm), I'll wait. Yep > -Erinn -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From hugh at psychopig.com Wed Mar 4 03:57:42 2015 From: hugh at psychopig.com (Hugh) Date: Tue, 03 Mar 2015 21:57:42 -0600 Subject: [Freeipa-users] ntGroup MUST ntUserDomainId? Message-ID: <54F682B6.7000106@psychopig.com> All, We're running ipa-server-3.0.0-42/389-ds-base-1.2.11.15-48 on CentOS 6.5 and synching to AD. We're able to synch users, but can't synch groups. When I was adding in the ntGroup objectclass, it appears that that requires ntUserDomainId to be set. Shouldn't that be ntGroupDomainId? I tried to add ntGroupDomainId, but that attribute doesn't seem to be allowed by any objectclasses. I did a grep on the /etc/dirsrv directory and can see ntGroupDomainId in the attribute list, but not in any of the objectclasses. What attributes/objectclasses are required for synching to AD? Thanks, Hugh From bentech4you at gmail.com Wed Mar 4 06:06:17 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 4 Mar 2015 09:06:17 +0300 Subject: [Freeipa-users] how can i fix ipa: ERROR: AD DC was unable to reach any IPA domain controller Message-ID: HI i have re-installed IPA with latest 4.1 version. installed packages by using https://copr.fedoraproject.org/coprs/mkosek/freeipa/ repos # ipa-server-install went successfully without any error an it says the same on log files *[root at kwtpocpbis01 ~]# kinit admin* *Password for admin at SOLIPA.LOCAL:* *[root at kwtpocpbis01 ~]# klist* *Ticket cache: KEYRING:persistent:0:0* *Default principal: admin at SOLIPA.LOCAL* *Valid starting Expires Service principal* *03/04/2015 08:36:55 03/05/2015 08:36:51 krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL* *[root at kwtpocpbis01 ~]# geten* *getenforce getent* *[root at kwtpocpbis01 ~]# getent passwd admin* *admin:*:4400000:4400000:Administrator:/home/admin:/bin/bash* *# ipa-adtrust-install --netbios-name=SOLIPA -a Passw0rd* also successfully went . DNS is working fine as expected. *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.kwttestdc.com * *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV _ldap._tcp.kwttestdc.com * *;; global options: +cmd* *;; Got answer:* *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26944* *;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* *;; OPT PSEUDOSECTION:* *; EDNS: version: 0, flags:; udp: 4000* *;; QUESTION SECTION:* *;_ldap._tcp.kwttestdc.com . IN SRV* *;; ANSWER SECTION:* *_ldap._tcp.kwttestdc.com . 600 IN SRV 0 100 389 kwttestdc001.kwttestdc.com .* *;; ADDITIONAL SECTION:* *kwttestdc001.kwttestdc.com . 3600 IN A 172.16.104.231* *;; Query time: 0 msec* *;; SERVER: 172.16.104.231#53(172.16.104.231)* *;; WHEN: Wed Mar 04 08:41:26 AST 2015* *;; MSG SIZE rcvd: 115* *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.solipa.local* *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV _ldap._tcp.solipa.local* *;; global options: +cmd* *;; Got answer:* *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6196* *;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* *;; OPT PSEUDOSECTION:* *; EDNS: version: 0, flags:; udp: 4000* *;; QUESTION SECTION:* *;_ldap._tcp.solipa.local. IN SRV* *;; ANSWER SECTION:* *_ldap._tcp.solipa.local. 11944 IN SRV 0 100 389 kwtpocpbis01.solipa.local.* *;; ADDITIONAL SECTION:* *kwtpocpbis01.solipa.local. 1200 IN A 172.16.107.244* *;; Query time: 2 msec* *;; SERVER: 172.16.104.231#53(172.16.104.231)* *;; WHEN: Wed Mar 04 08:41:34 AST 2015* *;; MSG SIZE rcvd: 113* But when i try to trust add AD, i am getting error [root at kwtpocpbis01 ~]# ipa trust-add --type=ad kwttestdc.com --admin adm-ben.george --password Active Directory domain administrator's password: ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue I checked from firewall status on both IPA and AD, and it was in off state. below is the error i got on httpd/error_log while trying AD trust *[Wed Mar 04 08:50:30.784320 2015] [:error] [pid 6138] ipa: INFO: [jsonserver_session] admin at SOLIPA.LOCAL: trust_add(u'kwttestdc.com ', trust_type=u'ad', realm_admin=u'adm-ben.george', realm_passwd=u'********', all=False, raw=False, version=u'2.113'): RemoteRetrieveError* and i have enable debugging on SM, here attaching logs from samba LOGS can be downloaded from here also : https://app.box.com/s/6bx9cgozjyb8h96wx7j6ovvz9w8cp4yl how can i fix this issue? Thanks & Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa.tar Type: application/x-tar Size: 30720 bytes Desc: not available URL: From jhrozek at redhat.com Wed Mar 4 06:36:40 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 4 Mar 2015 07:36:40 +0100 Subject: [Freeipa-users] AD trust relationship is established, but IPA cannot see AD users In-Reply-To: References: <1425324774568.82792@middlebury.edu> <20150302201724.GI25455@redhat.com> <153cef24575b440e8679266856da0aa0@greyhound.middlebury.edu> <20150303095526.GC4026@hendrix.arn.redhat.com> <20150303171324.GQ25455@redhat.com> <20150303172814.GT4026@hendrix.arn.redhat.com> Message-ID: <78DFF09C-FA9F-4364-AB52-119A022E6B09@redhat.com> > On 03 Mar 2015, at 18:40, Guertin, David S. wrote: > >> yes, I'm quite certain this is the client. > > Actually, it isn't, or at least it's not supposed to be. I've only ever installed IPA on one machine, and the command I used to install it was ipa-server-install (followed by ipa dnsconfig-mod, ipa-adtrust-install, and ipa trust-add, as described in the documentation). > > Of course, the ipa-client package is installed too, but if this machine is not acting as a server then something is seriously messed up! Sorry about the confusion, for some reason I thought the server was running 7.x, where the sssd runs in a special mode and no longer acts as a client. Then the info Alexander requested is correct. From bentech4you at gmail.com Wed Mar 4 07:01:05 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 4 Mar 2015 10:01:05 +0300 Subject: [Freeipa-users] how can i fix ipa: ERROR: AD DC was unable to reach any IPA domain controller In-Reply-To: References: Message-ID: HI When i checked on IPA web panel, i can able to see my AD under trusted even though i got error while adding . ipa trust-add also *[root at kwtpocpbis01 ~]# ipa trustdomain-find "kwttestdc.com "* * Domain name: kwttestdc.com * * Domain NetBIOS name: KWTTESTDC* * Domain Security Identifier: S-1-5-21-3321666283-4099738591-2270060621* * Domain enabled: True* *----------------------------* *Number of entries returned 1* *----------------------------* *[root at kwtpocpbis01 ~]# ipa trust-fetch-domains "kwttestdc.com "* *ipa: ERROR: AD domain controller complains about communication sequence. It may mean unsynchronized time on both sides, for example* This is the the same story happend with IPA 3.3 before Regards, Ben On Wed, Mar 4, 2015 at 9:06 AM, Ben .T.George wrote: > HI > > i have re-installed IPA with latest 4.1 version. > > installed packages by using > https://copr.fedoraproject.org/coprs/mkosek/freeipa/ repos > > # ipa-server-install went successfully without any error an it says the > same on log files > > *[root at kwtpocpbis01 ~]# kinit admin* > *Password for admin at SOLIPA.LOCAL:* > *[root at kwtpocpbis01 ~]# klist* > *Ticket cache: KEYRING:persistent:0:0* > *Default principal: admin at SOLIPA.LOCAL* > > *Valid starting Expires Service principal* > *03/04/2015 08:36:55 03/05/2015 08:36:51 > krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL* > *[root at kwtpocpbis01 ~]# geten* > *getenforce getent* > *[root at kwtpocpbis01 ~]# getent passwd admin* > *admin:*:4400000:4400000:Administrator:/home/admin:/bin/bash* > > > *# ipa-adtrust-install --netbios-name=SOLIPA -a Passw0rd* also > successfully went . > > DNS is working fine as expected. > > *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.kwttestdc.com > * > > *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV > _ldap._tcp.kwttestdc.com * > *;; global options: +cmd* > *;; Got answer:* > *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26944* > *;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* > > *;; OPT PSEUDOSECTION:* > *; EDNS: version: 0, flags:; udp: 4000* > *;; QUESTION SECTION:* > *;_ldap._tcp.kwttestdc.com . IN SRV* > > *;; ANSWER SECTION:* > *_ldap._tcp.kwttestdc.com . 600 IN SRV > 0 100 389 kwttestdc001.kwttestdc.com .* > > *;; ADDITIONAL SECTION:* > *kwttestdc001.kwttestdc.com . 3600 IN > A 172.16.104.231* > > *;; Query time: 0 msec* > *;; SERVER: 172.16.104.231#53(172.16.104.231)* > *;; WHEN: Wed Mar 04 08:41:26 AST 2015* > *;; MSG SIZE rcvd: 115* > > *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.solipa.local* > > *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV > _ldap._tcp.solipa.local* > *;; global options: +cmd* > *;; Got answer:* > *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6196* > *;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* > > *;; OPT PSEUDOSECTION:* > *; EDNS: version: 0, flags:; udp: 4000* > *;; QUESTION SECTION:* > *;_ldap._tcp.solipa.local. IN SRV* > > *;; ANSWER SECTION:* > *_ldap._tcp.solipa.local. 11944 IN SRV 0 100 389 > kwtpocpbis01.solipa.local.* > > *;; ADDITIONAL SECTION:* > *kwtpocpbis01.solipa.local. 1200 IN A 172.16.107.244* > > *;; Query time: 2 msec* > *;; SERVER: 172.16.104.231#53(172.16.104.231)* > *;; WHEN: Wed Mar 04 08:41:34 AST 2015* > *;; MSG SIZE rcvd: 113* > > But when i try to trust add AD, i am getting error > > [root at kwtpocpbis01 ~]# ipa trust-add --type=ad kwttestdc.com --admin > adm-ben.george --password > Active Directory domain administrator's password: > ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most > likely it is a DNS or firewall issue > > I checked from firewall status on both IPA and AD, and it was in off > state. > > below is the error i got on httpd/error_log while trying AD trust > > *[Wed Mar 04 08:50:30.784320 2015] [:error] [pid 6138] ipa: INFO: > [jsonserver_session] admin at SOLIPA.LOCAL: trust_add(u'kwttestdc.com > ', trust_type=u'ad', realm_admin=u'adm-ben.george', > realm_passwd=u'********', all=False, raw=False, version=u'2.113'): > RemoteRetrieveError* > > and i have enable debugging on SM, here attaching logs from samba > > LOGS can be downloaded from here also : > https://app.box.com/s/6bx9cgozjyb8h96wx7j6ovvz9w8cp4yl > > how can i fix this issue? > > Thanks & Regards, > Ben > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 4 07:07:06 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 Mar 2015 09:07:06 +0200 Subject: [Freeipa-users] how can i fix ipa: ERROR: AD DC was unable to reach any IPA domain controller In-Reply-To: References: Message-ID: <20150304070706.GW25455@redhat.com> On Wed, 04 Mar 2015, Ben .T.George wrote: >HI > >i have re-installed IPA with latest 4.1 version. > >installed packages by using >https://copr.fedoraproject.org/coprs/mkosek/freeipa/ repos > ># ipa-server-install went successfully without any error an it says the >same on log files > >*[root at kwtpocpbis01 ~]# kinit admin* >*Password for admin at SOLIPA.LOCAL:* >*[root at kwtpocpbis01 ~]# klist* >*Ticket cache: KEYRING:persistent:0:0* >*Default principal: admin at SOLIPA.LOCAL* > >*Valid starting Expires Service principal* >*03/04/2015 08:36:55 03/05/2015 08:36:51 krbtgt/SOLIPA.LOCAL at SOLIPA.LOCAL* >*[root at kwtpocpbis01 ~]# geten* >*getenforce getent* >*[root at kwtpocpbis01 ~]# getent passwd admin* >*admin:*:4400000:4400000:Administrator:/home/admin:/bin/bash* > > >*# ipa-adtrust-install --netbios-name=SOLIPA -a Passw0rd* also successfully >went . > >DNS is working fine as expected. > >*[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.kwttestdc.com >* > >*; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV >_ldap._tcp.kwttestdc.com * >*;; global options: +cmd* >*;; Got answer:* >*;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26944* >*;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* > >*;; OPT PSEUDOSECTION:* >*; EDNS: version: 0, flags:; udp: 4000* >*;; QUESTION SECTION:* >*;_ldap._tcp.kwttestdc.com . IN SRV* > >*;; ANSWER SECTION:* >*_ldap._tcp.kwttestdc.com . 600 IN SRV >0 100 389 kwttestdc001.kwttestdc.com .* > >*;; ADDITIONAL SECTION:* >*kwttestdc001.kwttestdc.com . 3600 IN > A 172.16.104.231* > >*;; Query time: 0 msec* >*;; SERVER: 172.16.104.231#53(172.16.104.231)* >*;; WHEN: Wed Mar 04 08:41:26 AST 2015* >*;; MSG SIZE rcvd: 115* > >*[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.solipa.local* > >*; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV >_ldap._tcp.solipa.local* >*;; global options: +cmd* >*;; Got answer:* >*;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6196* >*;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* > >*;; OPT PSEUDOSECTION:* >*; EDNS: version: 0, flags:; udp: 4000* >*;; QUESTION SECTION:* >*;_ldap._tcp.solipa.local. IN SRV* > >*;; ANSWER SECTION:* >*_ldap._tcp.solipa.local. 11944 IN SRV 0 100 389 >kwtpocpbis01.solipa.local.* > >*;; ADDITIONAL SECTION:* >*kwtpocpbis01.solipa.local. 1200 IN A 172.16.107.244* > >*;; Query time: 2 msec* >*;; SERVER: 172.16.104.231#53(172.16.104.231)* >*;; WHEN: Wed Mar 04 08:41:34 AST 2015* >*;; MSG SIZE rcvd: 113* > >But when i try to trust add AD, i am getting error > >[root at kwtpocpbis01 ~]# ipa trust-add --type=ad kwttestdc.com --admin >adm-ben.george --password >Active Directory domain administrator's password: >ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most >likely it is a DNS or firewall issue > >I checked from firewall status on both IPA and AD, and it was in off state. You really need to find out what is wrong between AD and IPA. The message above is based on what AD DC reports back to IPA when it tried to validate the trust and was not able to contact IPA DCs. We cannot influence ourselves this part, as AD DC uses SRV records in DNS to find out which domain controller to contact and if it fails to contact us for any reason (firewall, DNS is broken from AD DC perspective, routing brings it to a different IP address, etc), it will complain like that and never proceed. You may try to run tcpdump or wireshark and see what happens on the network at the time of 'ipa trust-add', specifically, whom AD DC is talking to and where it takes a DNS record. -- / Alexander Bokovoy From mkosek at redhat.com Wed Mar 4 08:00:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Mar 2015 09:00:16 +0100 Subject: [Freeipa-users] ntGroup MUST ntUserDomainId? In-Reply-To: <54F682B6.7000106@psychopig.com> References: <54F682B6.7000106@psychopig.com> Message-ID: <54F6BB90.8060500@redhat.com> On 03/04/2015 04:57 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 > and synching to AD. We're able to synch users, but can't synch groups. > When I was adding in the ntGroup objectclass, it appears that that > requires ntUserDomainId to be set. Shouldn't that be ntGroupDomainId? I > tried to add ntGroupDomainId, but that attribute doesn't seem to be > allowed by any objectclasses. I did a grep on the /etc/dirsrv directory > and can see ntGroupDomainId in the attribute list, but not in any of the > objectclasses. What attributes/objectclasses are required for synching > to AD? Hello Hugh, Before you dive in further in the FreeIPA winsync and groups, please note that FreeIPA does not support group sync from/to AD and there are no plans for adding that capability. We are focusing on AD Trusts instead, as *the* way for cooperation with AD. This is related upstream ticket with similar request, just different direction: https://fedorahosted.org/freeipa/ticket/3946 Martin From jhrozek at redhat.com Wed Mar 4 08:30:28 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 4 Mar 2015 09:30:28 +0100 Subject: [Freeipa-users] Error with kerberos users In-Reply-To: <54F5F671.4080906@redhat.com> References: <9634801.f8Rp1ygRMO@techz> <54F5DE12.9000107@redhat.com> <9199894.rDJXoCu3cC@techz> <54F5F671.4080906@redhat.com> Message-ID: <20150304083028.GA3497@hendrix.arn.redhat.com> On Tue, Mar 03, 2015 at 12:59:13PM -0500, Dmitri Pal wrote: > On 03/03/2015 12:35 PM, G?nther J. Niederwimmer wrote: > >Hello, > > > >Am Dienstag, 3. M?rz 2015, 11:15:14 schrieb Dmitri Pal: > >>On 03/03/2015 10:39 AM, G?nther J. Niederwimmer wrote: > >>>Hello, > >>> > >>>what is wrong on my setup? > >>>This is a "normal" install with ipa-server-install and ipa-client install > >>>on 5 KVM clients. > >>> > >>>CentOs 7 > >>> > >>> > >>> > >>>WARNING: Failed to create krb5 context for user with uid 225200001 for > >>>server bbs.gjn.prv > >Can this be correct ?? > > > >I make a kinit with this user ? > > > > > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6912]: doing error downcall > >>>Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall > >>>(/var/lib/nfs/rpc_pipefs/nfs/clnt5) > >>>Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 > >>>uid=225200001 enctypes=18,17,16,23,3,1,2 ' > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: handling krb5 upcall > >>>(/var/lib/nfs/rpc_pipefs/nfs/clnt5) > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: process_krb5_upcall: service is > >>>'' > >>I assume this is a log from the nfs client shoing the attempt to access > >>NFS server. > >>Seems like something is misconfigured in the nfs configuration or there > >>is a mismatch between the acceptable encryption types on the server and > >>on the client. > >Yes this is a log from nfs-client but on the server I have the same Errors. > >I have all docs I found read .-(. > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: ERROR: GSS-API: error in > >>>gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code > >>>may > >>>provide more information) - No Kerberos credentials available > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with > >>>uid 225200001 for server bbs.gjn.prv > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' > >>>being > >>>considered, with preferred realm 'GJN.PRV' > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: CC '/tmp/krb5ccmachine_GJN.PRV' > >>>owned by 0, not 225200001 > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: getting credentials for client with > >>>uid 225200001 for server bbs.gjn.prv > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: Error doing scandir on directory > >>>'/run/user/225200001': No such file or directory > >Why I have no User (?) and this is not created by a kinit ? > > > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: WARNING: Failed to create krb5 > >>>context for user with uid 225200001 for server bbs.gjn.prv > > > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6913]: doing error downcall > >>>Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handling gssd upcall > >>>(/var/lib/nfs/rpc_pipefs/nfs/clnt5) > >>>Mar 3 16:28:22 smtp1 rpc.gssd[32155]: handle_gssd_upcall: 'mech=krb5 > >>>uid=225200001 enctypes=18,17,16,23,3,1,2 ' > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6914]: handling krb5 upcall > >>>(/var/lib/nfs/rpc_pipefs/nfs/clnt5) > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6914]: process_krb5_upcall: service is > >>>'' Mar 3 16:28:22 smtp1 rpc.gssd[6914]: ERROR: GSS-API: error in > >>>gss_acquire_cred(): GSS_S_FAILURE (Unspecified GSS failure. Minor code > >>>may > >>>provide more information) - No Kerberos credentials available > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with > >>>uid 225200001 for server bbs.gjn.prv > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' > >>>being > >>>considered, with preferred realm 'GJN.PRV' > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6914]: CC '/tmp/krb5ccmachine_GJN.PRV' > >>>owned by 0, not 225200001 > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6914]: getting credentials for client with > >>>uid 225200001 for server bbs.gjn.prv > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6914]: Error doing scandir on directory > >>>'/run/user/225200001': No such file or directory > >>>Mar 3 16:28:22 smtp1 rpc.gssd[6914]: WARNING: Failed to create krb5 > >>>context for user with uid 225200001 for server bbs.gjn.prv > >Thank's for answer. > > > > If this is the client. Let us step back and ask the following questions: > a) Are users resolvable using id command and friends? > b) Can you do kinit as an ipa user from the client? > c) Can you log in to that system? > > In 7 the credential cache created by SSSD is in kernel keyring but it seems > that NFS client is looking for it in /tmp. > > What is the sequence of operations? What do you actually do before you > observe this error (for example: reboot, log into the system using sssd...)? Also, it's not really clear to me what the issue actually is. What is that you're trying to accomplish, which part works and which does not? From bentech4you at gmail.com Wed Mar 4 08:31:41 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 4 Mar 2015 11:31:41 +0300 Subject: [Freeipa-users] how can i fix ipa: ERROR: AD DC was unable to reach any IPA domain controller In-Reply-To: <20150304070706.GW25455@redhat.com> References: <20150304070706.GW25455@redhat.com> Message-ID: Hi i have done tcpdump against AD ip *10:21:34.033939 IP kwtpocpbis01.solipa.local.48731 > kwttestdc001.kwttestdc.com.domain: 39643+ SRV? _ldap._tcp.solipa.local. (41)* *10:21:34.034530 IP kwttestdc001.kwttestdc.com.domain > kwtpocpbis01.solipa.local.48731: 39643 1/0/1 SRV kwtpocpbis01.solipa.local.:389 0 100 (102)* *10:21:38.026794 IP kwtpocpbis01.solipa.local.42160 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [F.], seq 63944419, ack 521272023, win 165, options [nop,nop,TS val 6918912 ecr 248450971], length 0* *10:21:38.027095 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42160: Flags [.], ack 1, win 511, options [nop,nop,TS val 248822622 ecr 6918912], length 0* *10:21:38.027517 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42160: Flags [R.], seq 1, ack 1, win 0, length 0* *10:21:38.031732 IP kwtpocpbis01.solipa.local.34108 > kwttestdc001.kwttestdc.com.domain: 6437+ SRV? _ldap._tcp.kwttestdc.com . (42)* *10:21:38.032554 IP kwttestdc001.kwttestdc.com.domain > kwtpocpbis01.solipa.local.34108: 6437* 1/0/1 SRV kwttestdc001.kwttestdc.com.:389 0 100 (104)* *10:21:38.032827 IP kwtpocpbis01.solipa.local.48294 > kwttestdc001.kwttestdc.com.domain: 64621+ AAAA? kwttestdc001.kwttestdc.com . (44)* *10:21:38.033191 IP kwttestdc001.kwttestdc.com.domain > kwtpocpbis01.solipa.local.48294: 64621* 0/1/0 (91)* *10:21:38.033268 IP kwtpocpbis01.solipa.local.39812 > kwttestdc001.kwttestdc.com.domain: 7211+ AAAA? kwttestdc001.kwttestdc.com . (44)* *10:21:38.033797 IP kwttestdc001.kwttestdc.com.domain > kwtpocpbis01.solipa.local.39812: 7211* 0/1/0 (91)* *10:21:38.033836 IP kwtpocpbis01.solipa.local.37700 > kwttestdc001.kwttestdc.com.domain: 48543+ A? kwttestdc001.kwttestdc.com . (44)* *10:21:38.034193 IP kwttestdc001.kwttestdc.com.domain > kwtpocpbis01.solipa.local.37700: 48543* 1/0/0 A 172.16.104.231 (60)* *10:21:38.035587 IP kwtpocpbis01.solipa.local.48384 > kwttestdc001.kwttestdc.com.ldap: UDP, length 82* *10:21:38.035925 IP kwttestdc001.kwttestdc.com.ldap > kwtpocpbis01.solipa.local.48384: UDP, length 188* *10:21:38.037107 IP kwtpocpbis01.solipa.local.44461 > kwttestdc001.kwttestdc.com.ldap: Flags [S], seq 2172952938, win 14600, options [mss 1460,sackOK,TS val 6918922 ecr 0,nop,wscale 7], length 0* *10:21:38.037577 IP kwttestdc001.kwttestdc.com.ldap > kwtpocpbis01.solipa.local.44461: Flags [S.], seq 4067674102, ack 2172952939, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 248822623 ecr 6918922], length 0* *10:21:38.037594 IP kwtpocpbis01.solipa.local.44461 > kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 1, win 115, options [nop,nop,TS val 6918922 ecr 248822623], length 0* *10:21:38.037627 IP kwtpocpbis01.solipa.local.44461 > kwttestdc001.kwttestdc.com.ldap: Flags [P.], seq 1:75, ack 1, win 115, options [nop,nop,TS val 6918922 ecr 248822623], length 74* *10:21:38.038501 IP kwttestdc001.kwttestdc.com.ldap > kwtpocpbis01.solipa.local.44461: Flags [.], seq 1:1449, ack 75, win 514, options [nop,nop,TS val 248822623 ecr 6918922], length 1448* *10:21:38.038520 IP kwtpocpbis01.solipa.local.44461 > kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 1449, win 137, options [nop,nop,TS val 6918923 ecr 248822623], length 0* *10:21:38.038526 IP kwttestdc001.kwttestdc.com.ldap > kwtpocpbis01.solipa.local.44461: Flags [.], seq 1449:2897, ack 75, win 514, options [nop,nop,TS val 248822623 ecr 6918922], length 1448* *10:21:38.038534 IP kwtpocpbis01.solipa.local.44461 > kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 2897, win 160, options [nop,nop,TS val 6918923 ecr 248822623], length 0* *10:21:38.038703 IP kwttestdc001.kwttestdc.com.ldap > kwtpocpbis01.solipa.local.44461: Flags [P.], seq 2897:3228, ack 75, win 514, options [nop,nop,TS val 248822623 ecr 6918923], length 331* *10:21:38.038711 IP kwtpocpbis01.solipa.local.44461 > kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 3228, win 182, options [nop,nop,TS val 6918924 ecr 248822623], length 0* *10:21:38.039039 IP kwtpocpbis01.solipa.local.44461 > kwttestdc001.kwttestdc.com.ldap: Flags [P.], seq 75:117, ack 3228, win 182, options [nop,nop,TS val 6918924 ecr 248822623], length 42* *10:21:38.039055 IP kwtpocpbis01.solipa.local.44461 > kwttestdc001.kwttestdc.com.ldap: Flags [F.], seq 117, ack 3228, win 182, options [nop,nop,TS val 6918924 ecr 248822623], length 0* *10:21:38.039383 IP kwttestdc001.kwttestdc.com.ldap > kwtpocpbis01.solipa.local.44461: Flags [.], ack 118, win 514, options [nop,nop,TS val 248822623 ecr 6918924], length 0* *10:21:38.039406 IP kwttestdc001.kwttestdc.com.ldap > kwtpocpbis01.solipa.local.44461: Flags [R.], seq 3228, ack 118, win 0, length 0* *10:21:38.042568 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [S], seq 3200525455, win 14600, options [mss 1460,sackOK,TS val 6918927 ecr 0,nop,wscale 7], length 0* *10:21:38.042810 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [S.], seq 2793269455, ack 3200525456, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 248822624 ecr 6918927], length 0* *10:21:38.042829 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 1, win 115, options [nop,nop,TS val 6918928 ecr 248822624], length 0* *10:21:38.043374 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1:195, ack 1, win 115, options [nop,nop,TS val 6918928 ecr 248822624], length 194SMB PACKET: SMBnegprot (REQUEST)* *10:21:38.043903 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1:210, ack 195, win 514, options [nop,nop,TS val 248822624 ecr 6918928], length 209SMB PACKET: SMBnegprot (REPLY)* *10:21:38.043919 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 210, win 123, options [nop,nop,TS val 6918929 ecr 248822624], length 0* *10:21:38.044868 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 195:387, ack 210, win 123, options [nop,nop,TS val 6918930 ecr 248822624], length 192SMB PACKET: SMBsesssetupX (REQUEST)* *10:21:38.045203 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 210:732, ack 387, win 513, options [nop,nop,TS val 248822624 ecr 6918930], length 522SMB PACKET: SMBsesssetupX (REPLY)* *10:21:38.045770 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 387:905, ack 732, win 131, options [nop,nop,TS val 6918931 ecr 248822624], length 518SMB PACKET: SMBsesssetupX (REQUEST)* *10:21:38.047195 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 732:972, ack 905, win 511, options [nop,nop,TS val 248822624 ecr 6918931], length 240SMB PACKET: SMBsesssetupX (REPLY)* *10:21:38.047568 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 905:1027, ack 972, win 140, options [nop,nop,TS val 6918932 ecr 248822624], length 122SMB PACKET: SMBtconX (REQUEST)* *10:21:38.047985 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 972:1032, ack 1027, win 511, options [nop,nop,TS val 248822624 ecr 6918932], length 60SMB PACKET: SMBtconX (REPLY)* *10:21:38.048235 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1027:1131, ack 1032, win 140, options [nop,nop,TS val 6918933 ecr 248822624], length 104SMB PACKET: SMBntcreateX (REQUEST)* *10:21:38.048698 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1032:1139, ack 1131, win 511, options [nop,nop,TS val 248822624 ecr 6918933], length 107SMB PACKET: SMBntcreateX (REPLY)* *10:21:38.048989 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1131:1291, ack 1139, win 140, options [nop,nop,TS val 6918934 ecr 248822624], length 160SMB PACKET: SMBtrans (REQUEST)* *10:21:38.049378 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1139:1267, ack 1291, win 510, options [nop,nop,TS val 248822624 ecr 6918934], length 128SMB PACKET: SMBtrans (REPLY)* *10:21:38.050552 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1291:1459, ack 1267, win 148, options [nop,nop,TS val 6918935 ecr 248822624], length 168SMB PACKET: SMBtrans (REQUEST)* *10:21:38.050950 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1267:1375, ack 1459, win 509, options [nop,nop,TS val 248822625 ecr 6918935], length 108SMB PACKET: SMBtrans (REPLY)* *10:21:38.051805 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1459:1593, ack 1375, win 148, options [nop,nop,TS val 6918937 ecr 248822625], length 134SMB PACKET: SMBtrans (REQUEST)* *10:21:38.052072 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1375:1655, ack 1593, win 509, options [nop,nop,TS val 248822625 ecr 6918937], length 280SMB PACKET: SMBtrans (REPLY)* *10:21:38.053560 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1593:1727, ack 1655, win 156, options [nop,nop,TS val 6918938 ecr 248822625], length 134SMB PACKET: SMBtrans (REQUEST)* *10:21:38.053875 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1655:1755, ack 1727, win 514, options [nop,nop,TS val 248822625 ecr 6918938], length 100SMB PACKET: SMBtrans (REPLY)* *10:21:38.060487 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1727:1905, ack 1755, win 156, options [nop,nop,TS val 6918945 ecr 248822625], length 178SMB PACKET: SMBtrans (REQUEST)* *10:21:38.061143 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1755:1999, ack 1905, win 514, options [nop,nop,TS val 248822626 ecr 6918945], length 244SMB PACKET: SMBtrans (REPLY)* *10:21:38.063073 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1905:2065, ack 1999, win 165, options [nop,nop,TS val 6918948 ecr 248822626], length 160SMB PACKET: SMBtrans (REQUEST)* *10:21:38.069191 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1999:2087, ack 2065, win 513, options [nop,nop,TS val 248822626 ecr 6918948], length 88SMB PACKET: SMBtrans (REPLY)* *10:21:38.088743 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 2065:3421, ack 2087, win 165, options [nop,nop,TS val 6918974 ecr 248822626], length 1356SMB PACKET: SMBtrans (REQUEST)* *10:21:38.203820 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2087:2195, ack 3421, win 514, options [nop,nop,TS val 248822640 ecr 6918974], length 108SMB PACKET: SMBtrans (REPLY)* *10:21:38.205063 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3421:3601, ack 2195, win 165, options [nop,nop,TS val 6919090 ecr 248822640], length 180SMB PACKET: SMBtrans (REQUEST)* *10:21:38.205715 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2195:2303, ack 3601, win 514, options [nop,nop,TS val 248822640 ecr 6919090], length 108SMB PACKET: SMBtrans (REPLY)* *10:21:38.206634 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3601:3741, ack 2303, win 165, options [nop,nop,TS val 6919092 ecr 248822640], length 140SMB PACKET: SMBtrans (REQUEST)* *10:21:38.209567 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2303:2391, ack 3741, win 513, options [nop,nop,TS val 248822640 ecr 6919092], length 88SMB PACKET: SMBtrans (REPLY)* *10:21:38.210883 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3741:3997, ack 2391, win 165, options [nop,nop,TS val 6919096 ecr 248822640], length 256SMB PACKET: SMBtrans (REQUEST)* *10:21:38.290133 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2391:2479, ack 3997, win 512, options [nop,nop,TS val 248822647 ecr 6919096], length 88SMB PACKET: SMBtrans (REPLY)* *10:21:38.291716 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3997:4262, ack 2479, win 165, options [nop,nop,TS val 6919177 ecr 248822647], length 265SMB PACKET: SMBtrans (REQUEST)* *10:21:38.294583 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2479:2571, ack 4262, win 511, options [nop,nop,TS val 248822649 ecr 6919177], length 92SMB PACKET: SMBtrans (REPLY)* *10:21:38.333630 IP kwtpocpbis01.solipa.local.42260 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 2571, win 165, options [nop,nop,TS val 6919219 ecr 248822649], length 0* *10:21:38.713471 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [S], seq 1205005628, win 14600, options [mss 1460,sackOK,TS val 6919598 ecr 0,nop,wscale 7], length 0* *10:21:38.713838 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [S.], seq 3996989028, ack 1205005629, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 248822691 ecr 6919598], length 0* *10:21:38.713861 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 1, win 115, options [nop,nop,TS val 6919599 ecr 248822691], length 0* *10:21:38.714196 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1:195, ack 1, win 115, options [nop,nop,TS val 6919599 ecr 248822691], length 194SMB PACKET: SMBnegprot (REQUEST)* *10:21:38.714773 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1:210, ack 195, win 514, options [nop,nop,TS val 248822691 ecr 6919599], length 209SMB PACKET: SMBnegprot (REPLY)* *10:21:38.714787 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 210, win 123, options [nop,nop,TS val 6919600 ecr 248822691], length 0* *10:21:38.715561 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 195:387, ack 210, win 123, options [nop,nop,TS val 6919600 ecr 248822691], length 192SMB PACKET: SMBsesssetupX (REQUEST)* *10:21:38.715981 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 210:732, ack 387, win 513, options [nop,nop,TS val 248822691 ecr 6919600], length 522SMB PACKET: SMBsesssetupX (REPLY)* *10:21:38.716465 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 387:905, ack 732, win 131, options [nop,nop,TS val 6919601 ecr 248822691], length 518SMB PACKET: SMBsesssetupX (REQUEST)* *10:21:38.718165 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 732:972, ack 905, win 511, options [nop,nop,TS val 248822691 ecr 6919601], length 240SMB PACKET: SMBsesssetupX (REPLY)* *10:21:38.718455 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 905:1027, ack 972, win 140, options [nop,nop,TS val 6919603 ecr 248822691], length 122SMB PACKET: SMBtconX (REQUEST)* *10:21:38.718773 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 972:1032, ack 1027, win 511, options [nop,nop,TS val 248822691 ecr 6919603], length 60SMB PACKET: SMBtconX (REPLY)* *10:21:38.719028 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1027:1135, ack 1032, win 140, options [nop,nop,TS val 6919604 ecr 248822691], length 108SMB PACKET: SMBntcreateX (REQUEST)* *10:21:38.719404 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1032:1139, ack 1135, win 511, options [nop,nop,TS val 248822691 ecr 6919604], length 107SMB PACKET: SMBntcreateX (REPLY)* *10:21:38.719791 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1135:1295, ack 1139, win 140, options [nop,nop,TS val 6919605 ecr 248822691], length 160SMB PACKET: SMBtrans (REQUEST)* *10:21:38.720098 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1139:1267, ack 1295, win 510, options [nop,nop,TS val 248822691 ecr 6919605], length 128SMB PACKET: SMBtrans (REPLY)* *10:21:38.720995 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1295:1465, ack 1267, win 148, options [nop,nop,TS val 6919606 ecr 248822691], length 170SMB PACKET: SMBtrans (REQUEST)* *10:21:38.721306 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1267:1395, ack 1465, win 509, options [nop,nop,TS val 248822692 ecr 6919606], length 128SMB PACKET: SMBtrans (REPLY)* *10:21:38.722086 IP kwtpocpbis01.solipa.local.42261 > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [F.], seq 1465, ack 1395, win 156, options [nop,nop,TS val 6919607 ecr 248822692], length 0* *10:21:38.722665 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [.], ack 1466, win 509, options [nop,nop,TS val 248822692 ecr 6919607], length 0* *10:21:38.722735 IP kwttestdc001.kwttestdc.com.microsoft-ds > kwtpocpbis01.solipa.local.42261: Flags [R.], seq 1395, ack 1466, win 0, length 0* On Wed, Mar 4, 2015 at 10:07 AM, Alexander Bokovoy wrote: > On Wed, 04 Mar 2015, Ben .T.George wrote: > >> HI >> >> i have re-installed IPA with latest 4.1 version. >> >> installed packages by using >> https://copr.fedoraproject.org/coprs/mkosek/freeipa/ repos >> >> # ipa-server-install went successfully without any error an it says the >> same on log files >> >> *[root at kwtpocpbis01 ~]# kinit admin* >> *Password for admin at SOLIPA.LOCAL:* >> *[root at kwtpocpbis01 ~]# klist* >> *Ticket cache: KEYRING:persistent:0:0* >> *Default principal: admin at SOLIPA.LOCAL* >> >> *Valid starting Expires Service principal* >> *03/04/2015 08:36:55 03/05/2015 08:36:51 krbtgt/SOLIPA.LOCAL at SOLIPA. >> LOCAL* >> *[root at kwtpocpbis01 ~]# geten* >> *getenforce getent* >> *[root at kwtpocpbis01 ~]# getent passwd admin* >> *admin:*:4400000:4400000:Administrator:/home/admin:/bin/bash* >> >> >> *# ipa-adtrust-install --netbios-name=SOLIPA -a Passw0rd* also >> successfully >> went . >> >> DNS is working fine as expected. >> >> *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.kwttestdc.com >> * >> >> *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV >> _ldap._tcp.kwttestdc.com * >> *;; global options: +cmd* >> *;; Got answer:* >> *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26944* >> *;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* >> >> *;; OPT PSEUDOSECTION:* >> *; EDNS: version: 0, flags:; udp: 4000* >> *;; QUESTION SECTION:* >> *;_ldap._tcp.kwttestdc.com . IN SRV* >> >> *;; ANSWER SECTION:* >> *_ldap._tcp.kwttestdc.com . 600 IN SRV >> 0 100 389 kwttestdc001.kwttestdc.com > >.* >> >> *;; ADDITIONAL SECTION:* >> *kwttestdc001.kwttestdc.com . 3600 IN >> A 172.16.104.231* >> >> *;; Query time: 0 msec* >> *;; SERVER: 172.16.104.231#53(172.16.104.231)* >> *;; WHEN: Wed Mar 04 08:41:26 AST 2015* >> *;; MSG SIZE rcvd: 115* >> >> *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.solipa.local* >> >> *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV >> _ldap._tcp.solipa.local* >> *;; global options: +cmd* >> *;; Got answer:* >> *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6196* >> *;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* >> >> *;; OPT PSEUDOSECTION:* >> *; EDNS: version: 0, flags:; udp: 4000* >> *;; QUESTION SECTION:* >> *;_ldap._tcp.solipa.local. IN SRV* >> >> *;; ANSWER SECTION:* >> *_ldap._tcp.solipa.local. 11944 IN SRV 0 100 389 >> kwtpocpbis01.solipa.local.* >> >> *;; ADDITIONAL SECTION:* >> *kwtpocpbis01.solipa.local. 1200 IN A 172.16.107.244* >> >> *;; Query time: 2 msec* >> *;; SERVER: 172.16.104.231#53(172.16.104.231)* >> *;; WHEN: Wed Mar 04 08:41:34 AST 2015* >> *;; MSG SIZE rcvd: 113* >> >> But when i try to trust add AD, i am getting error >> >> [root at kwtpocpbis01 ~]# ipa trust-add --type=ad kwttestdc.com --admin >> adm-ben.george --password >> Active Directory domain administrator's password: >> ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most >> likely it is a DNS or firewall issue >> >> I checked from firewall status on both IPA and AD, and it was in off >> state. >> > You really need to find out what is wrong between AD and IPA. The > message above is based on what AD DC reports back to IPA when it tried > to validate the trust and was not able to contact IPA DCs. > > We cannot influence ourselves this part, as AD DC uses SRV records in > DNS to find out which domain controller to contact and if it fails to > contact us for any reason (firewall, DNS is broken from AD DC > perspective, routing brings it to a different IP address, etc), it will > complain like that and never proceed. > > You may try to run tcpdump or wireshark and see what happens on the > network at the time of 'ipa trust-add', specifically, whom AD DC is > talking to and where it takes a DNS record. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From reesb at hushmail.com Wed Mar 4 08:43:54 2015 From: reesb at hushmail.com (reesb at hushmail.com) Date: Wed, 04 Mar 2015 16:43:54 +0800 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source Message-ID: <20150304084354.97EB2C043D@smtp.hushmail.com> Hi,I've read the thread from Nov and checked out http://www.freeipa.org/page/HowTo/vsphere5_integration however i'm still having trouble getting vpshere to use freeipa as an identity source. I've set the base DN for users and groups, the connection url and username and password and my vadmin account connects correctly however when i try to log in as a user (whom i've assigned permissions to) i get an authentication error that states it may be caused by a malfunctioning identity source. Also I have modified my ldap schema as directed in the howto however (and i'm pretty sure this is the root of my problem) I notice that when I do an ldapsearch for a group which i've assigned administrator permissions it does not have the 'uniqueMember' attribute. The ldapmodify command seemed to run correctly without any complaints. Also i'm running freeipa 4.1. Watching the ldap traffic between the two boxes show that vcenter is binding successfully however when it does a search request with the following filter;"Filter: (&(objectClass=groupOfUniqueNames)(uniqueMember=uid=adminuser,cn=users,cn=compat,dc=localdomain,dc=local))"it returns no results. Does anyone have any suggestions? Cheers, Rees -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Wed Mar 4 10:00:49 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 4 Mar 2015 13:00:49 +0300 Subject: [Freeipa-users] how can i fix ipa: ERROR: AD DC was unable to reach any IPA domain controller In-Reply-To: References: <20150304070706.GW25455@redhat.com> Message-ID: i found that some DNS mismatching while trying to add AD. but that dns is not listed anywhere that is showing under krb5kdc.log. CLIENT_NOT_FOUND error message, with some IP address. let me try to re-install everything. which is the suggested Best software version combination ? Redhat 7 + IPA 3.3 , Redhat 7 + IPA 4.1 or Redhat6.6 + IPA 4.1 On Wed, Mar 4, 2015 at 11:31 AM, Ben .T.George wrote: > Hi i have done tcpdump against AD ip > > *10:21:34.033939 IP kwtpocpbis01.solipa.local.48731 > > kwttestdc001.kwttestdc.com.domain: 39643+ SRV? _ldap._tcp.solipa.local. > (41)* > *10:21:34.034530 IP kwttestdc001.kwttestdc.com.domain > > kwtpocpbis01.solipa.local.48731: 39643 1/0/1 SRV > kwtpocpbis01.solipa.local.:389 0 100 (102)* > *10:21:38.026794 IP kwtpocpbis01.solipa.local.42160 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [F.], seq 63944419, ack > 521272023, win 165, options [nop,nop,TS val 6918912 ecr 248450971], length > 0* > *10:21:38.027095 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42160: Flags [.], ack 1, win 511, options > [nop,nop,TS val 248822622 ecr 6918912], length 0* > *10:21:38.027517 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42160: Flags [R.], seq 1, ack 1, win 0, length 0* > *10:21:38.031732 IP kwtpocpbis01.solipa.local.34108 > > kwttestdc001.kwttestdc.com.domain: 6437+ SRV? _ldap._tcp.kwttestdc.com > . (42)* > *10:21:38.032554 IP kwttestdc001.kwttestdc.com.domain > > kwtpocpbis01.solipa.local.34108: 6437* 1/0/1 SRV > kwttestdc001.kwttestdc.com.:389 0 100 (104)* > *10:21:38.032827 IP kwtpocpbis01.solipa.local.48294 > > kwttestdc001.kwttestdc.com.domain: 64621+ AAAA? kwttestdc001.kwttestdc.com > . (44)* > *10:21:38.033191 IP kwttestdc001.kwttestdc.com.domain > > kwtpocpbis01.solipa.local.48294: 64621* 0/1/0 (91)* > *10:21:38.033268 IP kwtpocpbis01.solipa.local.39812 > > kwttestdc001.kwttestdc.com.domain: 7211+ AAAA? kwttestdc001.kwttestdc.com > . (44)* > *10:21:38.033797 IP kwttestdc001.kwttestdc.com.domain > > kwtpocpbis01.solipa.local.39812: 7211* 0/1/0 (91)* > *10:21:38.033836 IP kwtpocpbis01.solipa.local.37700 > > kwttestdc001.kwttestdc.com.domain: 48543+ A? kwttestdc001.kwttestdc.com > . (44)* > *10:21:38.034193 IP kwttestdc001.kwttestdc.com.domain > > kwtpocpbis01.solipa.local.37700: 48543* 1/0/0 A 172.16.104.231 (60)* > *10:21:38.035587 IP kwtpocpbis01.solipa.local.48384 > > kwttestdc001.kwttestdc.com.ldap: UDP, length 82* > *10:21:38.035925 IP kwttestdc001.kwttestdc.com.ldap > > kwtpocpbis01.solipa.local.48384: UDP, length 188* > *10:21:38.037107 IP kwtpocpbis01.solipa.local.44461 > > kwttestdc001.kwttestdc.com.ldap: Flags [S], seq 2172952938 <2172952938>, > win 14600, options [mss 1460,sackOK,TS val 6918922 ecr 0,nop,wscale 7], > length 0* > *10:21:38.037577 IP kwttestdc001.kwttestdc.com.ldap > > kwtpocpbis01.solipa.local.44461: Flags [S.], seq 4067674102 <4067674102>, > ack 2172952939 <2172952939>, win 8192, options [mss 1460,nop,wscale > 8,sackOK,TS val 248822623 ecr 6918922], length 0* > *10:21:38.037594 IP kwtpocpbis01.solipa.local.44461 > > kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 1, win 115, options > [nop,nop,TS val 6918922 ecr 248822623], length 0* > *10:21:38.037627 IP kwtpocpbis01.solipa.local.44461 > > kwttestdc001.kwttestdc.com.ldap: Flags [P.], seq 1:75, ack 1, win 115, > options [nop,nop,TS val 6918922 ecr 248822623], length 74* > *10:21:38.038501 IP kwttestdc001.kwttestdc.com.ldap > > kwtpocpbis01.solipa.local.44461: Flags [.], seq 1:1449, ack 75, win 514, > options [nop,nop,TS val 248822623 ecr 6918922], length 1448* > *10:21:38.038520 IP kwtpocpbis01.solipa.local.44461 > > kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 1449, win 137, options > [nop,nop,TS val 6918923 ecr 248822623], length 0* > *10:21:38.038526 IP kwttestdc001.kwttestdc.com.ldap > > kwtpocpbis01.solipa.local.44461: Flags [.], seq 1449:2897, ack 75, win 514, > options [nop,nop,TS val 248822623 ecr 6918922], length 1448* > *10:21:38.038534 IP kwtpocpbis01.solipa.local.44461 > > kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 2897, win 160, options > [nop,nop,TS val 6918923 ecr 248822623], length 0* > *10:21:38.038703 IP kwttestdc001.kwttestdc.com.ldap > > kwtpocpbis01.solipa.local.44461: Flags [P.], seq 2897:3228, ack 75, win > 514, options [nop,nop,TS val 248822623 ecr 6918923], length 331* > *10:21:38.038711 IP kwtpocpbis01.solipa.local.44461 > > kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 3228, win 182, options > [nop,nop,TS val 6918924 ecr 248822623], length 0* > *10:21:38.039039 IP kwtpocpbis01.solipa.local.44461 > > kwttestdc001.kwttestdc.com.ldap: Flags [P.], seq 75:117, ack 3228, win 182, > options [nop,nop,TS val 6918924 ecr 248822623], length 42* > *10:21:38.039055 IP kwtpocpbis01.solipa.local.44461 > > kwttestdc001.kwttestdc.com.ldap: Flags [F.], seq 117, ack 3228, win 182, > options [nop,nop,TS val 6918924 ecr 248822623], length 0* > *10:21:38.039383 IP kwttestdc001.kwttestdc.com.ldap > > kwtpocpbis01.solipa.local.44461: Flags [.], ack 118, win 514, options > [nop,nop,TS val 248822623 ecr 6918924], length 0* > *10:21:38.039406 IP kwttestdc001.kwttestdc.com.ldap > > kwtpocpbis01.solipa.local.44461: Flags [R.], seq 3228, ack 118, win 0, > length 0* > *10:21:38.042568 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [S], seq 3200525455, win > 14600, options [mss 1460,sackOK,TS val 6918927 ecr 0,nop,wscale 7], length > 0* > *10:21:38.042810 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [S.], seq 2793269455 <2793269455>, > ack 3200525456, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val > 248822624 ecr 6918927], length 0* > *10:21:38.042829 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 1, win 115, options > [nop,nop,TS val 6918928 ecr 248822624], length 0* > *10:21:38.043374 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1:195, ack 1, win > 115, options [nop,nop,TS val 6918928 ecr 248822624], length 194SMB PACKET: > SMBnegprot (REQUEST)* > > *10:21:38.043903 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1:210, ack 195, win 514, > options [nop,nop,TS val 248822624 ecr 6918928], length 209SMB PACKET: > SMBnegprot (REPLY)* > > *10:21:38.043919 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 210, win 123, > options [nop,nop,TS val 6918929 ecr 248822624], length 0* > *10:21:38.044868 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 195:387, ack 210, > win 123, options [nop,nop,TS val 6918930 ecr 248822624], length 192SMB > PACKET: SMBsesssetupX (REQUEST)* > > *10:21:38.045203 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 210:732, ack 387, win 513, > options [nop,nop,TS val 248822624 ecr 6918930], length 522SMB PACKET: > SMBsesssetupX (REPLY)* > > *10:21:38.045770 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 387:905, ack 732, > win 131, options [nop,nop,TS val 6918931 ecr 248822624], length 518SMB > PACKET: SMBsesssetupX (REQUEST)* > > *10:21:38.047195 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 732:972, ack 905, win 511, > options [nop,nop,TS val 248822624 ecr 6918931], length 240SMB PACKET: > SMBsesssetupX (REPLY)* > > *10:21:38.047568 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 905:1027, ack 972, > win 140, options [nop,nop,TS val 6918932 ecr 248822624], length 122SMB > PACKET: SMBtconX (REQUEST)* > > *10:21:38.047985 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 972:1032, ack 1027, win > 511, options [nop,nop,TS val 248822624 ecr 6918932], length 60SMB PACKET: > SMBtconX (REPLY)* > > *10:21:38.048235 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1027:1131, ack > 1032, win 140, options [nop,nop,TS val 6918933 ecr 248822624], length > 104SMB PACKET: SMBntcreateX (REQUEST)* > > *10:21:38.048698 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1032:1139, ack 1131, win > 511, options [nop,nop,TS val 248822624 ecr 6918933], length 107SMB PACKET: > SMBntcreateX (REPLY)* > > *10:21:38.048989 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1131:1291, ack > 1139, win 140, options [nop,nop,TS val 6918934 ecr 248822624], length > 160SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.049378 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1139:1267, ack 1291, win > 510, options [nop,nop,TS val 248822624 ecr 6918934], length 128SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.050552 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1291:1459, ack > 1267, win 148, options [nop,nop,TS val 6918935 ecr 248822624], length > 168SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.050950 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1267:1375, ack 1459, win > 509, options [nop,nop,TS val 248822625 ecr 6918935], length 108SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.051805 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1459:1593, ack > 1375, win 148, options [nop,nop,TS val 6918937 ecr 248822625], length > 134SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.052072 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1375:1655, ack 1593, win > 509, options [nop,nop,TS val 248822625 ecr 6918937], length 280SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.053560 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1593:1727, ack > 1655, win 156, options [nop,nop,TS val 6918938 ecr 248822625], length > 134SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.053875 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1655:1755, ack 1727, win > 514, options [nop,nop,TS val 248822625 ecr 6918938], length 100SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.060487 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1727:1905, ack > 1755, win 156, options [nop,nop,TS val 6918945 ecr 248822625], length > 178SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.061143 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1755:1999, ack 1905, win > 514, options [nop,nop,TS val 248822626 ecr 6918945], length 244SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.063073 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1905:2065, ack > 1999, win 165, options [nop,nop,TS val 6918948 ecr 248822626], length > 160SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.069191 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1999:2087, ack 2065, win > 513, options [nop,nop,TS val 248822626 ecr 6918948], length 88SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.088743 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 2065:3421, ack > 2087, win 165, options [nop,nop,TS val 6918974 ecr 248822626], length > 1356SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.203820 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2087:2195, ack 3421, win > 514, options [nop,nop,TS val 248822640 ecr 6918974], length 108SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.205063 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3421:3601, ack > 2195, win 165, options [nop,nop,TS val 6919090 ecr 248822640], length > 180SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.205715 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2195:2303, ack 3601, win > 514, options [nop,nop,TS val 248822640 ecr 6919090], length 108SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.206634 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3601:3741, ack > 2303, win 165, options [nop,nop,TS val 6919092 ecr 248822640], length > 140SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.209567 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2303:2391, ack 3741, win > 513, options [nop,nop,TS val 248822640 ecr 6919092], length 88SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.210883 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3741:3997, ack > 2391, win 165, options [nop,nop,TS val 6919096 ecr 248822640], length > 256SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.290133 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2391:2479, ack 3997, win > 512, options [nop,nop,TS val 248822647 ecr 6919096], length 88SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.291716 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3997:4262, ack > 2479, win 165, options [nop,nop,TS val 6919177 ecr 248822647], length > 265SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.294583 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2479:2571, ack 4262, win > 511, options [nop,nop,TS val 248822649 ecr 6919177], length 92SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.333630 IP kwtpocpbis01.solipa.local.42260 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 2571, win 165, > options [nop,nop,TS val 6919219 ecr 248822649], length 0* > *10:21:38.713471 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [S], seq 1205005628 > <1205005628>, win 14600, options [mss 1460,sackOK,TS val 6919598 ecr > 0,nop,wscale 7], length 0* > *10:21:38.713838 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [S.], seq 3996989028, ack 1205005629 > <1205005629>, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val > 248822691 ecr 6919598], length 0* > *10:21:38.713861 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 1, win 115, options > [nop,nop,TS val 6919599 ecr 248822691], length 0* > *10:21:38.714196 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1:195, ack 1, win > 115, options [nop,nop,TS val 6919599 ecr 248822691], length 194SMB PACKET: > SMBnegprot (REQUEST)* > > *10:21:38.714773 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1:210, ack 195, win 514, > options [nop,nop,TS val 248822691 ecr 6919599], length 209SMB PACKET: > SMBnegprot (REPLY)* > > *10:21:38.714787 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 210, win 123, > options [nop,nop,TS val 6919600 ecr 248822691], length 0* > *10:21:38.715561 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 195:387, ack 210, > win 123, options [nop,nop,TS val 6919600 ecr 248822691], length 192SMB > PACKET: SMBsesssetupX (REQUEST)* > > *10:21:38.715981 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 210:732, ack 387, win 513, > options [nop,nop,TS val 248822691 ecr 6919600], length 522SMB PACKET: > SMBsesssetupX (REPLY)* > > *10:21:38.716465 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 387:905, ack 732, > win 131, options [nop,nop,TS val 6919601 ecr 248822691], length 518SMB > PACKET: SMBsesssetupX (REQUEST)* > > *10:21:38.718165 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 732:972, ack 905, win 511, > options [nop,nop,TS val 248822691 ecr 6919601], length 240SMB PACKET: > SMBsesssetupX (REPLY)* > > *10:21:38.718455 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 905:1027, ack 972, > win 140, options [nop,nop,TS val 6919603 ecr 248822691], length 122SMB > PACKET: SMBtconX (REQUEST)* > > *10:21:38.718773 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 972:1032, ack 1027, win > 511, options [nop,nop,TS val 248822691 ecr 6919603], length 60SMB PACKET: > SMBtconX (REPLY)* > > *10:21:38.719028 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1027:1135, ack > 1032, win 140, options [nop,nop,TS val 6919604 ecr 248822691], length > 108SMB PACKET: SMBntcreateX (REQUEST)* > > *10:21:38.719404 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1032:1139, ack 1135, win > 511, options [nop,nop,TS val 248822691 ecr 6919604], length 107SMB PACKET: > SMBntcreateX (REPLY)* > > *10:21:38.719791 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1135:1295, ack > 1139, win 140, options [nop,nop,TS val 6919605 ecr 248822691], length > 160SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.720098 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1139:1267, ack 1295, win > 510, options [nop,nop,TS val 248822691 ecr 6919605], length 128SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.720995 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1295:1465, ack > 1267, win 148, options [nop,nop,TS val 6919606 ecr 248822691], length > 170SMB PACKET: SMBtrans (REQUEST)* > > *10:21:38.721306 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1267:1395, ack 1465, win > 509, options [nop,nop,TS val 248822692 ecr 6919606], length 128SMB PACKET: > SMBtrans (REPLY)* > > *10:21:38.722086 IP kwtpocpbis01.solipa.local.42261 > > kwttestdc001.kwttestdc.com.microsoft-ds: Flags [F.], seq 1465, ack 1395, > win 156, options [nop,nop,TS val 6919607 ecr 248822692], length 0* > *10:21:38.722665 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [.], ack 1466, win 509, options > [nop,nop,TS val 248822692 ecr 6919607], length 0* > *10:21:38.722735 IP kwttestdc001.kwttestdc.com.microsoft-ds > > kwtpocpbis01.solipa.local.42261: Flags [R.], seq 1395, ack 1466, win 0, > length 0* > > > > On Wed, Mar 4, 2015 at 10:07 AM, Alexander Bokovoy > wrote: > >> On Wed, 04 Mar 2015, Ben .T.George wrote: >> >>> HI >>> >>> i have re-installed IPA with latest 4.1 version. >>> >>> installed packages by using >>> https://copr.fedoraproject.org/coprs/mkosek/freeipa/ repos >>> >>> # ipa-server-install went successfully without any error an it says the >>> same on log files >>> >>> *[root at kwtpocpbis01 ~]# kinit admin* >>> *Password for admin at SOLIPA.LOCAL:* >>> *[root at kwtpocpbis01 ~]# klist* >>> *Ticket cache: KEYRING:persistent:0:0* >>> *Default principal: admin at SOLIPA.LOCAL* >>> >>> *Valid starting Expires Service principal* >>> *03/04/2015 08:36:55 03/05/2015 08:36:51 krbtgt/SOLIPA.LOCAL at SOLIPA. >>> LOCAL* >>> *[root at kwtpocpbis01 ~]# geten* >>> *getenforce getent* >>> *[root at kwtpocpbis01 ~]# getent passwd admin* >>> *admin:*:4400000:4400000:Administrator:/home/admin:/bin/bash* >>> >>> >>> *# ipa-adtrust-install --netbios-name=SOLIPA -a Passw0rd* also >>> successfully >>> went . >>> >>> DNS is working fine as expected. >>> >>> *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.kwttestdc.com >>> * >>> >>> *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV >>> _ldap._tcp.kwttestdc.com * >>> *;; global options: +cmd* >>> *;; Got answer:* >>> *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26944* >>> *;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* >>> >>> *;; OPT PSEUDOSECTION:* >>> *; EDNS: version: 0, flags:; udp: 4000* >>> *;; QUESTION SECTION:* >>> *;_ldap._tcp.kwttestdc.com . IN SRV* >>> >>> *;; ANSWER SECTION:* >>> *_ldap._tcp.kwttestdc.com . 600 IN SRV >>> 0 100 389 kwttestdc001.kwttestdc.com >> >.* >>> >>> *;; ADDITIONAL SECTION:* >>> *kwttestdc001.kwttestdc.com . 3600 IN >>> A 172.16.104.231* >>> >>> *;; Query time: 0 msec* >>> *;; SERVER: 172.16.104.231#53(172.16.104.231)* >>> *;; WHEN: Wed Mar 04 08:41:26 AST 2015* >>> *;; MSG SIZE rcvd: 115* >>> >>> *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.solipa.local* >>> >>> *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV >>> _ldap._tcp.solipa.local* >>> *;; global options: +cmd* >>> *;; Got answer:* >>> *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6196* >>> *;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* >>> >>> *;; OPT PSEUDOSECTION:* >>> *; EDNS: version: 0, flags:; udp: 4000* >>> *;; QUESTION SECTION:* >>> *;_ldap._tcp.solipa.local. IN SRV* >>> >>> *;; ANSWER SECTION:* >>> *_ldap._tcp.solipa.local. 11944 IN SRV 0 100 389 >>> kwtpocpbis01.solipa.local.* >>> >>> *;; ADDITIONAL SECTION:* >>> *kwtpocpbis01.solipa.local. 1200 IN A 172.16.107.244* >>> >>> *;; Query time: 2 msec* >>> *;; SERVER: 172.16.104.231#53(172.16.104.231)* >>> *;; WHEN: Wed Mar 04 08:41:34 AST 2015* >>> *;; MSG SIZE rcvd: 113* >>> >>> But when i try to trust add AD, i am getting error >>> >>> [root at kwtpocpbis01 ~]# ipa trust-add --type=ad kwttestdc.com --admin >>> adm-ben.george --password >>> Active Directory domain administrator's password: >>> ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most >>> likely it is a DNS or firewall issue >>> >>> I checked from firewall status on both IPA and AD, and it was in off >>> state. >>> >> You really need to find out what is wrong between AD and IPA. The >> message above is based on what AD DC reports back to IPA when it tried >> to validate the trust and was not able to contact IPA DCs. >> >> We cannot influence ourselves this part, as AD DC uses SRV records in >> DNS to find out which domain controller to contact and if it fails to >> contact us for any reason (firewall, DNS is broken from AD DC >> perspective, routing brings it to a different IP address, etc), it will >> complain like that and never proceed. >> >> You may try to run tcpdump or wireshark and see what happens on the >> network at the time of 'ipa trust-add', specifically, whom AD DC is >> talking to and where it takes a DNS record. >> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 4 10:52:30 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 4 Mar 2015 12:52:30 +0200 Subject: [Freeipa-users] how can i fix ipa: ERROR: AD DC was unable to reach any IPA domain controller In-Reply-To: References: <20150304070706.GW25455@redhat.com> Message-ID: <20150304105230.GX25455@redhat.com> On Wed, 04 Mar 2015, Ben .T.George wrote: >i found that some DNS mismatching while trying to add AD. but that dns is >not listed anywhere > >that is showing under krb5kdc.log. CLIENT_NOT_FOUND error message, with >some IP address. > >let me try to re-install everything. > >which is the suggested Best software version combination ? > >Redhat 7 + IPA 3.3 , Redhat 7 + IPA 4.1 or Redhat6.6 + IPA 4.1 RHEL 7.1 provides IPA 4.1, this is a best combination. I hope it will be released real soon but beta is already available. > >On Wed, Mar 4, 2015 at 11:31 AM, Ben .T.George >wrote: > >> Hi i have done tcpdump against AD ip >> >> *10:21:34.033939 IP kwtpocpbis01.solipa.local.48731 > >> kwttestdc001.kwttestdc.com.domain: 39643+ SRV? _ldap._tcp.solipa.local. >> (41)* >> *10:21:34.034530 IP kwttestdc001.kwttestdc.com.domain > >> kwtpocpbis01.solipa.local.48731: 39643 1/0/1 SRV >> kwtpocpbis01.solipa.local.:389 0 100 (102)* >> *10:21:38.026794 IP kwtpocpbis01.solipa.local.42160 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [F.], seq 63944419, ack >> 521272023, win 165, options [nop,nop,TS val 6918912 ecr 248450971], length >> 0* >> *10:21:38.027095 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42160: Flags [.], ack 1, win 511, options >> [nop,nop,TS val 248822622 ecr 6918912], length 0* >> *10:21:38.027517 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42160: Flags [R.], seq 1, ack 1, win 0, length 0* >> *10:21:38.031732 IP kwtpocpbis01.solipa.local.34108 > >> kwttestdc001.kwttestdc.com.domain: 6437+ SRV? _ldap._tcp.kwttestdc.com >> . (42)* >> *10:21:38.032554 IP kwttestdc001.kwttestdc.com.domain > >> kwtpocpbis01.solipa.local.34108: 6437* 1/0/1 SRV >> kwttestdc001.kwttestdc.com.:389 0 100 (104)* >> *10:21:38.032827 IP kwtpocpbis01.solipa.local.48294 > >> kwttestdc001.kwttestdc.com.domain: 64621+ AAAA? kwttestdc001.kwttestdc.com >> . (44)* >> *10:21:38.033191 IP kwttestdc001.kwttestdc.com.domain > >> kwtpocpbis01.solipa.local.48294: 64621* 0/1/0 (91)* >> *10:21:38.033268 IP kwtpocpbis01.solipa.local.39812 > >> kwttestdc001.kwttestdc.com.domain: 7211+ AAAA? kwttestdc001.kwttestdc.com >> . (44)* >> *10:21:38.033797 IP kwttestdc001.kwttestdc.com.domain > >> kwtpocpbis01.solipa.local.39812: 7211* 0/1/0 (91)* >> *10:21:38.033836 IP kwtpocpbis01.solipa.local.37700 > >> kwttestdc001.kwttestdc.com.domain: 48543+ A? kwttestdc001.kwttestdc.com >> . (44)* >> *10:21:38.034193 IP kwttestdc001.kwttestdc.com.domain > >> kwtpocpbis01.solipa.local.37700: 48543* 1/0/0 A 172.16.104.231 (60)* >> *10:21:38.035587 IP kwtpocpbis01.solipa.local.48384 > >> kwttestdc001.kwttestdc.com.ldap: UDP, length 82* >> *10:21:38.035925 IP kwttestdc001.kwttestdc.com.ldap > >> kwtpocpbis01.solipa.local.48384: UDP, length 188* >> *10:21:38.037107 IP kwtpocpbis01.solipa.local.44461 > >> kwttestdc001.kwttestdc.com.ldap: Flags [S], seq 2172952938 <2172952938>, >> win 14600, options [mss 1460,sackOK,TS val 6918922 ecr 0,nop,wscale 7], >> length 0* >> *10:21:38.037577 IP kwttestdc001.kwttestdc.com.ldap > >> kwtpocpbis01.solipa.local.44461: Flags [S.], seq 4067674102 <4067674102>, >> ack 2172952939 <2172952939>, win 8192, options [mss 1460,nop,wscale >> 8,sackOK,TS val 248822623 ecr 6918922], length 0* >> *10:21:38.037594 IP kwtpocpbis01.solipa.local.44461 > >> kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 1, win 115, options >> [nop,nop,TS val 6918922 ecr 248822623], length 0* >> *10:21:38.037627 IP kwtpocpbis01.solipa.local.44461 > >> kwttestdc001.kwttestdc.com.ldap: Flags [P.], seq 1:75, ack 1, win 115, >> options [nop,nop,TS val 6918922 ecr 248822623], length 74* >> *10:21:38.038501 IP kwttestdc001.kwttestdc.com.ldap > >> kwtpocpbis01.solipa.local.44461: Flags [.], seq 1:1449, ack 75, win 514, >> options [nop,nop,TS val 248822623 ecr 6918922], length 1448* >> *10:21:38.038520 IP kwtpocpbis01.solipa.local.44461 > >> kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 1449, win 137, options >> [nop,nop,TS val 6918923 ecr 248822623], length 0* >> *10:21:38.038526 IP kwttestdc001.kwttestdc.com.ldap > >> kwtpocpbis01.solipa.local.44461: Flags [.], seq 1449:2897, ack 75, win 514, >> options [nop,nop,TS val 248822623 ecr 6918922], length 1448* >> *10:21:38.038534 IP kwtpocpbis01.solipa.local.44461 > >> kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 2897, win 160, options >> [nop,nop,TS val 6918923 ecr 248822623], length 0* >> *10:21:38.038703 IP kwttestdc001.kwttestdc.com.ldap > >> kwtpocpbis01.solipa.local.44461: Flags [P.], seq 2897:3228, ack 75, win >> 514, options [nop,nop,TS val 248822623 ecr 6918923], length 331* >> *10:21:38.038711 IP kwtpocpbis01.solipa.local.44461 > >> kwttestdc001.kwttestdc.com.ldap: Flags [.], ack 3228, win 182, options >> [nop,nop,TS val 6918924 ecr 248822623], length 0* >> *10:21:38.039039 IP kwtpocpbis01.solipa.local.44461 > >> kwttestdc001.kwttestdc.com.ldap: Flags [P.], seq 75:117, ack 3228, win 182, >> options [nop,nop,TS val 6918924 ecr 248822623], length 42* >> *10:21:38.039055 IP kwtpocpbis01.solipa.local.44461 > >> kwttestdc001.kwttestdc.com.ldap: Flags [F.], seq 117, ack 3228, win 182, >> options [nop,nop,TS val 6918924 ecr 248822623], length 0* >> *10:21:38.039383 IP kwttestdc001.kwttestdc.com.ldap > >> kwtpocpbis01.solipa.local.44461: Flags [.], ack 118, win 514, options >> [nop,nop,TS val 248822623 ecr 6918924], length 0* >> *10:21:38.039406 IP kwttestdc001.kwttestdc.com.ldap > >> kwtpocpbis01.solipa.local.44461: Flags [R.], seq 3228, ack 118, win 0, >> length 0* >> *10:21:38.042568 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [S], seq 3200525455, win >> 14600, options [mss 1460,sackOK,TS val 6918927 ecr 0,nop,wscale 7], length >> 0* >> *10:21:38.042810 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [S.], seq 2793269455 <2793269455>, >> ack 3200525456, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val >> 248822624 ecr 6918927], length 0* >> *10:21:38.042829 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 1, win 115, options >> [nop,nop,TS val 6918928 ecr 248822624], length 0* >> *10:21:38.043374 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1:195, ack 1, win >> 115, options [nop,nop,TS val 6918928 ecr 248822624], length 194SMB PACKET: >> SMBnegprot (REQUEST)* >> >> *10:21:38.043903 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1:210, ack 195, win 514, >> options [nop,nop,TS val 248822624 ecr 6918928], length 209SMB PACKET: >> SMBnegprot (REPLY)* >> >> *10:21:38.043919 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 210, win 123, >> options [nop,nop,TS val 6918929 ecr 248822624], length 0* >> *10:21:38.044868 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 195:387, ack 210, >> win 123, options [nop,nop,TS val 6918930 ecr 248822624], length 192SMB >> PACKET: SMBsesssetupX (REQUEST)* >> >> *10:21:38.045203 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 210:732, ack 387, win 513, >> options [nop,nop,TS val 248822624 ecr 6918930], length 522SMB PACKET: >> SMBsesssetupX (REPLY)* >> >> *10:21:38.045770 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 387:905, ack 732, >> win 131, options [nop,nop,TS val 6918931 ecr 248822624], length 518SMB >> PACKET: SMBsesssetupX (REQUEST)* >> >> *10:21:38.047195 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 732:972, ack 905, win 511, >> options [nop,nop,TS val 248822624 ecr 6918931], length 240SMB PACKET: >> SMBsesssetupX (REPLY)* >> >> *10:21:38.047568 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 905:1027, ack 972, >> win 140, options [nop,nop,TS val 6918932 ecr 248822624], length 122SMB >> PACKET: SMBtconX (REQUEST)* >> >> *10:21:38.047985 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 972:1032, ack 1027, win >> 511, options [nop,nop,TS val 248822624 ecr 6918932], length 60SMB PACKET: >> SMBtconX (REPLY)* >> >> *10:21:38.048235 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1027:1131, ack >> 1032, win 140, options [nop,nop,TS val 6918933 ecr 248822624], length >> 104SMB PACKET: SMBntcreateX (REQUEST)* >> >> *10:21:38.048698 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1032:1139, ack 1131, win >> 511, options [nop,nop,TS val 248822624 ecr 6918933], length 107SMB PACKET: >> SMBntcreateX (REPLY)* >> >> *10:21:38.048989 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1131:1291, ack >> 1139, win 140, options [nop,nop,TS val 6918934 ecr 248822624], length >> 160SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.049378 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1139:1267, ack 1291, win >> 510, options [nop,nop,TS val 248822624 ecr 6918934], length 128SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.050552 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1291:1459, ack >> 1267, win 148, options [nop,nop,TS val 6918935 ecr 248822624], length >> 168SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.050950 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1267:1375, ack 1459, win >> 509, options [nop,nop,TS val 248822625 ecr 6918935], length 108SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.051805 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1459:1593, ack >> 1375, win 148, options [nop,nop,TS val 6918937 ecr 248822625], length >> 134SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.052072 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1375:1655, ack 1593, win >> 509, options [nop,nop,TS val 248822625 ecr 6918937], length 280SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.053560 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1593:1727, ack >> 1655, win 156, options [nop,nop,TS val 6918938 ecr 248822625], length >> 134SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.053875 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1655:1755, ack 1727, win >> 514, options [nop,nop,TS val 248822625 ecr 6918938], length 100SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.060487 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1727:1905, ack >> 1755, win 156, options [nop,nop,TS val 6918945 ecr 248822625], length >> 178SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.061143 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1755:1999, ack 1905, win >> 514, options [nop,nop,TS val 248822626 ecr 6918945], length 244SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.063073 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1905:2065, ack >> 1999, win 165, options [nop,nop,TS val 6918948 ecr 248822626], length >> 160SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.069191 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 1999:2087, ack 2065, win >> 513, options [nop,nop,TS val 248822626 ecr 6918948], length 88SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.088743 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 2065:3421, ack >> 2087, win 165, options [nop,nop,TS val 6918974 ecr 248822626], length >> 1356SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.203820 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2087:2195, ack 3421, win >> 514, options [nop,nop,TS val 248822640 ecr 6918974], length 108SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.205063 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3421:3601, ack >> 2195, win 165, options [nop,nop,TS val 6919090 ecr 248822640], length >> 180SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.205715 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2195:2303, ack 3601, win >> 514, options [nop,nop,TS val 248822640 ecr 6919090], length 108SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.206634 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3601:3741, ack >> 2303, win 165, options [nop,nop,TS val 6919092 ecr 248822640], length >> 140SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.209567 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2303:2391, ack 3741, win >> 513, options [nop,nop,TS val 248822640 ecr 6919092], length 88SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.210883 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3741:3997, ack >> 2391, win 165, options [nop,nop,TS val 6919096 ecr 248822640], length >> 256SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.290133 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2391:2479, ack 3997, win >> 512, options [nop,nop,TS val 248822647 ecr 6919096], length 88SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.291716 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 3997:4262, ack >> 2479, win 165, options [nop,nop,TS val 6919177 ecr 248822647], length >> 265SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.294583 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42260: Flags [P.], seq 2479:2571, ack 4262, win >> 511, options [nop,nop,TS val 248822649 ecr 6919177], length 92SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.333630 IP kwtpocpbis01.solipa.local.42260 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 2571, win 165, >> options [nop,nop,TS val 6919219 ecr 248822649], length 0* >> *10:21:38.713471 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [S], seq 1205005628 >> <1205005628>, win 14600, options [mss 1460,sackOK,TS val 6919598 ecr >> 0,nop,wscale 7], length 0* >> *10:21:38.713838 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [S.], seq 3996989028, ack 1205005629 >> <1205005629>, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val >> 248822691 ecr 6919598], length 0* >> *10:21:38.713861 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 1, win 115, options >> [nop,nop,TS val 6919599 ecr 248822691], length 0* >> *10:21:38.714196 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1:195, ack 1, win >> 115, options [nop,nop,TS val 6919599 ecr 248822691], length 194SMB PACKET: >> SMBnegprot (REQUEST)* >> >> *10:21:38.714773 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1:210, ack 195, win 514, >> options [nop,nop,TS val 248822691 ecr 6919599], length 209SMB PACKET: >> SMBnegprot (REPLY)* >> >> *10:21:38.714787 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [.], ack 210, win 123, >> options [nop,nop,TS val 6919600 ecr 248822691], length 0* >> *10:21:38.715561 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 195:387, ack 210, >> win 123, options [nop,nop,TS val 6919600 ecr 248822691], length 192SMB >> PACKET: SMBsesssetupX (REQUEST)* >> >> *10:21:38.715981 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [P.], seq 210:732, ack 387, win 513, >> options [nop,nop,TS val 248822691 ecr 6919600], length 522SMB PACKET: >> SMBsesssetupX (REPLY)* >> >> *10:21:38.716465 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 387:905, ack 732, >> win 131, options [nop,nop,TS val 6919601 ecr 248822691], length 518SMB >> PACKET: SMBsesssetupX (REQUEST)* >> >> *10:21:38.718165 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [P.], seq 732:972, ack 905, win 511, >> options [nop,nop,TS val 248822691 ecr 6919601], length 240SMB PACKET: >> SMBsesssetupX (REPLY)* >> >> *10:21:38.718455 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 905:1027, ack 972, >> win 140, options [nop,nop,TS val 6919603 ecr 248822691], length 122SMB >> PACKET: SMBtconX (REQUEST)* >> >> *10:21:38.718773 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [P.], seq 972:1032, ack 1027, win >> 511, options [nop,nop,TS val 248822691 ecr 6919603], length 60SMB PACKET: >> SMBtconX (REPLY)* >> >> *10:21:38.719028 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1027:1135, ack >> 1032, win 140, options [nop,nop,TS val 6919604 ecr 248822691], length >> 108SMB PACKET: SMBntcreateX (REQUEST)* >> >> *10:21:38.719404 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1032:1139, ack 1135, win >> 511, options [nop,nop,TS val 248822691 ecr 6919604], length 107SMB PACKET: >> SMBntcreateX (REPLY)* >> >> *10:21:38.719791 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1135:1295, ack >> 1139, win 140, options [nop,nop,TS val 6919605 ecr 248822691], length >> 160SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.720098 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1139:1267, ack 1295, win >> 510, options [nop,nop,TS val 248822691 ecr 6919605], length 128SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.720995 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [P.], seq 1295:1465, ack >> 1267, win 148, options [nop,nop,TS val 6919606 ecr 248822691], length >> 170SMB PACKET: SMBtrans (REQUEST)* >> >> *10:21:38.721306 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [P.], seq 1267:1395, ack 1465, win >> 509, options [nop,nop,TS val 248822692 ecr 6919606], length 128SMB PACKET: >> SMBtrans (REPLY)* >> >> *10:21:38.722086 IP kwtpocpbis01.solipa.local.42261 > >> kwttestdc001.kwttestdc.com.microsoft-ds: Flags [F.], seq 1465, ack 1395, >> win 156, options [nop,nop,TS val 6919607 ecr 248822692], length 0* >> *10:21:38.722665 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [.], ack 1466, win 509, options >> [nop,nop,TS val 248822692 ecr 6919607], length 0* >> *10:21:38.722735 IP kwttestdc001.kwttestdc.com.microsoft-ds > >> kwtpocpbis01.solipa.local.42261: Flags [R.], seq 1395, ack 1466, win 0, >> length 0* >> >> >> >> On Wed, Mar 4, 2015 at 10:07 AM, Alexander Bokovoy >> wrote: >> >>> On Wed, 04 Mar 2015, Ben .T.George wrote: >>> >>>> HI >>>> >>>> i have re-installed IPA with latest 4.1 version. >>>> >>>> installed packages by using >>>> https://copr.fedoraproject.org/coprs/mkosek/freeipa/ repos >>>> >>>> # ipa-server-install went successfully without any error an it says the >>>> same on log files >>>> >>>> *[root at kwtpocpbis01 ~]# kinit admin* >>>> *Password for admin at SOLIPA.LOCAL:* >>>> *[root at kwtpocpbis01 ~]# klist* >>>> *Ticket cache: KEYRING:persistent:0:0* >>>> *Default principal: admin at SOLIPA.LOCAL* >>>> >>>> *Valid starting Expires Service principal* >>>> *03/04/2015 08:36:55 03/05/2015 08:36:51 krbtgt/SOLIPA.LOCAL at SOLIPA. >>>> LOCAL* >>>> *[root at kwtpocpbis01 ~]# geten* >>>> *getenforce getent* >>>> *[root at kwtpocpbis01 ~]# getent passwd admin* >>>> *admin:*:4400000:4400000:Administrator:/home/admin:/bin/bash* >>>> >>>> >>>> *# ipa-adtrust-install --netbios-name=SOLIPA -a Passw0rd* also >>>> successfully >>>> went . >>>> >>>> DNS is working fine as expected. >>>> >>>> *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.kwttestdc.com >>>> * >>>> >>>> *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV >>>> _ldap._tcp.kwttestdc.com * >>>> *;; global options: +cmd* >>>> *;; Got answer:* >>>> *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 26944* >>>> *;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* >>>> >>>> *;; OPT PSEUDOSECTION:* >>>> *; EDNS: version: 0, flags:; udp: 4000* >>>> *;; QUESTION SECTION:* >>>> *;_ldap._tcp.kwttestdc.com . IN SRV* >>>> >>>> *;; ANSWER SECTION:* >>>> *_ldap._tcp.kwttestdc.com . 600 IN SRV >>>> 0 100 389 kwttestdc001.kwttestdc.com >>> >.* >>>> >>>> *;; ADDITIONAL SECTION:* >>>> *kwttestdc001.kwttestdc.com . 3600 IN >>>> A 172.16.104.231* >>>> >>>> *;; Query time: 0 msec* >>>> *;; SERVER: 172.16.104.231#53(172.16.104.231)* >>>> *;; WHEN: Wed Mar 04 08:41:26 AST 2015* >>>> *;; MSG SIZE rcvd: 115* >>>> >>>> *[root at kwtpocpbis01 ~]# dig SRV _ldap._tcp.solipa.local* >>>> >>>> *; <<>> DiG 9.9.4-RedHat-9.9.4-20.el7.centos.pkcs11 <<>> SRV >>>> _ldap._tcp.solipa.local* >>>> *;; global options: +cmd* >>>> *;; Got answer:* >>>> *;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 6196* >>>> *;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 2* >>>> >>>> *;; OPT PSEUDOSECTION:* >>>> *; EDNS: version: 0, flags:; udp: 4000* >>>> *;; QUESTION SECTION:* >>>> *;_ldap._tcp.solipa.local. IN SRV* >>>> >>>> *;; ANSWER SECTION:* >>>> *_ldap._tcp.solipa.local. 11944 IN SRV 0 100 389 >>>> kwtpocpbis01.solipa.local.* >>>> >>>> *;; ADDITIONAL SECTION:* >>>> *kwtpocpbis01.solipa.local. 1200 IN A 172.16.107.244* >>>> >>>> *;; Query time: 2 msec* >>>> *;; SERVER: 172.16.104.231#53(172.16.104.231)* >>>> *;; WHEN: Wed Mar 04 08:41:34 AST 2015* >>>> *;; MSG SIZE rcvd: 113* >>>> >>>> But when i try to trust add AD, i am getting error >>>> >>>> [root at kwtpocpbis01 ~]# ipa trust-add --type=ad kwttestdc.com --admin >>>> adm-ben.george --password >>>> Active Directory domain administrator's password: >>>> ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most >>>> likely it is a DNS or firewall issue >>>> >>>> I checked from firewall status on both IPA and AD, and it was in off >>>> state. >>>> >>> You really need to find out what is wrong between AD and IPA. The >>> message above is based on what AD DC reports back to IPA when it tried >>> to validate the trust and was not able to contact IPA DCs. >>> >>> We cannot influence ourselves this part, as AD DC uses SRV records in >>> DNS to find out which domain controller to contact and if it fails to >>> contact us for any reason (firewall, DNS is broken from AD DC >>> perspective, routing brings it to a different IP address, etc), it will >>> complain like that and never proceed. >>> >>> You may try to run tcpdump or wireshark and see what happens on the >>> network at the time of 'ipa trust-add', specifically, whom AD DC is >>> talking to and where it takes a DNS record. >>> >>> -- >>> / Alexander Bokovoy >>> >> >> -- / Alexander Bokovoy From mkosek at redhat.com Wed Mar 4 12:32:29 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Mar 2015 13:32:29 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <20150304084354.97EB2C043D@smtp.hushmail.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> Message-ID: <54F6FB5D.1050606@redhat.com> On 03/04/2015 09:43 AM, reesb at hushmail.com wrote: > Hi,I've read the thread from Nov and checked out > http://www.freeipa.org/page/HowTo/vsphere5_integration however i'm > still having trouble getting vpshere to use freeipa as an identity > source. > I've set the base DN for users and groups, the connection url and > username and password and my vadmin account connects correctly however > when i try to log in as a user (whom i've assigned permissions to) i > get an authentication error that states it may be caused by a > malfunctioning identity source. > Also I have modified my ldap schema as directed in the howto however > (and i'm pretty sure this is the root of my problem) I notice that > when I do an ldapsearch for a group which i've assigned administrator > permissions it does not have the 'uniqueMember' attribute. The > ldapmodify command seemed to run correctly without any complaints. > Also i'm running freeipa 4.1. > Watching the ldap traffic between the two boxes show that vcenter is > binding successfully however when it does a search request with the > following filter;"Filter: > (&(objectClass=groupOfUniqueNames)(uniqueMember=uid=adminuser,cn=users,cn=compat,dc=localdomain,dc=local))"it > returns no results. > > Does anyone have any suggestions? > Cheers, > Rees Given that this HOWTO does not use the vanilla Schema Compatibility settings (FreeIPA Compat Tree by default uses posixGroup objectclass and memberUid attribute for user membership), I would check if the groups really have the right objectclass and uniqueMember generated: # ldapsearch -D "VSPHERE_DN" -x -w "$VSPHERE_DN_PASSWORD" -b "cn=groups,cn=compat,dc=localdomain,dc=local" I expect there will be some problem preventing the LDAP search to succeed. Then we would know where to look next. Martin From gianluca.cecchi at gmail.com Wed Mar 4 13:13:06 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Wed, 4 Mar 2015 14:13:06 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <20150304084354.97EB2C043D@smtp.hushmail.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> Message-ID: On Wed, Mar 4, 2015 at 9:43 AM, wrote: > Hi, > I've read the thread from Nov and checked out > http://www.freeipa.org/page/HowTo/vsphere5_integration however i'm still > having trouble getting vpshere to use freeipa as an identity source. > > I've set the base DN for users and groups, the connection url and username > and password and my vadmin account connects correctly however when i try to > log in as a user (whom i've assigned permissions to) i get an > authentication error that states it may be caused by a malfunctioning > identity source. > > Also I have modified my ldap schema as directed in the howto however (and > i'm pretty sure this is the root of my problem) I notice that when I do an > ldapsearch for a group which i've assigned administrator permissions it > does not have the 'uniqueMember' attribute. The ldapmodify command seemed > to run correctly without any complaints. Also i'm running freeipa 4.1. > > > [snip] > > > Does anyone have any suggestions? > > > Hello, I did write that howto based on my test configuration that was composed by: - vSphere 5.1 (no updates) - IPA packages 3.3.3-28.0.1.el7.centos.3 as provided in CentOS 7 at beginning of December 2014 What's your version of vSphere? I didn't test it but a couple of other guys notified me about problems with 5.5 Also, stupid question, I presume you had configured exactly as my test case where IPA domain was localdomain.local, based on your output, correct? Please provide output of the ldapsearch command requested by Martin too.. Thanks, Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From hugh at psychopig.com Wed Mar 4 13:33:17 2015 From: hugh at psychopig.com (Hugh) Date: Wed, 04 Mar 2015 07:33:17 -0600 Subject: [Freeipa-users] ntGroup MUST ntUserDomainId? In-Reply-To: <54F6BB90.8060500@redhat.com> References: <54F682B6.7000106@psychopig.com> <54F6BB90.8060500@redhat.com> Message-ID: <54F7099D.4030706@psychopig.com> On 3/4/2015 2:00 AM, Martin Kosek wrote: > On 03/04/2015 04:57 AM, Hugh wrote: > Hello Hugh, > > Before you dive in further in the FreeIPA winsync and groups, please note that > FreeIPA does not support group sync from/to AD and there are no plans for > adding that capability. We are focusing on AD Trusts instead, as *the* way for > cooperation with AD. This is related upstream ticket with similar request, just > different direction: > > https://fedorahosted.org/freeipa/ticket/3946 We would prefer to use trusts and I tried that first, but then I discovered that logging into Windows workstations joined to the AD domain with IPA user accounts is not supported due to lack of a Global Catalog. Therefore, I had to resort to using a synch instead. I'm assuming that implementing a Global Catalog will take a while, so I'd probably suggest/request that feature additions to synch agreements not be closed off. Hugh From rmj at ast.cam.ac.uk Wed Mar 4 15:29:34 2015 From: rmj at ast.cam.ac.uk (Roderick Johnstone) Date: Wed, 04 Mar 2015 15:29:34 +0000 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <1425312395.13900.7.camel@willson.usersys.redhat.com> References: <54F0B548.8050902@ast.cam.ac.uk> <1425062007.9346.6.camel@willson.usersys.redhat.com> <54F0BE7E.4000001@ast.cam.ac.uk> <1425067497.9346.8.camel@willson.usersys.redhat.com> <54F4579D.6030206@ast.cam.ac.uk> <1425312395.13900.7.camel@willson.usersys.redhat.com> Message-ID: <54F724DE.7050104@ast.cam.ac.uk> >> 4) I'm not sure about this one. Things seem to work at the moment. Is >> this again about managing the records more easily when we bring on line >> replica servers? > > It is only about ease of use indeed, if you manage your servers > manually, and keep them properly up to date, all should be fine. Simo Can you clarify really what freeipa is doing with the DNS please. Is it just about maintaining the SRV records for the server replicas, assuming we have our hosts already in an external (to freeipa) DNS? Does it change the priority in the SRV records as replicas come and go? Is there more to it than this? Thanks Roderick From simo at redhat.com Wed Mar 4 15:42:24 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 04 Mar 2015 10:42:24 -0500 Subject: [Freeipa-users] Host aliases in freeipa In-Reply-To: <54F724DE.7050104@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> <1425067497.9346.8.camel@willson.usersys.redhat.com> <54F4579D.6030206@ast.cam.ac.uk> <1425312395.13900.7.camel@willson.usersys.redhat.com> <54F724DE.7050104@ast.cam.ac.uk> Message-ID: <1425483744.13900.43.camel@willson.usersys.redhat.com> On Wed, 2015-03-04 at 15:29 +0000, Roderick Johnstone wrote: > >> 4) I'm not sure about this one. Things seem to work at the moment. Is > >> this again about managing the records more easily when we bring on line > >> replica servers? > > > > It is only about ease of use indeed, if you manage your servers > > manually, and keep them properly up to date, all should be fine. > > Simo > > Can you clarify really what freeipa is doing with the DNS please. Automatically add/remove replicas are added/removed in SRV records. Allows secure updates from clients. Allows fine grained delegation of DNS management. > Is it just about maintaining the SRV records for the server replicas, > assuming we have our hosts already in an external (to freeipa) DNS? Not only but this is one of the important things. > Does it change the priority in the SRV records as replicas come and go? Not yet. > Is there more to it than this? See above. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From mkosek at redhat.com Wed Mar 4 17:24:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 04 Mar 2015 18:24:42 +0100 Subject: [Freeipa-users] ntGroup MUST ntUserDomainId? In-Reply-To: <54F7099D.4030706@psychopig.com> References: <54F682B6.7000106@psychopig.com> <54F6BB90.8060500@redhat.com> <54F7099D.4030706@psychopig.com> Message-ID: <54F73FDA.6050303@redhat.com> On 03/04/2015 02:33 PM, Hugh wrote: > On 3/4/2015 2:00 AM, Martin Kosek wrote: >> On 03/04/2015 04:57 AM, Hugh wrote: >> Hello Hugh, >> >> Before you dive in further in the FreeIPA winsync and groups, please note that >> FreeIPA does not support group sync from/to AD and there are no plans for >> adding that capability. We are focusing on AD Trusts instead, as *the* way for >> cooperation with AD. This is related upstream ticket with similar request, just >> different direction: >> >> https://fedorahosted.org/freeipa/ticket/3946 > > We would prefer to use trusts and I tried that first, but then I > discovered that logging into Windows workstations joined to the AD > domain with IPA user accounts is not supported due to lack of a Global > Catalog. Therefore, I had to resort to using a synch instead. I see. > I'm assuming that implementing a Global Catalog will take a while, so > I'd probably suggest/request that feature additions to synch agreements > not be closed off. We are mostly not closing it off, if there is a contribution from the community for the said feature, we will not reject it just because it is winsync feature. But adding group support to winsync plugin is a non-trivial development effort and we would rather focus on the said Global Catalog support which is a better choice long run. I am now thinking how could your use case be worked around without significant development. I can only think of having parallel script polling the new/updated LDAP groups (based on modify time) and then uploading them to AD with adcli for example (http://www.freedesktop.org/software/realmd/adcli/adcli.html). But this is suboptimal, yes. Martin From sipazzo at yahoo.com Wed Mar 4 21:32:29 2015 From: sipazzo at yahoo.com (sipazzo) Date: Wed, 4 Mar 2015 21:32:29 +0000 (UTC) Subject: [Freeipa-users] Need to replace cert for ipa servers Message-ID: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> Good afternoon, we have a freeipa 3.0.42 installation running on redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was originally configured with the built in dogtag certificate CA and then one of my co-workers added our GoDaddy certificate to the certificate bundle. My understanding is this cert is used for communication between the ipa servers as well as the clients are also configured to trust the GoDaddy certificate. We recently had to get a new GoDaddy cert so our old one is revoked. I need to figure out how to either replace the existing revoked cert with the new one or add the new one to the bundle and then remove the revoked certificate so as not to break anything. Any help is appreciated. I am not strong with certificates so the more detail you can give the better.Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Mar 4 22:56:32 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Mar 2015 17:56:32 -0500 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> References: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> Message-ID: <54F78DA0.4040801@redhat.com> On 03/04/2015 04:32 PM, sipazzo wrote: > Good afternoon, we have a freeipa 3.0.42 installation running on > redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was > originally configured with the built in dogtag certificate CA and then > one of my co-workers added our GoDaddy certificate to the certificate > bundle. My understanding is this cert is used for communication > between the ipa servers as well as the clients are also configured to > trust the GoDaddy certificate. We recently had to get a new GoDaddy > cert so our old one is revoked. I need to figure out how to either > replace the existing revoked cert with the new one or add the new one > to the bundle and then remove the revoked certificate so as not to > break anything. > > Any help is appreciated. I am not strong with certificates so the more > detail you can give the better. > Thank you. > > You say it was running with the self signed IPA CA and than GoDaddy cert was added to the bundle. How was it added? IPA does not use certs for communication between the instances. It uses Kerberos. I am not sure the DoDaddy cert you added is even used in some way by IPA. It seems that your GoDaddy cert is an orthogonal trust so if you replaced the main key pair then you just need to distribute your new GoDaddy cert to the clients as you did on the first place. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Thu Mar 5 00:24:34 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Wed, 4 Mar 2015 16:24:34 -0800 Subject: [Freeipa-users] AD trust users cannot login to Solaris Message-ID: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> I have successfully setup a Solaris 10 client so that internal FreeIPA users can login, get the correct shell, and can sudo to root using ldap. The problem is that the AD trusted users cannot login. I have read all the freeIPA docs about enabling legacy clients, and they say to use the compat tree. I'm pretty sure I'm already doing this. Here is the contents of the ldap_client_file from my Solaris machine (which was downloaded automatically when I did ldapclient init): # # Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead. # NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= ipadc1.mydomain.net NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=net NS_LDAP_AUTH= none NS_LDAP_SEARCH_REF= TRUE NS_LDAP_SEARCH_TIME= 15 NS_LDAP_PROFILE= default NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=mydomain,dc=net NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,dc=mydomain,dc=net NS_LDAP_BIND_TIME= 5 NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount I see that the users are coming from the accounts tree and the groups are coming from the compat tree. Is this right? The trust was created with --enable-compat so I'm surprised that only the groups are coming from the compat tree. Does FreeIPA serve up an improperly configured DefaultDUAProfile? I couldn't login with this configuration, so I switched the passwd line to cn=compat just to test, but that didn't seem to work. Here is the result of getent passwd on solaris (last 2 lines): admin:x:375200000:375200000:Administrator:/home/admin:/bin/bash ipauser1:x:375200006:375200006:ipa user1:/home/ipauser1:/bin/bash So once again, we can see FreeIPA users, but not AD users. I don't think this is a Solaris problem because when I go onto my windows desktop and load ldp.exe and view the ldap tree, I can view cn=compat,dc=mydomain,dc=net However, the compat tree has a users section that only includes my FreeIPA internal users. So my questions are : 1.)What is the point of a compat tree in FreeIPA if it doesn't list AD users? 2.)How do I get my compat tree to list my AD users? 3.)If there is something manual I have to do to make my compat tree show AD users, why is this not done when enable the trust with --enable-compat. >From what I can see, my compat tree basically contains the exact same users and groups as my regular tree, so it will never allow a client using ldap only auth to see the AD users? From dpal at redhat.com Thu Mar 5 00:36:05 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Mar 2015 19:36:05 -0500 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> Message-ID: <54F7A4F5.2090707@redhat.com> On 03/04/2015 07:24 PM, nathan at nathanpeters.com wrote: > I have successfully setup a Solaris 10 client so that internal FreeIPA > users can login, get the correct shell, and can sudo to root using ldap. > > The problem is that the AD trusted users cannot login. I have read all > the freeIPA docs about enabling legacy clients, and they say to use the > compat tree. I'm pretty sure I'm already doing this. Here is the > contents of the ldap_client_file from my Solaris machine (which was > downloaded automatically when I did ldapclient init): > > # > # Do not edit this file manually; your changes will be lost.Please use > ldapclient (1M) instead. > # > NS_LDAP_FILE_VERSION= 2.0 > NS_LDAP_SERVERS= ipadc1.mydomain.net > NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=net > NS_LDAP_AUTH= none > NS_LDAP_SEARCH_REF= TRUE > NS_LDAP_SEARCH_TIME= 15 > NS_LDAP_PROFILE= default > NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=mydomain,dc=net > NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,dc=mydomain,dc=net > NS_LDAP_BIND_TIME= 5 > NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount > > I see that the users are coming from the accounts tree and the groups are > coming from the compat tree. Is this right? The trust was created with > --enable-compat so I'm surprised that only the groups are coming from the > compat tree. > > Does FreeIPA serve up an improperly configured DefaultDUAProfile? > > I couldn't login with this configuration, so I switched the passwd line to > cn=compat just to test, but that didn't seem to work. > > Here is the result of getent passwd on solaris (last 2 lines): > admin:x:375200000:375200000:Administrator:/home/admin:/bin/bash > ipauser1:x:375200006:375200006:ipa user1:/home/ipauser1:/bin/bash > > So once again, we can see FreeIPA users, but not AD users. > > I don't think this is a Solaris problem because when I go onto my windows > desktop and load ldp.exe and view the ldap tree, I can view > cn=compat,dc=mydomain,dc=net > > However, the compat tree has a users section that only includes my FreeIPA > internal users. So my questions are : > 1.)What is the point of a compat tree in FreeIPA if it doesn't list AD users? > 2.)How do I get my compat tree to list my AD users? > 3.)If there is something manual I have to do to make my compat tree show > AD users, why is this not done when enable the trust with --enable-compat. > > >From what I can see, my compat tree basically contains the exact same > users and groups as my regular tree, so it will never allow a client using > ldap only auth to see the AD users? > > What version of IPA are you using? Have you verified that trust actually works by looking up or authenticating with the AD users on the SSSD client or on the server itself? The compat tree fills the data dynamically as you need it. When an AD user accesses Solaris box Solaris would authenticate against the compat tree. Compat tree will use SSSD on the server to authenticate against the AD. It seems that this part is failing. SSSD logs from the IPA server with high debug level would be helpful. More info is here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From reesb at hushmail.com Thu Mar 5 01:13:22 2015 From: reesb at hushmail.com (reesb at hushmail.com) Date: Thu, 05 Mar 2015 09:13:22 +0800 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <54F6FB5D.1050606@redhat.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> Message-ID: <20150305011322.B02F2C043C@smtp.hushmail.com> Hi Martin, Using my vadmin account, "uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local", the search completes successfully and i get a list of my users and groups however when I've watched the ldap queries between vcenter and freeipa I can see it's applying a filter to the user search looking for 'objectClass=groupOfUniqueNames' which my groups don't seem to contain. I'm very much an ldap newbie but I thought at step two in the vsphere integration howto I modified the groups schema to include that object class? On 3/4/2015 at 8:32 PM, "Martin Kosek" wrote: Given that this HOWTO does not use the vanilla Schema Compatibility settings (FreeIPA Compat Tree by default uses posixGroup objectclass and memberUid attribute for user membership), I would check if the groups really have the right objectclass and uniqueMember generated: # ldapsearch -D "VSPHERE_DN" -x -w "$VSPHERE_DN_PASSWORD" -b "cn=groups,cn=compat,dc=localdomain,dc=local" I expect there will be some problem preventing the LDAP search to succeed. Then we would know where to look next. Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From reesb at hushmail.com Thu Mar 5 01:37:11 2015 From: reesb at hushmail.com (reesb at hushmail.com) Date: Thu, 05 Mar 2015 09:37:11 +0800 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <20150305011322.B02F2C043C@smtp.hushmail.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> Message-ID: <20150305013712.23AB3C043C@smtp.hushmail.com> Opps, I got that wrong, my groups don't show the 'uniqueMember' attribute. Here is an example returned from ldapsearch; # admins, groups, compat, localdomain.local dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local gidNumber: 756200000 memberUid: admin memberUid: vadmin objectClass: posixGroup objectClass: groupOfUniqueNames objectClass: top cn: admins On 3/5/2015 at 9:15 AM, reesb at hushmail.com wrote: Hi Martin, Using my vadmin account, "uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local", the search completes successfully and i get a list of my users and groups however when I've watched the ldap queries between vcenter and freeipa I can see it's applying a filter to the user search looking for 'objectClass=groupOfUniqueNames' which my groups don't seem to contain. I'm very much an ldap newbie but I thought at step two in the vsphere integration howto I modified the groups schema to include that object class? On 3/4/2015 at 8:32 PM, "Martin Kosek" wrote: Given that this HOWTO does not use the vanilla Schema Compatibility settings (FreeIPA Compat Tree by default uses posixGroup objectclass and memberUid attribute for user membership), I would check if the groups really have the right objectclass and uniqueMember generated: # ldapsearch -D "VSPHERE_DN" -x -w "$VSPHERE_DN_PASSWORD" -b "cn=groups,cn=compat,dc=localdomain,dc=local" I expect there will be some problem preventing the LDAP search to succeed. Then we would know where to look next. Martin From nathan at nathanpeters.com Thu Mar 5 01:55:16 2015 From: nathan at nathanpeters.com (Nathan Peters) Date: Wed, 4 Mar 2015 17:55:16 -0800 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <54F7A4F5.2090707@redhat.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <54F7A4F5.2090707@redhat.com> Message-ID: <76041DEDC50B4BD69B65E670E695B53C@Azul> I am using FreeIPA 4.1.2 on CentOS 7. Yes, AD users can login to all Linux / Centos machines. Also, when I'm at a shell prompt on the FreeIPA DC, I can getent passwd and I see their info properly. The guide you linked below is the first thing I read while trying to troubleshoot this. It seems aimed toward older sssd clients < 1.9 and not Solaris clients. I will try this again tomorrow and confirm that the request is being passed to the FreeIPA DC and rejected there. I was assuming that it was being rejected by the Solaris machine. -----Original Message----- From: Dmitri Pal Sent: Wednesday, March 04, 2015 4:36 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] AD trust users cannot login to Solaris On 03/04/2015 07:24 PM, nathan at nathanpeters.com wrote: > I have successfully setup a Solaris 10 client so that internal FreeIPA > users can login, get the correct shell, and can sudo to root using ldap. > > The problem is that the AD trusted users cannot login. I have read all > the freeIPA docs about enabling legacy clients, and they say to use the > compat tree. I'm pretty sure I'm already doing this. Here is the > contents of the ldap_client_file from my Solaris machine (which was > downloaded automatically when I did ldapclient init): > > # > # Do not edit this file manually; your changes will be lost.Please use > ldapclient (1M) instead. > # > NS_LDAP_FILE_VERSION= 2.0 > NS_LDAP_SERVERS= ipadc1.mydomain.net > NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=net > NS_LDAP_AUTH= none > NS_LDAP_SEARCH_REF= TRUE > NS_LDAP_SEARCH_TIME= 15 > NS_LDAP_PROFILE= default > NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=mydomain,dc=net > NS_LDAP_SERVICE_SEARCH_DESC= > passwd:cn=users,cn=accounts,dc=mydomain,dc=net > NS_LDAP_BIND_TIME= 5 > NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount > > I see that the users are coming from the accounts tree and the groups are > coming from the compat tree. Is this right? The trust was created with > --enable-compat so I'm surprised that only the groups are coming from the > compat tree. > > Does FreeIPA serve up an improperly configured DefaultDUAProfile? > > I couldn't login with this configuration, so I switched the passwd line to > cn=compat just to test, but that didn't seem to work. > > Here is the result of getent passwd on solaris (last 2 lines): > admin:x:375200000:375200000:Administrator:/home/admin:/bin/bash > ipauser1:x:375200006:375200006:ipa user1:/home/ipauser1:/bin/bash > > So once again, we can see FreeIPA users, but not AD users. > > I don't think this is a Solaris problem because when I go onto my windows > desktop and load ldp.exe and view the ldap tree, I can view > cn=compat,dc=mydomain,dc=net > > However, the compat tree has a users section that only includes my FreeIPA > internal users. So my questions are : > 1.)What is the point of a compat tree in FreeIPA if it doesn't list AD > users? > 2.)How do I get my compat tree to list my AD users? > 3.)If there is something manual I have to do to make my compat tree show > AD users, why is this not done when enable the trust with --enable-compat. > > >From what I can see, my compat tree basically contains the exact same > users and groups as my regular tree, so it will never allow a client using > ldap only auth to see the AD users? > > What version of IPA are you using? Have you verified that trust actually works by looking up or authenticating with the AD users on the SSSD client or on the server itself? The compat tree fills the data dynamically as you need it. When an AD user accesses Solaris box Solaris would authenticate against the compat tree. Compat tree will use SSSD on the server to authenticate against the AD. It seems that this part is failing. SSSD logs from the IPA server with high debug level would be helpful. More info is here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf -- 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 Mar 5 03:34:20 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 04 Mar 2015 22:34:20 -0500 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <76041DEDC50B4BD69B65E670E695B53C@Azul> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <54F7A4F5.2090707@redhat.com> <76041DEDC50B4BD69B65E670E695B53C@Azul> Message-ID: <54F7CEBC.9030304@redhat.com> On 03/04/2015 08:55 PM, Nathan Peters wrote: > I am using FreeIPA 4.1.2 on CentOS 7. > > Yes, AD users can login to all Linux / Centos machines. > > Also, when I'm at a shell prompt on the FreeIPA DC, I can getent > passwd and I see their info properly. > > The guide you linked below is the first thing I read while trying to > troubleshoot this. It seems aimed toward older sssd clients < 1.9 and > not Solaris clients. > > I will try this again tomorrow and confirm that the request is being > passed to the FreeIPA DC and rejected there. I was assuming that it > was being rejected by the Solaris machine. Good that everything else works. That narrows things down. Let us see whether the auth request hits SSSD and what happens then. May be it is on Solaris. The password line should in fact point to the compat tree as you noticed. But authentication should work. May be it ts NS_LDAP_OBJECTCLASSMAP, the mention of shadow looks suspicious. Also NS_LDAP_AUTH= none ... may be it should be some other value. Also the configuration seems to be different from one described here: http://www.freeipa.org/docs/1.2/Client_Setup_Guide/en-US/html/chap-Client_Configuration_Guide-Configuring_Solaris_as_an_IPA_Client.html or here http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html Those are old guides but still should be relevant to Solaris configuration. Just use compat tree as recent docs prescribe. > > -----Original Message----- From: Dmitri Pal > Sent: Wednesday, March 04, 2015 4:36 PM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] AD trust users cannot login to Solaris > > On 03/04/2015 07:24 PM, nathan at nathanpeters.com wrote: >> I have successfully setup a Solaris 10 client so that internal FreeIPA >> users can login, get the correct shell, and can sudo to root using ldap. >> >> The problem is that the AD trusted users cannot login. I have read all >> the freeIPA docs about enabling legacy clients, and they say to use the >> compat tree. I'm pretty sure I'm already doing this. Here is the >> contents of the ldap_client_file from my Solaris machine (which was >> downloaded automatically when I did ldapclient init): >> >> # >> # Do not edit this file manually; your changes will be lost.Please use >> ldapclient (1M) instead. >> # >> NS_LDAP_FILE_VERSION= 2.0 >> NS_LDAP_SERVERS= ipadc1.mydomain.net >> NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=net >> NS_LDAP_AUTH= none >> NS_LDAP_SEARCH_REF= TRUE >> NS_LDAP_SEARCH_TIME= 15 >> NS_LDAP_PROFILE= default >> NS_LDAP_SERVICE_SEARCH_DESC= >> group:cn=groups,cn=compat,dc=mydomain,dc=net >> NS_LDAP_SERVICE_SEARCH_DESC= >> passwd:cn=users,cn=accounts,dc=mydomain,dc=net >> NS_LDAP_BIND_TIME= 5 >> NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount >> >> I see that the users are coming from the accounts tree and the groups >> are >> coming from the compat tree. Is this right? The trust was created with >> --enable-compat so I'm surprised that only the groups are coming from >> the >> compat tree. >> >> Does FreeIPA serve up an improperly configured DefaultDUAProfile? >> >> I couldn't login with this configuration, so I switched the passwd >> line to >> cn=compat just to test, but that didn't seem to work. >> >> Here is the result of getent passwd on solaris (last 2 lines): >> admin:x:375200000:375200000:Administrator:/home/admin:/bin/bash >> ipauser1:x:375200006:375200006:ipa user1:/home/ipauser1:/bin/bash >> >> So once again, we can see FreeIPA users, but not AD users. >> >> I don't think this is a Solaris problem because when I go onto my >> windows >> desktop and load ldp.exe and view the ldap tree, I can view >> cn=compat,dc=mydomain,dc=net >> >> However, the compat tree has a users section that only includes my >> FreeIPA >> internal users. So my questions are : >> 1.)What is the point of a compat tree in FreeIPA if it doesn't list >> AD users? >> 2.)How do I get my compat tree to list my AD users? >> 3.)If there is something manual I have to do to make my compat tree show >> AD users, why is this not done when enable the trust with >> --enable-compat. >> >> >From what I can see, my compat tree basically contains the exact same >> users and groups as my regular tree, so it will never allow a client >> using >> ldap only auth to see the AD users? >> >> > What version of IPA are you using? > Have you verified that trust actually works by looking up or > authenticating with the AD users on the SSSD client or on the server > itself? > > The compat tree fills the data dynamically as you need it. When an AD > user accesses Solaris box Solaris would authenticate against the compat > tree. Compat tree will use SSSD on the server to authenticate against > the AD. It seems that this part is failing. SSSD logs from the IPA > server with high debug level would be helpful. > > More info is here: > http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From bentech4you at gmail.com Thu Mar 5 05:40:21 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Thu, 5 Mar 2015 08:40:21 +0300 Subject: [Freeipa-users] Trust is successful and getting error while creating groups. Message-ID: Hi i have re-installed everything . my current versions are Centos 7 with IPA 4.1 i followed this tutorial: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup when i fetch , it went successful: *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com "* * Domain name: infra.com * * Domain NetBIOS name: INFRA* * Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* * Domain enabled: True* *----------------------------* *Number of entries returned 1* *----------------------------* *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com "* * Domain name: infra.com * * Domain NetBIOS name: INFRA* * Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* * Domain enabled: True* *----------------------------* *Number of entries returned 1* *----------------------------* when i gone through "Allow access for users from AD domain to protected resources", i am getting errors, *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com users external map' ad_users_external --external* *-------------------------------* *Added group "ad_users_external"* *-------------------------------* * Group name: ad_users_external* * Description: infra.com users external map* *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com users' ad_users* *----------------------* *Added group "ad_users"* *----------------------* * Group name: ad_users* * Description: infra.com users* * GID: 643400005* *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users_external --external 'INFRA\Domain Users'* *[member user]:* *[member group]:* * Group name: ad_users_external* * Description: infra.com users external map* * Failed members:* * member user:* * member group: INFRA\Domain Users: trusted domain object not found* *-------------------------* *Number of members added 0* *-------------------------* *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users --groups ad_users_external* * Group name: ad_users* * Description: infra.com users* * GID: 643400005* * Member groups: ad_users_external* *-------------------------* *Number of members added 1* *-------------------------* please help me to solve this issue: below error is getting on httpd/error_log while trying : *ipa group-add-member ad_users_external --external 'INFRA\Domain Users'* *[Thu Mar 05 11:36:37.371594 2015] [:error] [pid 4090] ipa: WARNING: Search on AD DC kwtipaad001.infra.com:3268 failed with: Insufficient access: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket not yet valid)* *[Thu Mar 05 11:36:37.374280 2015] [:error] [pid 4090] ipa: INFO: [jsonserver_kerb] admin at SOLARIS.LOCAL: group_add_member(u'ad_users_external', ipaexternalmember=(u'INFRA\\\\Domain Users',), all=False, raw=False, version=u'2.113', no_members=False): SUCCESS* Thanks & Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Mar 5 05:52:38 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Mar 2015 07:52:38 +0200 Subject: [Freeipa-users] Trust is successful and getting error while creating groups. In-Reply-To: References: Message-ID: <20150305055238.GH25455@redhat.com> On Thu, 05 Mar 2015, Ben .T.George wrote: >Hi > >i have re-installed everything . my current versions are Centos 7 with IPA >4.1 > >i followed this tutorial: >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup > >when i fetch , it went successful: > >*[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com "* >* Domain name: infra.com * >* Domain NetBIOS name: INFRA* >* Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* >* Domain enabled: True* >*----------------------------* >*Number of entries returned 1* >*----------------------------* >*[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com "* >* Domain name: infra.com * >* Domain NetBIOS name: INFRA* >* Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* >* Domain enabled: True* >*----------------------------* >*Number of entries returned 1* >*----------------------------* > >when i gone through "Allow access for users from AD domain to protected >resources", i am getting errors, > > >*[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com >users external map' ad_users_external --external* >*-------------------------------* >*Added group "ad_users_external"* >*-------------------------------* >* Group name: ad_users_external* >* Description: infra.com users external map* > >*[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com >users' ad_users* >*----------------------* >*Added group "ad_users"* >*----------------------* >* Group name: ad_users* >* Description: infra.com users* >* GID: 643400005* > >*[root at kwtpocpbis01 ~]# ipa group-add-member ad_users_external --external >'INFRA\Domain Users'* >*[member user]:* >*[member group]:* >* Group name: ad_users_external* >* Description: infra.com users external map* >* Failed members:* >* member user:* >* member group: INFRA\Domain Users: trusted domain object not found* >*-------------------------* >*Number of members added 0* >*-------------------------* > >*[root at kwtpocpbis01 ~]# ipa group-add-member ad_users --groups >ad_users_external* >* Group name: ad_users* >* Description: infra.com users* >* GID: 643400005* >* Member groups: ad_users_external* >*-------------------------* >*Number of members added 1* >*-------------------------* > >please help me to solve this issue: > >below error is getting on httpd/error_log while trying : *ipa >group-add-member ad_users_external --external 'INFRA\Domain Users'* > >*[Thu Mar 05 11:36:37.371594 2015] [:error] [pid 4090] ipa: WARNING: Search >on AD DC kwtipaad001.infra.com:3268 >failed with: Insufficient access: SASL(-1): generic failure: GSSAPI Error: >Unspecified GSS failure. Minor code may provide more information (Ticket >not yet valid)* >*[Thu Mar 05 11:36:37.374280 2015] [:error] [pid 4090] ipa: INFO: >[jsonserver_kerb] admin at SOLARIS.LOCAL: >group_add_member(u'ad_users_external', ipaexternalmember=(u'INFRA\\\\Domain >Users',), all=False, raw=False, version=u'2.113', no_members=False): >SUCCESS* OK, "Ticket not yet valid" is time synchronization issue -- AD DC has time behind IPA DC. Check time and time zone settings. -- / Alexander Bokovoy From abokovoy at redhat.com Thu Mar 5 06:26:44 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Mar 2015 08:26:44 +0200 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> Message-ID: <20150305062644.GI25455@redhat.com> On Wed, 04 Mar 2015, nathan at nathanpeters.com wrote: >I have successfully setup a Solaris 10 client so that internal FreeIPA >users can login, get the correct shell, and can sudo to root using ldap. > >The problem is that the AD trusted users cannot login. I have read all >the freeIPA docs about enabling legacy clients, and they say to use the >compat tree. I'm pretty sure I'm already doing this. Here is the >contents of the ldap_client_file from my Solaris machine (which was >downloaded automatically when I did ldapclient init): > ># ># Do not edit this file manually; your changes will be lost.Please use >ldapclient (1M) instead. ># >NS_LDAP_FILE_VERSION= 2.0 >NS_LDAP_SERVERS= ipadc1.mydomain.net >NS_LDAP_SEARCH_BASEDN= dc=mydomain,dc=net >NS_LDAP_AUTH= none You need to use authenticated bind and password proxying. There are two actions here: 1. Add system account in IPA To create a system account for NS_LDAP_BINDDN, use # cat <45-my-solaris-binddn.update dn: uid=solaris,cn=sysaccounts,cn=etc,\$SUFFIX add:objectclass:account,simplesecurityobject add:uid:solaris add:userPassword:"ohaimakethissimethingtoughtobreak" add:passwordExpirationTime:20380119031407Z add:nsIdleTimeout:0 END # ipa-ldap-updater -l ./45-my-solaris-binddn.update Frsing update file './45-my-solaris-binddn.update' New entry: uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test The ipa-ldap-updater command was successful 2. Setup Solaris properly NS_LDAP_AUTH=tls:simple NS_LDAP_CREDENTIAL_LEVEL=proxy NS_LDAP_BINDDN=uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test NS_LDAP_BINDPASSWD=ohaimakethissimethingtoughtobreak NS_LDAP_CACHETTL=0 NS_LDAP_HOST_CERTPATH=/var/ldap and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) into /var/ldap's database with certutil: # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap Obviously, you'll have your own $SUFFIX value in NS_LDAP_* entries. And point LDAP_SERVICE_SEARCH_DESC for passwd to the compat tree. >NS_LDAP_SEARCH_REF= TRUE >NS_LDAP_SEARCH_TIME= 15 >NS_LDAP_PROFILE= default >NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=mydomain,dc=net >NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=accounts,dc=mydomain,dc=net >NS_LDAP_BIND_TIME= 5 >NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount > >I see that the users are coming from the accounts tree and the groups are >coming from the compat tree. Is this right? The trust was created with >--enable-compat so I'm surprised that only the groups are coming from the >compat tree. > >Does FreeIPA serve up an improperly configured DefaultDUAProfile No, it serves a profile which is fine for non-AD case because all we need to override is group management -- Solaris expects RFC2307, not RFC2307bis. But for AD users you need to point passwd to compat tree cn=users,cn=compat,.. as well -- we simulate LDAP objects there for AD users on request. Additionally, a default DUA profile assumes you are using Kerberos authentication and thus don't need LDAP bind proxying to verify passwords. It is not true in the case of AD users as they couldn't be seen differently by Solaris. As result, you have to do LDAP bind against compat tree. When the Schema Compatibility Plugin is configured to expose users from trusted domains, their authentication is handled via PAM 'system-auth' service. This service exists by default on Linux systems and is provided by pam package as /etc/pam.d/system-auth. If your FreeIPA install does not have default HBAC rule 'allow_all' enabled, then make sure to define in IPA a special service called 'system-auth' and create an HBAC rule to allow access to anyone to this rule on IPA masters. As 'system-auth' PAM service is not used directly by any other application, it is safe to use it for trusted domain users via compatibility path. -- / Alexander Bokovoy From bentech4you at gmail.com Thu Mar 5 06:35:38 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Thu, 5 Mar 2015 09:35:38 +0300 Subject: [Freeipa-users] Trust is successful and getting error while creating groups. In-Reply-To: <20150305055238.GH25455@redhat.com> References: <20150305055238.GH25455@redhat.com> Message-ID: HI sorry ntp was stopped. now time is in sync. rebooted machine buy process is not going through *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external --external 'ad_netbios\Domain Admins'* *[member user]:* *[member group]:* * Group name: ad_admins_external* * Description: infra.com admins external map* * Failed members:* * member user:* * member group: ad_netbios\Domain Admins: invalid 'trusted domain object': no trusted domain matched the specified flat name* *-------------------------* *Number of members added 0* *-------------------------* *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external --external 'ad_netbios\Domain Users'* *[member user]:* *[member group]:* * Group name: ad_admins_external* * Description: infra.com admins external map* * Failed members:* * member user:* * member group: ad_netbios\Domain Users: invalid 'trusted domain object': no trusted domain matched the specified flat name* *-------------------------* *Number of members added 0* *-------------------------* And the error message on error_log is : [Thu Mar 05 09:31:50.146154 2015] [:error] [pid 2101] ipa: INFO: [jsonserver_kerb] admin at SOLARIS.LOCAL: group_add_member(u'ad_admins_external', ipaexternalmember=(u'ad_netbios\\\\Domain Admins',), all=False, raw=False, version=u'2.113', no_members=False): SUCCESS [Thu Mar 05 09:32:15.761885 2015] [:error] [pid 2101] ipa: INFO: [jsonserver_kerb] admin at SOLARIS.LOCAL: group_add_member(u'ad_admins_external', ipaexternalmember=(u'ad_netbios\\\\Domain Users',), all=False, raw=False, version=u'2.113', no_members=False): SUCCESS On Thu, Mar 5, 2015 at 8:52 AM, Alexander Bokovoy wrote: > On Thu, 05 Mar 2015, Ben .T.George wrote: > >> Hi >> >> i have re-installed everything . my current versions are Centos 7 with IPA >> 4.1 >> >> i followed this tutorial: >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >> >> when i fetch , it went successful: >> >> *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com > >"* >> * Domain name: infra.com * >> * Domain NetBIOS name: INFRA* >> * Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* >> * Domain enabled: True* >> *----------------------------* >> *Number of entries returned 1* >> *----------------------------* >> *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com > >"* >> * Domain name: infra.com * >> * Domain NetBIOS name: INFRA* >> * Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* >> * Domain enabled: True* >> *----------------------------* >> *Number of entries returned 1* >> *----------------------------* >> >> when i gone through "Allow access for users from AD domain to protected >> resources", i am getting errors, >> >> >> *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com > > >> users external map' ad_users_external --external* >> *-------------------------------* >> *Added group "ad_users_external"* >> *-------------------------------* >> * Group name: ad_users_external* >> * Description: infra.com users external map* >> >> *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com > > >> users' ad_users* >> *----------------------* >> *Added group "ad_users"* >> *----------------------* >> * Group name: ad_users* >> * Description: infra.com users* >> * GID: 643400005* >> >> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users_external --external >> 'INFRA\Domain Users'* >> *[member user]:* >> *[member group]:* >> * Group name: ad_users_external* >> * Description: infra.com users external map* >> * Failed members:* >> * member user:* >> * member group: INFRA\Domain Users: trusted domain object not found* >> *-------------------------* >> *Number of members added 0* >> *-------------------------* >> >> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users --groups >> ad_users_external* >> * Group name: ad_users* >> * Description: infra.com users* >> * GID: 643400005* >> * Member groups: ad_users_external* >> *-------------------------* >> *Number of members added 1* >> *-------------------------* >> >> please help me to solve this issue: >> >> below error is getting on httpd/error_log while trying : *ipa >> group-add-member ad_users_external --external 'INFRA\Domain Users'* >> >> *[Thu Mar 05 11:36:37.371594 2015] [:error] [pid 4090] ipa: WARNING: >> Search >> on AD DC kwtipaad001.infra.com:3268 >> failed with: Insufficient access: SASL(-1): generic failure: GSSAPI Error: >> Unspecified GSS failure. Minor code may provide more information (Ticket >> not yet valid)* >> *[Thu Mar 05 11:36:37.374280 2015] [:error] [pid 4090] ipa: INFO: >> [jsonserver_kerb] admin at SOLARIS.LOCAL: >> group_add_member(u'ad_users_external', ipaexternalmember=(u'INFRA\\\\ >> Domain >> Users',), all=False, raw=False, version=u'2.113', no_members=False): >> SUCCESS* >> > OK, "Ticket not yet valid" is time synchronization issue -- AD DC has > time behind IPA DC. Check time and time zone settings. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Thu Mar 5 07:00:31 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Thu, 5 Mar 2015 10:00:31 +0300 Subject: [Freeipa-users] Trust is successful and getting error while creating groups. In-Reply-To: References: <20150305055238.GH25455@redhat.com> Message-ID: Hi Alexander, can you please give me clue what will be error message "member group: KWTTESTDC\Domain Admins: invalid 'trusted domain object': no trusted domain matched the specified flat name" Regards, Ben On Thu, Mar 5, 2015 at 9:35 AM, Ben .T.George wrote: > HI > > sorry ntp was stopped. now time is in sync. rebooted machine > > buy process is not going through > > *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external --external > 'ad_netbios\Domain Admins'* > *[member user]:* > *[member group]:* > * Group name: ad_admins_external* > * Description: infra.com admins external map* > * Failed members:* > * member user:* > * member group: ad_netbios\Domain Admins: invalid 'trusted domain > object': no trusted domain matched the specified flat name* > *-------------------------* > *Number of members added 0* > > *-------------------------* > *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external --external > 'ad_netbios\Domain Users'* > *[member user]:* > *[member group]:* > * Group name: ad_admins_external* > * Description: infra.com admins external map* > * Failed members:* > * member user:* > * member group: ad_netbios\Domain Users: invalid 'trusted domain > object': no trusted domain matched the specified flat name* > *-------------------------* > *Number of members added 0* > *-------------------------* > > And the error message on error_log is : > > [Thu Mar 05 09:31:50.146154 2015] [:error] [pid 2101] ipa: INFO: > [jsonserver_kerb] admin at SOLARIS.LOCAL: > group_add_member(u'ad_admins_external', > ipaexternalmember=(u'ad_netbios\\\\Domain Admins',), all=False, raw=False, > version=u'2.113', no_members=False): SUCCESS > > [Thu Mar 05 09:32:15.761885 2015] [:error] [pid 2101] ipa: INFO: > [jsonserver_kerb] admin at SOLARIS.LOCAL: > group_add_member(u'ad_admins_external', > ipaexternalmember=(u'ad_netbios\\\\Domain Users',), all=False, raw=False, > version=u'2.113', no_members=False): SUCCESS > > > > On Thu, Mar 5, 2015 at 8:52 AM, Alexander Bokovoy > wrote: > >> On Thu, 05 Mar 2015, Ben .T.George wrote: >> >>> Hi >>> >>> i have re-installed everything . my current versions are Centos 7 with >>> IPA >>> 4.1 >>> >>> i followed this tutorial: >>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >>> >>> when i fetch , it went successful: >>> >>> *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com < >>> http://infra.com>"* >>> * Domain name: infra.com * >>> * Domain NetBIOS name: INFRA* >>> * Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* >>> * Domain enabled: True* >>> *----------------------------* >>> *Number of entries returned 1* >>> *----------------------------* >>> *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com < >>> http://infra.com>"* >>> * Domain name: infra.com * >>> * Domain NetBIOS name: INFRA* >>> * Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* >>> * Domain enabled: True* >>> *----------------------------* >>> *Number of entries returned 1* >>> *----------------------------* >>> >>> when i gone through "Allow access for users from AD domain to protected >>> resources", i am getting errors, >>> >>> >>> *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com < >>> http://infra.com> >>> users external map' ad_users_external --external* >>> *-------------------------------* >>> *Added group "ad_users_external"* >>> *-------------------------------* >>> * Group name: ad_users_external* >>> * Description: infra.com users external map* >>> >>> *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com < >>> http://infra.com> >>> users' ad_users* >>> *----------------------* >>> *Added group "ad_users"* >>> *----------------------* >>> * Group name: ad_users* >>> * Description: infra.com users* >>> * GID: 643400005* >>> >>> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users_external >>> --external >>> 'INFRA\Domain Users'* >>> *[member user]:* >>> *[member group]:* >>> * Group name: ad_users_external* >>> * Description: infra.com users external map* >>> * Failed members:* >>> * member user:* >>> * member group: INFRA\Domain Users: trusted domain object not found* >>> *-------------------------* >>> *Number of members added 0* >>> *-------------------------* >>> >>> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users --groups >>> ad_users_external* >>> * Group name: ad_users* >>> * Description: infra.com users* >>> * GID: 643400005* >>> * Member groups: ad_users_external* >>> *-------------------------* >>> *Number of members added 1* >>> *-------------------------* >>> >>> please help me to solve this issue: >>> >>> below error is getting on httpd/error_log while trying : *ipa >>> group-add-member ad_users_external --external 'INFRA\Domain Users'* >>> >>> *[Thu Mar 05 11:36:37.371594 2015] [:error] [pid 4090] ipa: WARNING: >>> Search >>> on AD DC kwtipaad001.infra.com:3268 >>> failed with: Insufficient access: SASL(-1): generic failure: GSSAPI >>> Error: >>> Unspecified GSS failure. Minor code may provide more information (Ticket >>> not yet valid)* >>> *[Thu Mar 05 11:36:37.374280 2015] [:error] [pid 4090] ipa: INFO: >>> [jsonserver_kerb] admin at SOLARIS.LOCAL: >>> group_add_member(u'ad_users_external', ipaexternalmember=(u'INFRA\\\\ >>> Domain >>> Users',), all=False, raw=False, version=u'2.113', no_members=False): >>> SUCCESS* >>> >> OK, "Ticket not yet valid" is time synchronization issue -- AD DC has >> time behind IPA DC. Check time and time zone settings. >> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Mar 5 07:05:08 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Mar 2015 09:05:08 +0200 Subject: [Freeipa-users] Trust is successful and getting error while creating groups. In-Reply-To: References: <20150305055238.GH25455@redhat.com> Message-ID: <20150305070508.GM25455@redhat.com> On Thu, 05 Mar 2015, Ben .T.George wrote: >Hi Alexander, > >can you please give me clue what will be error message > >"member group: KWTTESTDC\Domain Admins: invalid 'trusted domain object': no >trusted domain matched the specified flat name" So what are the domains your IPA reports as trusted? ipa trustdomain-find Because you are talking about KWTTESTDC -- is this a domain's NetBIOS name? It looks to me it is your AD DC's name, not the domain's. > >Regards, >Ben > >On Thu, Mar 5, 2015 at 9:35 AM, Ben .T.George wrote: > >> HI >> >> sorry ntp was stopped. now time is in sync. rebooted machine >> >> buy process is not going through >> >> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external --external >> 'ad_netbios\Domain Admins'* >> *[member user]:* >> *[member group]:* >> * Group name: ad_admins_external* >> * Description: infra.com admins external map* >> * Failed members:* >> * member user:* >> * member group: ad_netbios\Domain Admins: invalid 'trusted domain >> object': no trusted domain matched the specified flat name* >> *-------------------------* >> *Number of members added 0* >> >> *-------------------------* >> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external --external >> 'ad_netbios\Domain Users'* >> *[member user]:* >> *[member group]:* >> * Group name: ad_admins_external* >> * Description: infra.com admins external map* >> * Failed members:* >> * member user:* >> * member group: ad_netbios\Domain Users: invalid 'trusted domain >> object': no trusted domain matched the specified flat name* >> *-------------------------* >> *Number of members added 0* >> *-------------------------* >> >> And the error message on error_log is : >> >> [Thu Mar 05 09:31:50.146154 2015] [:error] [pid 2101] ipa: INFO: >> [jsonserver_kerb] admin at SOLARIS.LOCAL: >> group_add_member(u'ad_admins_external', >> ipaexternalmember=(u'ad_netbios\\\\Domain Admins',), all=False, raw=False, >> version=u'2.113', no_members=False): SUCCESS >> >> [Thu Mar 05 09:32:15.761885 2015] [:error] [pid 2101] ipa: INFO: >> [jsonserver_kerb] admin at SOLARIS.LOCAL: >> group_add_member(u'ad_admins_external', >> ipaexternalmember=(u'ad_netbios\\\\Domain Users',), all=False, raw=False, >> version=u'2.113', no_members=False): SUCCESS >> >> >> >> On Thu, Mar 5, 2015 at 8:52 AM, Alexander Bokovoy >> wrote: >> >>> On Thu, 05 Mar 2015, Ben .T.George wrote: >>> >>>> Hi >>>> >>>> i have re-installed everything . my current versions are Centos 7 with >>>> IPA >>>> 4.1 >>>> >>>> i followed this tutorial: >>>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >>>> >>>> when i fetch , it went successful: >>>> >>>> *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com < >>>> http://infra.com>"* >>>> * Domain name: infra.com * >>>> * Domain NetBIOS name: INFRA* >>>> * Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* >>>> * Domain enabled: True* >>>> *----------------------------* >>>> *Number of entries returned 1* >>>> *----------------------------* >>>> *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com < >>>> http://infra.com>"* >>>> * Domain name: infra.com * >>>> * Domain NetBIOS name: INFRA* >>>> * Domain Security Identifier: S-1-5-21-191287045-4012216658-3592112898* >>>> * Domain enabled: True* >>>> *----------------------------* >>>> *Number of entries returned 1* >>>> *----------------------------* >>>> >>>> when i gone through "Allow access for users from AD domain to protected >>>> resources", i am getting errors, >>>> >>>> >>>> *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com < >>>> http://infra.com> >>>> users external map' ad_users_external --external* >>>> *-------------------------------* >>>> *Added group "ad_users_external"* >>>> *-------------------------------* >>>> * Group name: ad_users_external* >>>> * Description: infra.com users external map* >>>> >>>> *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com < >>>> http://infra.com> >>>> users' ad_users* >>>> *----------------------* >>>> *Added group "ad_users"* >>>> *----------------------* >>>> * Group name: ad_users* >>>> * Description: infra.com users* >>>> * GID: 643400005* >>>> >>>> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users_external >>>> --external >>>> 'INFRA\Domain Users'* >>>> *[member user]:* >>>> *[member group]:* >>>> * Group name: ad_users_external* >>>> * Description: infra.com users external map* >>>> * Failed members:* >>>> * member user:* >>>> * member group: INFRA\Domain Users: trusted domain object not found* >>>> *-------------------------* >>>> *Number of members added 0* >>>> *-------------------------* >>>> >>>> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users --groups >>>> ad_users_external* >>>> * Group name: ad_users* >>>> * Description: infra.com users* >>>> * GID: 643400005* >>>> * Member groups: ad_users_external* >>>> *-------------------------* >>>> *Number of members added 1* >>>> *-------------------------* >>>> >>>> please help me to solve this issue: >>>> >>>> below error is getting on httpd/error_log while trying : *ipa >>>> group-add-member ad_users_external --external 'INFRA\Domain Users'* >>>> >>>> *[Thu Mar 05 11:36:37.371594 2015] [:error] [pid 4090] ipa: WARNING: >>>> Search >>>> on AD DC kwtipaad001.infra.com:3268 >>>> failed with: Insufficient access: SASL(-1): generic failure: GSSAPI >>>> Error: >>>> Unspecified GSS failure. Minor code may provide more information (Ticket >>>> not yet valid)* >>>> *[Thu Mar 05 11:36:37.374280 2015] [:error] [pid 4090] ipa: INFO: >>>> [jsonserver_kerb] admin at SOLARIS.LOCAL: >>>> group_add_member(u'ad_users_external', ipaexternalmember=(u'INFRA\\\\ >>>> Domain >>>> Users',), all=False, raw=False, version=u'2.113', no_members=False): >>>> SUCCESS* >>>> >>> OK, "Ticket not yet valid" is time synchronization issue -- AD DC has >>> time behind IPA DC. Check time and time zone settings. >>> >>> -- >>> / Alexander Bokovoy >>> >> >> -- / Alexander Bokovoy From bentech4you at gmail.com Thu Mar 5 07:19:47 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Thu, 5 Mar 2015 10:19:47 +0300 Subject: [Freeipa-users] Trust is successful and getting error while creating groups. In-Reply-To: <20150305070508.GM25455@redhat.com> References: <20150305055238.GH25455@redhat.com> <20150305070508.GM25455@redhat.com> Message-ID: HI Alex Oops sorry. actually i have 2 servers which hostname looks like same kwtpocpbis01 and kwtpocpbis02 i was trying on wrong server. now it's working on actual server: *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external --external 'INFRA\Domain Admins'* *[member user]:* *[member group]:* * Group name: ad_admins_external* * Description: infra.com admins external map* * External member: S-1-5-21-191287045-4012216658-3592112898-512* *-------------------------* *Number of members added 1* *-------------------------* *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external --external 'INFRA\Domain Users'* *[member user]:* *[member group]:* * Group name: ad_admins_external* * Description: infra.com admins external map* * External member: S-1-5-21-191287045-4012216658-3592112898-512, S-1-5-21-191287045-4012216658-3592112898-513* *-------------------------* *Number of members added 1* how can i fetch AD user on command line on IPA server to check the communication? Regards Ben On Thu, Mar 5, 2015 at 10:05 AM, Alexander Bokovoy wrote: > On Thu, 05 Mar 2015, Ben .T.George wrote: > >> Hi Alexander, >> >> can you please give me clue what will be error message >> >> "member group: KWTTESTDC\Domain Admins: invalid 'trusted domain object': >> no >> trusted domain matched the specified flat name" >> > So what are the domains your IPA reports as trusted? > > ipa trustdomain-find > > Because you are talking about KWTTESTDC -- is this a domain's NetBIOS > name? It looks to me it is your AD DC's name, not the domain's. > > >> Regards, >> Ben >> >> On Thu, Mar 5, 2015 at 9:35 AM, Ben .T.George >> wrote: >> >> HI >>> >>> sorry ntp was stopped. now time is in sync. rebooted machine >>> >>> buy process is not going through >>> >>> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external >>> --external >>> 'ad_netbios\Domain Admins'* >>> *[member user]:* >>> *[member group]:* >>> * Group name: ad_admins_external* >>> * Description: infra.com admins external map* >>> * Failed members:* >>> * member user:* >>> * member group: ad_netbios\Domain Admins: invalid 'trusted domain >>> object': no trusted domain matched the specified flat name* >>> *-------------------------* >>> *Number of members added 0* >>> >>> *-------------------------* >>> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_admins_external >>> --external >>> 'ad_netbios\Domain Users'* >>> *[member user]:* >>> *[member group]:* >>> * Group name: ad_admins_external* >>> * Description: infra.com admins external map* >>> * Failed members:* >>> * member user:* >>> * member group: ad_netbios\Domain Users: invalid 'trusted domain >>> object': no trusted domain matched the specified flat name* >>> >>> *-------------------------* >>> *Number of members added 0* >>> *-------------------------* >>> >>> And the error message on error_log is : >>> >>> [Thu Mar 05 09:31:50.146154 2015] [:error] [pid 2101] ipa: INFO: >>> [jsonserver_kerb] admin at SOLARIS.LOCAL: >>> group_add_member(u'ad_admins_external', >>> ipaexternalmember=(u'ad_netbios\\\\Domain Admins',), all=False, >>> raw=False, >>> version=u'2.113', no_members=False): SUCCESS >>> >>> [Thu Mar 05 09:32:15.761885 2015] [:error] [pid 2101] ipa: INFO: >>> [jsonserver_kerb] admin at SOLARIS.LOCAL: >>> group_add_member(u'ad_admins_external', >>> ipaexternalmember=(u'ad_netbios\\\\Domain Users',), all=False, >>> raw=False, >>> version=u'2.113', no_members=False): SUCCESS >>> >>> >>> >>> On Thu, Mar 5, 2015 at 8:52 AM, Alexander Bokovoy >>> wrote: >>> >>> On Thu, 05 Mar 2015, Ben .T.George wrote: >>>> >>>> Hi >>>>> >>>>> i have re-installed everything . my current versions are Centos 7 with >>>>> IPA >>>>> 4.1 >>>>> >>>>> i followed this tutorial: >>>>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup >>>>> >>>>> when i fetch , it went successful: >>>>> >>>>> *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com < >>>>> http://infra.com>"* >>>>> * Domain name: infra.com * >>>>> * Domain NetBIOS name: INFRA* >>>>> * Domain Security Identifier: S-1-5-21-191287045-4012216658- >>>>> 3592112898* >>>>> * Domain enabled: True* >>>>> *----------------------------* >>>>> *Number of entries returned 1* >>>>> *----------------------------* >>>>> *[root at kwtpocpbis01 ~]# ipa trustdomain-find "infra.com < >>>>> http://infra.com>"* >>>>> * Domain name: infra.com * >>>>> * Domain NetBIOS name: INFRA* >>>>> * Domain Security Identifier: S-1-5-21-191287045-4012216658- >>>>> 3592112898* >>>>> * Domain enabled: True* >>>>> *----------------------------* >>>>> *Number of entries returned 1* >>>>> *----------------------------* >>>>> >>>>> when i gone through "Allow access for users from AD domain to protected >>>>> resources", i am getting errors, >>>>> >>>>> >>>>> *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com < >>>>> http://infra.com> >>>>> users external map' ad_users_external --external* >>>>> *-------------------------------* >>>>> *Added group "ad_users_external"* >>>>> *-------------------------------* >>>>> * Group name: ad_users_external* >>>>> * Description: infra.com users external map* >>>>> >>>>> *[root at kwtpocpbis01 ~]# ipa group-add --desc='infra.com < >>>>> http://infra.com> >>>>> users' ad_users* >>>>> *----------------------* >>>>> *Added group "ad_users"* >>>>> *----------------------* >>>>> * Group name: ad_users* >>>>> * Description: infra.com users* >>>>> * GID: 643400005* >>>>> >>>>> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users_external >>>>> --external >>>>> 'INFRA\Domain Users'* >>>>> *[member user]:* >>>>> *[member group]:* >>>>> * Group name: ad_users_external* >>>>> * Description: infra.com users external map* >>>>> * Failed members:* >>>>> * member user:* >>>>> * member group: INFRA\Domain Users: trusted domain object not found* >>>>> *-------------------------* >>>>> *Number of members added 0* >>>>> *-------------------------* >>>>> >>>>> *[root at kwtpocpbis01 ~]# ipa group-add-member ad_users --groups >>>>> ad_users_external* >>>>> * Group name: ad_users* >>>>> * Description: infra.com users* >>>>> * GID: 643400005* >>>>> * Member groups: ad_users_external* >>>>> *-------------------------* >>>>> *Number of members added 1* >>>>> *-------------------------* >>>>> >>>>> please help me to solve this issue: >>>>> >>>>> below error is getting on httpd/error_log while trying : *ipa >>>>> group-add-member ad_users_external --external 'INFRA\Domain Users'* >>>>> >>>>> *[Thu Mar 05 11:36:37.371594 2015] [:error] [pid 4090] ipa: WARNING: >>>>> Search >>>>> on AD DC kwtipaad001.infra.com:3268 >>>> > >>>>> failed with: Insufficient access: SASL(-1): generic failure: GSSAPI >>>>> Error: >>>>> Unspecified GSS failure. Minor code may provide more information >>>>> (Ticket >>>>> not yet valid)* >>>>> *[Thu Mar 05 11:36:37.374280 2015] [:error] [pid 4090] ipa: INFO: >>>>> [jsonserver_kerb] admin at SOLARIS.LOCAL: >>>>> group_add_member(u'ad_users_external', ipaexternalmember=(u'INFRA\\\\ >>>>> Domain >>>>> Users',), all=False, raw=False, version=u'2.113', no_members=False): >>>>> SUCCESS* >>>>> >>>>> OK, "Ticket not yet valid" is time synchronization issue -- AD DC has >>>> time behind IPA DC. Check time and time zone settings. >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >>> >>> > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ender at kofeina.net Thu Mar 5 07:32:32 2015 From: ender at kofeina.net (=?iso-8859-2?Q?=A3ukasz_Jaworski?=) Date: Thu, 5 Mar 2015 08:32:32 +0100 Subject: [Freeipa-users] group issue (freeipa4) Message-ID: <35B76CE4-2DAF-4D33-92D3-DD6B2232997E@kofeina.net> Hello, I have group issue on sssd 1.8.6 and 1.11.5 (on ubuntu 12.04 and 14.04) and freeipa4 (freeipa-server-4.1.2-1 on fedora 21, 389-ds-base-1.3.3.8-1). If user has assigned Role I couldn't get all groups with "id" command. All works for users without role/special permissions. Information about test users from ipa server: User with role helpdesk: # ipa user-show test1 User login: test1 Member of groups: testgroup2, testgroup3, ipausers, testgroup4, testgroup1 Roles: helpdesk User without role: # ipa user-show test2 User login: test2 Member of groups: testgroup2, ipausers, testgroup4, testgroup1, testgroup3 Information about user on client (ubuntu 12.04): # id test1 uid=1016(test1) gid=1016(test1) groups=1016(test1) # id test2 uid=1022(test2) gid=1022(test2) groups=1022(test2),1014(testgroup4),1012(testgroup3),1011(testgroup2),1004(testgroup1) (Thu Mar 5 08:23:54 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'test1' matched without domain, user is test1 (Thu Mar 5 08:23:54 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Thu Mar 5 08:23:54 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test1] from [] (Thu Mar 5 08:23:54 2015) [sssd[nss]] [nss_cmd_initgroups_search] (0x0100): Requesting info for [test1 at example.com] (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=test1] (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_parse_deref] (0x0080): Dereferenced entry [cn=helpdesk,cn=roles,cn=accounts,dc=example] has no attributes (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_x_deref_parse_entry] (0x0040): sdap_parse_deref failed [22]: Invalid argument (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_get_generic_ext_done] (0x0020): reply parsing callback failed. (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_x_deref_search_done] (0x0100): sdap_get_generic_ext_recv failed [22]: Invalid argument (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_deref_search_done] (0x0040): dereference processing failed [22]: Invalid argument (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,22,Init group lookup failed (Thu Mar 5 08:23:54 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 22, Init group lookup failed Will try to return what we have in cache sssd.conf: [domain/example.com] cache_credentials = True krb5_store_password_if_offline = True krb5_realm = example ipa_domain = example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = test.example.com chpass_provider = ipa ipa_server =ipaserver.example.com ldap_tls_cacert = /etc/ipa/ca.crt enumerate = False min_id = 1000 lookup_family_order = ipv4_only [sssd] services = nss, pam, sudo, ssh config_file_version = 2 domains = example.com [nss] [pam] [sudo] [autofs] [ssh] Best regards ?ukasz Jaworski "Ender" From jhrozek at redhat.com Thu Mar 5 07:54:28 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 5 Mar 2015 08:54:28 +0100 Subject: [Freeipa-users] group issue (freeipa4) In-Reply-To: <35B76CE4-2DAF-4D33-92D3-DD6B2232997E@kofeina.net> References: <35B76CE4-2DAF-4D33-92D3-DD6B2232997E@kofeina.net> Message-ID: <20150305075428.GA3481@hendrix.arn.redhat.com> On Thu, Mar 05, 2015 at 08:32:32AM +0100, ?ukasz Jaworski wrote: > Hello, > > I have group issue on sssd 1.8.6 and 1.11.5 (on ubuntu 12.04 and 14.04) and freeipa4 (freeipa-server-4.1.2-1 on fedora 21, 389-ds-base-1.3.3.8-1). > > If user has assigned Role I couldn't get all groups with "id" command. > All works for users without role/special permissions. > > Information about test users from ipa server: > > User with role helpdesk: > # ipa user-show test1 > User login: test1 > Member of groups: testgroup2, testgroup3, ipausers, testgroup4, testgroup1 > Roles: helpdesk > > User without role: > # ipa user-show test2 > User login: test2 > Member of groups: testgroup2, ipausers, testgroup4, testgroup1, testgroup3 > > Information about user on client (ubuntu 12.04): > > # id test1 > uid=1016(test1) gid=1016(test1) groups=1016(test1) > > # id test2 > uid=1022(test2) gid=1022(test2) groups=1022(test2),1014(testgroup4),1012(testgroup3),1011(testgroup2),1004(testgroup1) > > > (Thu Mar 5 08:23:54 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'test1' matched without domain, user is test1 > (Thu Mar 5 08:23:54 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] > (Thu Mar 5 08:23:54 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test1] from [] > (Thu Mar 5 08:23:54 2015) [sssd[nss]] [nss_cmd_initgroups_search] (0x0100): Requesting info for [test1 at example.com] > (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=test1] > (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] > (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] > (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] > (Thu Mar 5 08:23:54 2015) [sssd[be[example.com]]] [sdap_parse_deref] (0x0080): Dereferenced entry [cn=helpdesk,cn=roles,cn=accounts,dc=example] has no attributes This ^^ line tells me it's a known SSSD bug: https://fedorahosted.org/sssd/ticket/2421 This bug only happens in a combination of old client and a particular server version. IIRC a subsequent server update fixed the ACIs on the server so that at least objectClass was readable. You can also work around the bug on the client by disabling dereference: ldap_deref_threshold = 0 btw sssd version 1.8 is quite old and not supported upstream anymore.. From mkosek at redhat.com Thu Mar 5 07:54:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 05 Mar 2015 08:54:30 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <20150305013712.23AB3C043C@smtp.hushmail.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> Message-ID: <54F80BB6.7090405@redhat.com> On 03/05/2015 02:37 AM, reesb at hushmail.com wrote: > Opps, I got that wrong, my groups don't show the 'uniqueMember' attribute. Here is an example returned from ldapsearch; > > # admins, groups, compat, localdomain.local > dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local > gidNumber: 756200000 > memberUid: admin > memberUid: vadmin > objectClass: posixGroup > objectClass: groupOfUniqueNames > objectClass: top > cn: admins > > > On 3/5/2015 at 9:15 AM, reesb at hushmail.com wrote: > > Hi Martin, > > Using my vadmin account, "uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local", the search completes successfully and i get a list of my users and groups however when I've watched the ldap queries between vcenter and freeipa I can see it's applying a filter to the user search looking for 'objectClass=groupOfUniqueNames' which my groups don't seem to contain. > > > I'm very much an ldap newbie but I thought at step two in the vsphere integration howto I modified the groups schema to include that object class? > > On 3/4/2015 at 8:32 PM, "Martin Kosek" wrote: > > Given that this HOWTO does not use the vanilla Schema Compatibility settings > (FreeIPA Compat Tree by default uses posixGroup objectclass and memberUid > attribute for user membership), I would check if the groups really have the > right objectclass and uniqueMember generated: > > # ldapsearch -D "VSPHERE_DN" -x -w "$VSPHERE_DN_PASSWORD" -b > "cn=groups,cn=compat,dc=localdomain,dc=local" > > I expect there will be some problem preventing the LDAP search to succeed. Then > we would know where to look next. > > Martin > I am also CCing Gialunca who contributed the HOWTO. I checked it again and tried to apply it on my FreeIPA 4.1.3, my compat group now contain the proper uniqueMember attribute and groupOfUniqueNames objectclass. I am not sure though why are also users updated (mostly question to Gialunca): dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config changetype: modify add: schema-compat-entry-attribute schema-compat-entry-attribute: objectclass=uniqueMember - add: schema-compat-entry-attribute schema-compat-entry-attribute: objectclass=inetOrgPerson - For instance, "uniqueMember" is not valid objectclass. Also, if you are adding iNetOrgPerson objectclass, you should have all it's MUST attributes also generated - otherwise consuming programs may break if they depend on such attributes to exist. I see that "sn" is missing in my compat user entries. Can you show the "cn=groups,cn=Schema Compatibility,cn=plugins,cn=config" entry so that we can see if the uniqueMember attribute is really configured correctly? Thanks, Martin From reesb at hushmail.com Thu Mar 5 08:16:03 2015 From: reesb at hushmail.com (reesb at hushmail.com) Date: Thu, 05 Mar 2015 16:16:03 +0800 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <54F80BB6.7090405@redhat.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> Message-ID: <20150305081603.64785C043C@smtp.hushmail.com> Ok here is the search result; # ldapsearch -x -D "cn=Directory Manager" -W -b "cn=config" cn=groups Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: cn=groups # requesting: ALL # # groups, Schema Compatibility, plugins, config dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config cn: groups objectClass: top objectClass: extensibleObject schema-compat-container-group: cn=compat, dc=localdomain,dc=local schema-compat-search-filter: objectclass=posixGroup schema-compat-container-rdn: cn=groups schema-compat-entry-rdn: cn=%{cn} schema-compat-search-base: cn=groups, cn=accounts, dc=localdomain,dc=local schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objec tclass=ipaOverrideTarget","") schema-compat-entry-attribute: gidNumber=%{gidNumber} schema-compat-entry-attribute: memberUid=%deref_r("member","uid") schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchor uuid=:IPA:cloud.local:%{ipauniqueid}","") schema-compat-entry-attribute: memberUid=%{memberUid} schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectcla ss=ipaOverrideTarget","") schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} schema-compat-entry-attribute: objectclass=posixGroup schema-compat-entry-attribute: objectclass=groupOfUniqueNames schema-compat-entry-attribute: uniqueMember=%regsub("%{member}","^(.*)accounts (.*)","%1compat%2") schema-compat-restrict-subtree: cn=Schema Compatibility,cn=plugins,cn=config schema-compat-restrict-subtree: dc=localdomain,dc=local # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 On 3/5/2015 at 3:54 PM, "Martin Kosek" wrote: > >On 03/05/2015 02:37 AM, reesb at hushmail.com wrote: >> Opps, I got that wrong, my groups don't show the 'uniqueMember' >attribute. Here is an example returned from ldapsearch; >> >> # admins, groups, compat, localdomain.local >> dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local >> gidNumber: 756200000 >> memberUid: admin >> memberUid: vadmin >> objectClass: posixGroup >> objectClass: groupOfUniqueNames >> objectClass: top >> cn: admins >> >> >> On 3/5/2015 at 9:15 AM, reesb at hushmail.com wrote: >> >> Hi Martin, >> >> Using my vadmin account, >"uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local", the >search completes successfully and i get a list of my users and >groups however when I've watched the ldap queries between vcenter >and freeipa I can see it's applying a filter to the user search >looking for 'objectClass=groupOfUniqueNames' which my groups don't >seem to contain. >> >> >> I'm very much an ldap newbie but I thought at step two in the >vsphere integration howto I modified the groups schema to include >that object class? >> >> On 3/4/2015 at 8:32 PM, "Martin Kosek" wrote: >> >> Given that this HOWTO does not use the vanilla Schema >Compatibility settings >> (FreeIPA Compat Tree by default uses posixGroup objectclass and >memberUid >> attribute for user membership), I would check if the groups >really have the >> right objectclass and uniqueMember generated: >> >> # ldapsearch -D "VSPHERE_DN" -x -w "$VSPHERE_DN_PASSWORD" -b >> "cn=groups,cn=compat,dc=localdomain,dc=local" >> >> I expect there will be some problem preventing the LDAP search >to succeed. Then >> we would know where to look next. >> >> Martin >> > >I am also CCing Gialunca who contributed the HOWTO. I checked it >again and >tried to apply it on my FreeIPA 4.1.3, my compat group now contain >the proper >uniqueMember attribute and groupOfUniqueNames objectclass. > >I am not sure though why are also users updated (mostly question >to Gialunca): >dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >changetype: modify >add: schema-compat-entry-attribute >schema-compat-entry-attribute: objectclass=uniqueMember >- >add: schema-compat-entry-attribute >schema-compat-entry-attribute: objectclass=inetOrgPerson >- > >For instance, "uniqueMember" is not valid objectclass. Also, if >you are adding >iNetOrgPerson objectclass, you should have all it's MUST >attributes also >generated - otherwise consuming programs may break if they depend >on such >attributes to exist. I see that "sn" is missing in my compat user >entries. > >Can you show the "cn=groups,cn=Schema >Compatibility,cn=plugins,cn=config" entry >so that we can see if the uniqueMember attribute is really >configured correctly? > >Thanks, >Martin From gianluca.cecchi at gmail.com Thu Mar 5 08:29:58 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 5 Mar 2015 09:29:58 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <54F80BB6.7090405@redhat.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 8:54 AM, Martin Kosek wrote: > > I am also CCing Gialunca who contributed the HOWTO. I checked it again and > tried to apply it on my FreeIPA 4.1.3, my compat group now contain the > proper > uniqueMember attribute and groupOfUniqueNames objectclass. > > I am not sure though why are also users updated (mostly question to > Gialunca): > dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config > changetype: modify > add: schema-compat-entry-attribute > schema-compat-entry-attribute: objectclass=uniqueMember > - > add: schema-compat-entry-attribute > schema-compat-entry-attribute: objectclass=inetOrgPerson > - > > For instance, "uniqueMember" is not valid objectclass. Also, if you are > adding > iNetOrgPerson objectclass, you should have all it's MUST attributes also > generated - otherwise consuming programs may break if they depend on such > attributes to exist. I see that "sn" is missing in my compat user entries. > > Can you show the "cn=groups,cn=Schema Compatibility,cn=plugins,cn=config" > entry > so that we can see if the uniqueMember attribute is really configured > correctly? > > Thanks, > Martin > users' updates were force by vSphere originated queries. For example without adding iNetOrgPerson objectclass, when I wanted to bind a permission to a user and searched for users in vSPhere, I got this error 05/Dec/2014:22:59:21 +0100] conn=1831 op=34 SRCH base="cn=users,cn=compat,dc=localdomain,dc=local" scope=2 filter="(&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson))" attrs="description entryuuid givenName initials mail pwdaccountlockedtime shadowExpire sn title uid userPassword" So I verified that adding inetOrgPerson I was then able to add users to permissions. Probably I have to check which are the MUST attributes for it so that we add the too As far as I understood, the use of compat was indeed to add uniqueMember that is expected to be there by vSphere, at least in 5.1 Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From ender at kofeina.net Thu Mar 5 09:22:35 2015 From: ender at kofeina.net (=?iso-8859-2?Q?=A3ukasz_Jaworski?=) Date: Thu, 5 Mar 2015 10:22:35 +0100 Subject: [Freeipa-users] group issue (freeipa4) In-Reply-To: <20150305075428.GA3481@hendrix.arn.redhat.com> References: <35B76CE4-2DAF-4D33-92D3-DD6B2232997E@kofeina.net> <20150305075428.GA3481@hendrix.arn.redhat.com> Message-ID: <0D44F44B-A520-4D41-BAB9-9A37A90B2401@kofeina.net> > This ^^ line tells me it's a known SSSD bug: > https://fedorahosted.org/sssd/ticket/2421 > > This bug only happens in a combination of old client and a particular > server version. > > IIRC a subsequent server update fixed the ACIs on the server so that at > least objectClass was readable. You can also work around the bug on the > client by disabling dereference: > ldap_deref_threshold = 0 > > btw sssd version 1.8 is quite old and not supported upstream anymore.. Thx. We will switch to newer version sssd. Best regards, Ender -- ?ukasz Jaworski From jhrozek at redhat.com Thu Mar 5 09:33:23 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 5 Mar 2015 10:33:23 +0100 Subject: [Freeipa-users] group issue (freeipa4) In-Reply-To: <0D44F44B-A520-4D41-BAB9-9A37A90B2401@kofeina.net> References: <35B76CE4-2DAF-4D33-92D3-DD6B2232997E@kofeina.net> <20150305075428.GA3481@hendrix.arn.redhat.com> <0D44F44B-A520-4D41-BAB9-9A37A90B2401@kofeina.net> Message-ID: <20150305093323.GD3481@hendrix.arn.redhat.com> On Thu, Mar 05, 2015 at 10:22:35AM +0100, ?ukasz Jaworski wrote: > > This ^^ line tells me it's a known SSSD bug: > > https://fedorahosted.org/sssd/ticket/2421 > > > > This bug only happens in a combination of old client and a particular > > server version. > > > > IIRC a subsequent server update fixed the ACIs on the server so that at > > least objectClass was readable. You can also work around the bug on the > > client by disabling dereference: > > ldap_deref_threshold = 0 > > > > btw sssd version 1.8 is quite old and not supported upstream anymore.. > > Thx. > > We will switch to newer version sssd. > > Best regards, > Ender You can also open a bug against Ubuntu and ask them to backport the fix for #2421, it should be doable (but I haven't tried, really..) From mkosek at redhat.com Thu Mar 5 09:37:53 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 05 Mar 2015 10:37:53 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> Message-ID: <54F823F1.3000202@redhat.com> On 03/05/2015 09:29 AM, Gianluca Cecchi wrote: > On Thu, Mar 5, 2015 at 8:54 AM, Martin Kosek wrote: > >> >> I am also CCing Gialunca who contributed the HOWTO. I checked it again and >> tried to apply it on my FreeIPA 4.1.3, my compat group now contain the >> proper >> uniqueMember attribute and groupOfUniqueNames objectclass. >> >> I am not sure though why are also users updated (mostly question to >> Gialunca): >> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >> changetype: modify >> add: schema-compat-entry-attribute >> schema-compat-entry-attribute: objectclass=uniqueMember >> - >> add: schema-compat-entry-attribute >> schema-compat-entry-attribute: objectclass=inetOrgPerson >> - >> >> For instance, "uniqueMember" is not valid objectclass. Also, if you are >> adding >> iNetOrgPerson objectclass, you should have all it's MUST attributes also >> generated - otherwise consuming programs may break if they depend on such >> attributes to exist. I see that "sn" is missing in my compat user entries. >> >> Can you show the "cn=groups,cn=Schema Compatibility,cn=plugins,cn=config" >> entry >> so that we can see if the uniqueMember attribute is really configured >> correctly? >> >> Thanks, >> Martin >> > > > users' updates were force by vSphere originated queries. > For example without adding iNetOrgPerson objectclass, when I wanted to bind > a permission to a user and searched for users in vSPhere, I got this error > > 05/Dec/2014:22:59:21 +0100] conn=1831 op=34 SRCH > base="cn=users,cn=compat,dc=localdomain,dc=local" scope=2 > filter="(&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson))" > attrs="description entryuuid givenName initials mail pwdaccountlockedtime > shadowExpire sn title uid userPassword" I see. The filter is quite strange though, I am not sure why is vSphere searching for the same value twice. I assume this is a (benign) bug in vSphere: (&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson)) > So I verified that adding inetOrgPerson I was then able to add users to > permissions. > Probably I have to check which are the MUST attributes for it so that we > add the too > > As far as I understood, the use of compat was indeed to add uniqueMember > that is expected to be there by vSphere, at least in 5.1 I checked the MUST already, I updated http://www.freeipa.org/page/HowTo/vsphere5_integration and added the missing SN attribute and removed the invalid objectClass. I hope that's fine with you. HTH, Martin From mkosek at redhat.com Thu Mar 5 09:43:58 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 05 Mar 2015 10:43:58 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <20150305081603.64785C043C@smtp.hushmail.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> <20150305081603.64785C043C@smtp.hushmail.com> Message-ID: <54F8255E.4000401@redhat.com> Thanks. The configuration looks OK, I wonder why the uniqueMember is not generated for your compat groups - it works on my FreeIPA 4.1.3 server. Did you restart the Directory Server after you changed the Schema Compatibility plugin? On 03/05/2015 09:16 AM, reesb at hushmail.com wrote: > Ok here is the search result; > # ldapsearch -x -D "cn=Directory Manager" -W -b "cn=config" cn=groups > Enter LDAP Password: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: cn=groups > # requesting: ALL > # > > # groups, Schema Compatibility, plugins, config > dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config > cn: groups > objectClass: top > objectClass: extensibleObject > schema-compat-container-group: cn=compat, dc=localdomain,dc=local > schema-compat-search-filter: objectclass=posixGroup > schema-compat-container-rdn: cn=groups > schema-compat-entry-rdn: cn=%{cn} > schema-compat-search-base: cn=groups, cn=accounts, dc=localdomain,dc=local > schema-compat-entry-attribute: %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objec > tclass=ipaOverrideTarget","") > schema-compat-entry-attribute: gidNumber=%{gidNumber} > schema-compat-entry-attribute: memberUid=%deref_r("member","uid") > schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchor > uuid=:IPA:cloud.local:%{ipauniqueid}","") > schema-compat-entry-attribute: memberUid=%{memberUid} > schema-compat-entry-attribute: %ifeq("ipauniqueid","%{ipauniqueid}","objectcla > ss=ipaOverrideTarget","") > schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} > schema-compat-entry-attribute: objectclass=posixGroup > schema-compat-entry-attribute: objectclass=groupOfUniqueNames > schema-compat-entry-attribute: uniqueMember=%regsub("%{member}","^(.*)accounts > (.*)","%1compat%2") > schema-compat-restrict-subtree: cn=Schema Compatibility,cn=plugins,cn=config > schema-compat-restrict-subtree: dc=localdomain,dc=local > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > On 3/5/2015 at 3:54 PM, "Martin Kosek" wrote: >> >> On 03/05/2015 02:37 AM, reesb at hushmail.com wrote: >>> Opps, I got that wrong, my groups don't show the 'uniqueMember' >> attribute. Here is an example returned from ldapsearch; >>> >>> # admins, groups, compat, localdomain.local >>> dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local >>> gidNumber: 756200000 >>> memberUid: admin >>> memberUid: vadmin >>> objectClass: posixGroup >>> objectClass: groupOfUniqueNames >>> objectClass: top >>> cn: admins >>> >>> >>> On 3/5/2015 at 9:15 AM, reesb at hushmail.com wrote: >>> >>> Hi Martin, >>> >>> Using my vadmin account, >> "uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local", the >> search completes successfully and i get a list of my users and >> groups however when I've watched the ldap queries between vcenter >> and freeipa I can see it's applying a filter to the user search >> looking for 'objectClass=groupOfUniqueNames' which my groups don't >> seem to contain. >>> >>> >>> I'm very much an ldap newbie but I thought at step two in the >> vsphere integration howto I modified the groups schema to include >> that object class? >>> >>> On 3/4/2015 at 8:32 PM, "Martin Kosek" wrote: >>> >>> Given that this HOWTO does not use the vanilla Schema >> Compatibility settings >>> (FreeIPA Compat Tree by default uses posixGroup objectclass and >> memberUid >>> attribute for user membership), I would check if the groups >> really have the >>> right objectclass and uniqueMember generated: >>> >>> # ldapsearch -D "VSPHERE_DN" -x -w "$VSPHERE_DN_PASSWORD" -b >>> "cn=groups,cn=compat,dc=localdomain,dc=local" >>> >>> I expect there will be some problem preventing the LDAP search >> to succeed. Then >>> we would know where to look next. >>> >>> Martin >>> >> >> I am also CCing Gialunca who contributed the HOWTO. I checked it >> again and >> tried to apply it on my FreeIPA 4.1.3, my compat group now contain >> the proper >> uniqueMember attribute and groupOfUniqueNames objectclass. >> >> I am not sure though why are also users updated (mostly question >> to Gialunca): >> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >> changetype: modify >> add: schema-compat-entry-attribute >> schema-compat-entry-attribute: objectclass=uniqueMember >> - >> add: schema-compat-entry-attribute >> schema-compat-entry-attribute: objectclass=inetOrgPerson >> - >> >> For instance, "uniqueMember" is not valid objectclass. Also, if >> you are adding >> iNetOrgPerson objectclass, you should have all it's MUST >> attributes also >> generated - otherwise consuming programs may break if they depend >> on such >> attributes to exist. I see that "sn" is missing in my compat user >> entries. >> >> Can you show the "cn=groups,cn=Schema >> Compatibility,cn=plugins,cn=config" entry >> so that we can see if the uniqueMember attribute is really >> configured correctly? >> >> Thanks, >> Martin > From gianluca.cecchi at gmail.com Thu Mar 5 10:18:11 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 5 Mar 2015 11:18:11 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <54F823F1.3000202@redhat.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> <54F823F1.3000202@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 10:37 AM, Martin Kosek wrote: > > > > > users' updates were force by vSphere originated queries. > > For example without adding iNetOrgPerson objectclass, when I wanted to > bind > > a permission to a user and searched for users in vSPhere, I got this > error > > > > 05/Dec/2014:22:59:21 +0100] conn=1831 op=34 SRCH > > base="cn=users,cn=compat,dc=localdomain,dc=local" scope=2 > > filter="(&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson))" > > attrs="description entryuuid givenName initials mail pwdaccountlockedtime > > shadowExpire sn title uid userPassword" > > I see. The filter is quite strange though, I am not sure why is vSphere > searching for the same value twice. I assume this is a (benign) bug in > vSphere: > > (&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson)) > > > So I verified that adding inetOrgPerson I was then able to add users to > > permissions. > > Probably I have to check which are the MUST attributes for it so that we > > add the too > > > > As far as I understood, the use of compat was indeed to add uniqueMember > > that is expected to be there by vSphere, at least in 5.1 > > I checked the MUST already, I updated > > http://www.freeipa.org/page/HowTo/vsphere5_integration > > and added the missing SN attribute and removed the invalid objectClass. I > hope > that's fine with you. > > HTH, > Martin > OK for the SN. But what about uniqueMember removal? Would complete then successfully the query that is based on this modification on compat groups: schema-compat-entry-attribute: uniqueMember=%regsub("%{member}","^(.*)accounts(.*)","%1compat%2") ? As far as I verified, vSphere 5.1 makes this query to check if a user has a role, as deriving from being part of a group: ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local" "(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local))" and without uniqueMember, I could bind roles directly against users, but the ones applied on groups were not inherited by the users inside the group... Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Mar 5 13:11:51 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 05 Mar 2015 14:11:51 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> <54F823F1.3000202@redhat.com> Message-ID: <54F85617.2010404@redhat.com> On 03/05/2015 11:18 AM, Gianluca Cecchi wrote: > On Thu, Mar 5, 2015 at 10:37 AM, Martin Kosek wrote: > >> >>> >>> users' updates were force by vSphere originated queries. >>> For example without adding iNetOrgPerson objectclass, when I wanted to >> bind >>> a permission to a user and searched for users in vSPhere, I got this >> error >>> >>> 05/Dec/2014:22:59:21 +0100] conn=1831 op=34 SRCH >>> base="cn=users,cn=compat,dc=localdomain,dc=local" scope=2 >>> filter="(&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson))" >>> attrs="description entryuuid givenName initials mail pwdaccountlockedtime >>> shadowExpire sn title uid userPassword" >> >> I see. The filter is quite strange though, I am not sure why is vSphere >> searching for the same value twice. I assume this is a (benign) bug in >> vSphere: >> >> (&(objectClass=inetOrgPerson)(objectClass=inetOrgPerson)) >> >>> So I verified that adding inetOrgPerson I was then able to add users to >>> permissions. >>> Probably I have to check which are the MUST attributes for it so that we >>> add the too >>> >>> As far as I understood, the use of compat was indeed to add uniqueMember >>> that is expected to be there by vSphere, at least in 5.1 >> >> I checked the MUST already, I updated >> >> http://www.freeipa.org/page/HowTo/vsphere5_integration >> >> and added the missing SN attribute and removed the invalid objectClass. I >> hope >> that's fine with you. >> >> HTH, >> Martin >> > > > OK for the SN. > But what about uniqueMember removal? uniqueMember is not a valid objectclass. uniqueMember makes sense as an attribute for group, but not as an objectclass for user. > Would complete then successfully the query that is based on this > modification on compat groups: > schema-compat-entry-attribute: > uniqueMember=%regsub("%{member}","^(.*)accounts(.*)","%1compat%2") > > ? It does work for me. I see no connection between the uniqueMember definition above and uniqueMember objectclass. > > As far as I verified, vSphere 5.1 makes this query to check if a user has a > role, as deriving from being part of a group: > ldapsearch -x -b "cn=groups,cn=compat,dc=localdomain,dc=local" > "(&(objectClass=groupOfUniqueNames)(uniqueMember=uid=gcecchi,cn=users,cn=compat,dc=localdomain,dc=local))" > > and without uniqueMember, I could bind roles directly against users, but > the ones applied on groups were not inherited by the users inside the > group... Note that I only removed "objectclass=uniqueMember" definition from user entries, not the useful uniqueMember definition from groups. Martin From andrew.holway at gmail.com Thu Mar 5 17:41:09 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 5 Mar 2015 18:41:09 +0100 Subject: [Freeipa-users] Freeipa and dns Message-ID: Hello, We're working on a plan to spin up a bunch of private networks around the globe and we would like to use freeipa as our domain controller. I'm trying to work out how we do DNS. Actually, more specifically, making sure that hosts are authenticating against its local freeipa. Each regional domain controller should be replicating with the other regional domain controllers however how do we tell machines in the US to auth against the US freeipa and the EU machines to auth against the EU freeipa. If we point the DNS in our machines to the US freeipa will that freeipa respond with SRV records for itself? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Thu Mar 5 18:40:22 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 5 Mar 2015 10:40:22 -0800 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <20150305062644.GI25455@redhat.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <20150305062644.GI25455@redhat.com> Message-ID: <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> > You need to use authenticated bind and password proxying. There are two > actions here: > 1. Add system account in IPA > To create a system account for NS_LDAP_BINDDN, use > > # cat <45-my-solaris-binddn.update > dn: uid=solaris,cn=sysaccounts,cn=etc,\$SUFFIX > add:objectclass:account,simplesecurityobject > add:uid:solaris > add:userPassword:"ohaimakethissimethingtoughtobreak" > add:passwordExpirationTime:20380119031407Z > add:nsIdleTimeout:0 > END > > # ipa-ldap-updater -l ./45-my-solaris-binddn.update > Frsing update file './45-my-solaris-binddn.update' > New entry: uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test > The ipa-ldap-updater command was successful This all worked fine and I was able to verify the account password : # ldapwhoami -vvv -h 127.0.0.1 -D uid=solaris,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net -x -w ldap_initialize( ldap://127.0.0.1 ) dn: uid=solaris,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net Result: Success (0) > 2. Setup Solaris properly > NS_LDAP_AUTH=tls:simple > NS_LDAP_CREDENTIAL_LEVEL=proxy > NS_LDAP_BINDDN=uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test > NS_LDAP_BINDPASSWD=ohaimakethissimethingtoughtobreak > NS_LDAP_CACHETTL=0 > NS_LDAP_HOST_CERTPATH=/var/ldap This part I have questions about. When I setup Solaris originally I used ldapclient init so it automatically creates (and updates based on the duaprofile) the configs. If I edit the file manually to make the changes you suggest, they will be overwritten at midnight when the ldapclient downloads the newest duaconfig. Instead I reconfigured using the ldapclient and the following settings: ldapclient manual -a credentialLevel=proxy -a authenticationMethod=tls:simple -a defaultSearchBase=dc=ipadomain,dc=net -a domainName=ipadomain.net -a defaultServerList=10.21.19.20 -a proxyDN=uid=solaris2,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net -a proxyPassword="changeme" -a objectClassMap=shadow:shadowAccount=posixAccount -a serviceSearchDescriptor=group:cn=groups,cn=compat,dc=ipadomain,dc=net -a serviceSearchDescriptor=passwd:cn=users,cn=compat,dc=ipadomain,dc=net I noted that in your example below you set passwd:cn=users,cn=accounts but then you later stated that it should actually be compat, so I did passwd:cn=users,cn=compat > > and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) > into /var/ldap's database with certutil: > # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap > This part I'm really confused about. If I run that on the Solaris server I get : bash-3.00# certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap bash: certutil: command not found If I run that on the ipa DC I get : [root at ipadc1 ipa]# certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key database is in an old, unsupported format. By following the Fedora 17 guide I had done this successfully: # certutil -N -d . [root at ipaserver ~]# scp cert8.db solaris.example.com:/var/ldap [root at ipaserver ~]# scp key3.db solaris.example.com:/var/ldap Is that functionally equivalent to what you were trying to do with the cert database or were you trying to do something different? > > Obviously, you'll have your own $SUFFIX value in NS_LDAP_* entries. > > And point LDAP_SERVICE_SEARCH_DESC for passwd to the compat tree. > >>NS_LDAP_SEARCH_REF= TRUE >>NS_LDAP_SEARCH_TIME= 15 >>NS_LDAP_PROFILE= default >>NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=mydomain,dc=net >>NS_LDAP_SERVICE_SEARCH_DESC= >> passwd:cn=users,cn=accounts,dc=mydomain,dc=net >>NS_LDAP_BIND_TIME= 5 >>NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount >> >>I see that the users are coming from the accounts tree and the groups are >>coming from the compat tree. Is this right? The trust was created with >>--enable-compat so I'm surprised that only the groups are coming from the >>compat tree. >> >>Does FreeIPA serve up an improperly configured DefaultDUAProfile > No, it serves a profile which is fine for non-AD case because all we > need to override is group management -- Solaris expects RFC2307, not > RFC2307bis. But for AD users you need to point passwd to compat tree > cn=users,cn=compat,.. as well -- we simulate LDAP objects there for AD > users on request. > > Additionally, a default DUA profile assumes you are using Kerberos > authentication and thus don't need LDAP bind proxying to verify > passwords. Could you clarify this a little bit? In the case of a FreeIPA native user, pam only lists pam_krb5.so modules so I assume that all login is handled by kerberos and not ldap. This doesn't explain how pam manages to set the user to the correct shell, because that shell information is obviously in ldap, yet I don't mention pam_ldap.so anywhere in my pam configurations. Also, if what you wrote below is true and AD users are authenticated not by kerberos, but by authenticated ldap binds, won't that totally fail if I don't mention pam_ldap in my pam configuration? > It is not true in the case of AD users as they couldn't be > seen differently by Solaris. As result, you have to do LDAP bind against > compat tree. When the Schema Compatibility Plugin is configured to > expose users from trusted domains, their authentication is handled via > PAM 'system-auth' service. This service exists by default on Linux > systems and is provided by pam package as /etc/pam.d/system-auth. If > your FreeIPA install does not have default HBAC rule 'allow_all' > enabled, then make sure to define in IPA a special service called > 'system-auth' and create an HBAC rule to allow access to anyone to this > rule on IPA masters. > > As 'system-auth' PAM service is not used directly by any other > application, it is safe to use it for trusted domain users via > compatibility path. > > > -- > / Alexander Bokovoy > After From abokovoy at redhat.com Thu Mar 5 19:13:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 5 Mar 2015 21:13:43 +0200 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <20150305062644.GI25455@redhat.com> <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> Message-ID: <20150305191343.GQ25455@redhat.com> On Thu, 05 Mar 2015, nathan at nathanpeters.com wrote: >> You need to use authenticated bind and password proxying. There are two >> actions here: >> 1. Add system account in IPA >> To create a system account for NS_LDAP_BINDDN, use >> >> # cat <45-my-solaris-binddn.update >> dn: uid=solaris,cn=sysaccounts,cn=etc,\$SUFFIX >> add:objectclass:account,simplesecurityobject >> add:uid:solaris >> add:userPassword:"ohaimakethissimethingtoughtobreak" >> add:passwordExpirationTime:20380119031407Z >> add:nsIdleTimeout:0 >> END >> >> # ipa-ldap-updater -l ./45-my-solaris-binddn.update >> Frsing update file './45-my-solaris-binddn.update' >> New entry: uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test >> The ipa-ldap-updater command was successful > >This all worked fine and I was able to verify the account password : > ># ldapwhoami -vvv -h 127.0.0.1 -D >uid=solaris,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net -x -w password> >ldap_initialize( ldap://127.0.0.1 ) >dn: uid=solaris,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net >Result: Success (0) > > >> 2. Setup Solaris properly >> NS_LDAP_AUTH=tls:simple >> NS_LDAP_CREDENTIAL_LEVEL=proxy >> NS_LDAP_BINDDN=uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test >> NS_LDAP_BINDPASSWD=ohaimakethissimethingtoughtobreak >> NS_LDAP_CACHETTL=0 >> NS_LDAP_HOST_CERTPATH=/var/ldap > >This part I have questions about. When I setup Solaris originally I used >ldapclient init so it automatically creates (and updates based on the >duaprofile) the configs. If I edit the file manually to make the changes >you suggest, they will be overwritten at midnight when the ldapclient >downloads the newest duaconfig. > >Instead I reconfigured using the ldapclient and the following settings: >ldapclient manual -a credentialLevel=proxy -a >authenticationMethod=tls:simple -a defaultSearchBase=dc=ipadomain,dc=net >-a domainName=ipadomain.net -a defaultServerList=10.21.19.20 -a >proxyDN=uid=solaris2,cn=sysaccounts,cn=etc,dc=ipadomain,dc=net -a >proxyPassword="changeme" -a >objectClassMap=shadow:shadowAccount=posixAccount -a >serviceSearchDescriptor=group:cn=groups,cn=compat,dc=ipadomain,dc=net -a >serviceSearchDescriptor=passwd:cn=users,cn=compat,dc=ipadomain,dc=net Right. >I noted that in your example below you set passwd:cn=users,cn=accounts That was a quote of your config, not mine. > >but then you later stated that it should actually be compat, so I did >passwd:cn=users,cn=compat Yes, this is what I wanted you to do. > >> >> and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) >> into /var/ldap's database with certutil: >> # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap >> > >This part I'm really confused about. If I run that on the Solaris server >I get : >bash-3.00# certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap >bash: certutil: command not found You need to download certutil package for Solaris. Others had some success in using a database copied from IPA server but this is generally not something that we can rely on. >If I run that on the ipa DC I get : > >[root at ipadc1 ipa]# certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap >certutil: function failed: SEC_ERROR_LEGACY_DATABASE: The certificate/key >database is in an old, unsupported format. > >By following the Fedora 17 guide I had done this successfully: > ># certutil -N -d . >[root at ipaserver ~]# scp cert8.db solaris.example.com:/var/ldap >[root at ipaserver ~]# scp key3.db solaris.example.com:/var/ldap > >Is that functionally equivalent to what you were trying to do with the >cert database or were you trying to do something different? More or less -- create an NSS database and add a CA cert there. >> RFC2307bis. But for AD users you need to point passwd to compat tree >> cn=users,cn=compat,.. as well -- we simulate LDAP objects there for AD >> users on request. >> >> Additionally, a default DUA profile assumes you are using Kerberos >> authentication and thus don't need LDAP bind proxying to verify >> passwords. > >Could you clarify this a little bit? In the case of a FreeIPA native >user, pam only lists pam_krb5.so modules so I assume that all login is >handled by kerberos and not ldap. This doesn't explain how pam manages to >set the user to the correct shell, because that shell information is >obviously in ldap, yet I don't mention pam_ldap.so anywhere in my pam >configurations. PAM has different stages -- authentication, session, etc. Shell, UID/GID and other parameters are coming from nsswitch interface, not PAM. On the other hand PAM allows to stack multiple modules to perform the same action so you can have both pam_krb5 and pam_ldap in the stack and cover both Kerberos ticket and password-based logins. >Also, if what you wrote below is true and AD users are authenticated not >by kerberos, but by authenticated ldap binds, won't that totally fail if I >don't mention pam_ldap in my pam configuration? Yep, it would fail but there are few separate things we need to clarify first. Did you add your Solaris host into IPA? Did you create a keytab for it? Is your Solaris host FQDN If answers are yes, yes, and yes, then AD users, when connecting to Solaris host from their Windows machines will attempt to obtain Kerberos ticket and IPA KDC will grant a service ticket to them thanks to cross-forest trust. When AD user using putty would present that ticket to Solaris, chances are that pam_krb5 will accept it and allow to login. When AD users have no Kerberos ticket, then they would attempt to do a password login. To verify this login you would need to bind to IPA LDAP's as AD user, using its DN from the compat tree and then actual authentication would happen on IPA master as part of LDAP bind processing. -- / Alexander Bokovoy From danofsatx at gmail.com Thu Mar 5 21:15:14 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 5 Mar 2015 15:15:14 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited Message-ID: Good day, folks. This time it is something different, yet the same. I have re-deployed my IPA installation due to some underlying issues with the host of the virtual machine. Even with the new installation, I cannot authenticate through the web UI. So far, there is exactly one client in the domain (my workstation), and exactly one user - admin. I am not comfortable with the command line tools, and I have others below my position that require a GUI for management purposes, so I have to make this work to proceed any further. Following up with the information Martin asked for in my previous thread, let me walk you through the process: I attempted to log in to https://vader.rez.lcl/, and received the error "Your session has expired. Please re-login." At this point, I clicked the link to configure Firefox. On the command line, I obtained a kerberos ticket for admin (note - I am root on this workstation for the time being): [root at dmfedora ~]# kinit admin Password for admin at REZ.LCL: [root at dmfedora ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: admin at REZ.LCL Valid starting Expires Service principal 03/05/2015 14:46:22 03/06/2015 14:46:15 krbtgt/REZ.LCL at REZ.LCL I then finished the Firefox configuration, and attempted to log in again. I still received the error. The Firefox console shows: POST https://vader.rez.lcl/ipa/session/login_password [HTTP/1.1 200 Success 756ms] POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized 3ms] GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 401 Unauthorized 2ms] GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 200 Success 26ms] POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized 4ms] /var/log/krb5kdc.log during the process: Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425589590, etypes {rep=18 tkt=18 ses=18}, HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425589590, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL /var/log/httpd/access_log shows the same thing as the Firefox console: 10.1.1.15 - - [05/Mar/2015:21:06:30 +0000] "POST /ipa/session/login_password HTTP/1.1" 200 25 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json HTTP/1.1" 401 - 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "GET /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 401 1469 10.1.1.15 - admin at REZ.LCL [05/Mar/2015:21:06:31 +0000] "GET /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 200 20 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json HTTP/1.1" 401 - Nothing is entered into any error logs, the audit log, or the system journal. I am at my wits end here, and lost. What other information do you need to help me solve this problem? Thank you, Dan Mossor -- 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathan at nathanpeters.com Thu Mar 5 21:51:17 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 5 Mar 2015 13:51:17 -0800 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <20150305191343.GQ25455@redhat.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <20150305062644.GI25455@redhat.com> <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> <20150305191343.GQ25455@redhat.com> Message-ID: <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> Ok, I sort of have this working now, but there are still some loose ends. Comments inline >>> 2. Setup Solaris properly >>> NS_LDAP_AUTH=tls:simple >>> NS_LDAP_CREDENTIAL_LEVEL=proxy >>> NS_LDAP_BINDDN=uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test >>> NS_LDAP_BINDPASSWD=ohaimakethissimethingtoughtobreak >>> NS_LDAP_CACHETTL=0 >>> NS_LDAP_HOST_CERTPATH=/var/ldap When I added NS_LDAP_HOST_CERTPATH to the ldap_client_file it complained about that particular setting being invalid. I think that setting doesn't exist on Solaris 10? I had to remove that line. >>Is that functionally equivalent to what you were trying to do with the >>cert database or were you trying to do something different? > More or less -- create an NSS database and add a CA cert there. OK, great, I think the manual copy worked. The reason is because if I delete those 2 .db files I get the following log entries: [ID 293258 daemon.warning] libsldap: Status: 91 Mesg: createTLSSession: failed to initialize TLS security (security library: bad database.) [ID 545954 daemon.error] libsldap: makeConnection: failed to open connection to ipadc1.ipadomain.net [ID 687686 daemon.warning] libsldap: Falling back to anonymous, non-SSL mode for __ns_ldap_getRootDSE. createTLSSession: failed to initialize TLS security (security library: bad database.) But if those 2 files I manually copied exist, then those messages don't happen. Also, FYI, certutil is not really supported on Solaris 10. Any download links to that program are now 404. It wasn't included in the Solaris 10 cd either. > PAM has different stages -- authentication, session, etc. Shell, > UID/GID and other parameters are coming from nsswitch interface, not > PAM. > > On the other hand PAM allows to stack multiple modules to perform the > same action so you can have both pam_krb5 and pam_ldap in the stack and > cover both Kerberos ticket and password-based logins. > >>Also, if what you wrote below is true and AD users are authenticated not >>by kerberos, but by authenticated ldap binds, won't that totally fail if >> I >>don't mention pam_ldap in my pam configuration? > Yep, it would fail but there are few separate things we need to clarify > first. > > Did you add your Solaris host into IPA? Did you create a keytab for > it? Is your Solaris host FQDN > > If answers are yes, yes, and yes, then AD users, when connecting to > Solaris host from their Windows machines will attempt to obtain Kerberos > ticket and IPA KDC will grant a service ticket to them thanks to > cross-forest trust. When AD user using putty would present that ticket > to Solaris, chances are that pam_krb5 will accept it and allow to login. > > When AD users have no Kerberos ticket, then they would attempt to do a > password login. To verify this login you would need to bind to IPA > LDAP's as AD user, using its DN from the compat tree and then actual > authentication would happen on IPA master as part of LDAP bind > processing. Yes, yes, and yes :) OK, I have added the following 2 lines to my pam.conf file and I can now authenticate AD users: other auth sufficient pam_ldap.so.1 other account required pam_ldap.so.1 However, I had to use a slighly different setting when initiating ldap client: ldapclient manual -a credentialLevel=proxy -a authenticationMethod=simple Note that if I chose tls:simple, the bind failed and I received the following log entries : Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net ldap_cachemgr[650]: [ID 293258 daemon.warning] libsldap: Status: 81 Mesg: openConnection: simple bind failed - Can't contact LDAP server Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net ldap_cachemgr[650]: [ID 545954 daemon.error] libsldap: makeConnection: failed to open connection to ipadc1.ipadomain.net Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net ldap_cachemgr[650]: [ID 687686 daemon.warning] libsldap: Falling back to anonymous, non-SSL mode for __ns_ldap_getRootDSE. openConnection: simple bind failed - Can't contact LDAP server So... any ideas why I could bind 'simple' but not 'tls:simple' ? From dpal at redhat.com Thu Mar 5 22:03:52 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Mar 2015 17:03:52 -0500 Subject: [Freeipa-users] Freeipa and dns In-Reply-To: References: Message-ID: <54F8D2C8.8090800@redhat.com> On 03/05/2015 12:41 PM, Andrew Holway wrote: > Hello, > > We're working on a plan to spin up a bunch of private networks around > the globe and we would like to use freeipa as our domain controller. > > I'm trying to work out how we do DNS. Actually, more specifically, > making sure that hosts are authenticating against its local freeipa. > Each regional domain controller should be replicating with the other > regional domain controllers however how do we tell machines in the US > to auth against the US freeipa and the EU machines to auth against the > EU freeipa. > > If we point the DNS in our machines to the US freeipa will that > freeipa respond with SRV records for itself? FreeIPA does not support DNS sites yet. https://fedorahosted.org/freeipa/ticket/2008 https://fedorahosted.org/bind-dyndb-ldap/ticket/126 It is in plans for the next release but as a stretch goal. For now the work around would be to have an explicit set of servers configured on the clients. You will loose a bit of agility if you plan to deploy replicas dynamically but if you do not plan to do that static server list might be a work around for now. > > Thanks, > > Andrew > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Mar 5 22:16:56 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Mar 2015 17:16:56 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: Message-ID: <54F8D5D8.4010509@redhat.com> On 03/05/2015 04:15 PM, Dan Mossor wrote: > Good day, folks. > > This time it is something different, yet the same. I have re-deployed > my IPA installation due to some underlying issues with the host of the > virtual machine. Even with the new installation, I cannot authenticate > through the web UI. > > So far, there is exactly one client in the domain (my workstation), > and exactly one user - admin. I am not comfortable with the command > line tools, and I have others below my position that require a GUI for > management purposes, so I have to make this work to proceed any further. > > Following up with the information Martin asked for in my previous > thread, let me walk you through the process: > > I attempted to log in to https://vader.rez.lcl/, and received the > error "Your session has expired. Please re-login." At this point, I > clicked the link to configure Firefox. On the command line, I obtained > a kerberos ticket for admin (note - I am root on this workstation for > the time being): > > [root at dmfedora ~]# kinit admin > Password for admin at REZ.LCL: > [root at dmfedora ~]# klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: admin at REZ.LCL > > Valid starting Expires Service principal > 03/05/2015 14:46:22 03/06/2015 14:46:15 krbtgt/REZ.LCL at REZ.LCL > > I then finished the Firefox configuration, and attempted to log in > again. I still received the error. The Firefox console shows: > > POST https://vader.rez.lcl/ipa/session/login_password [HTTP/1.1 200 > Success 756ms] > POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized > 3ms] > GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 401 > Unauthorized 2ms] > GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 200 > Success 26ms] > POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized > 4ms] > > /var/log/krb5kdc.log during the process: > Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.0.1 : NEEDED_PREAUTH: > HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional > pre-authentication required > Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.0.1 : ISSUE: authtime > 1425589590, etypes {rep=18 tkt=18 ses=18}, HTTP/vader.rez.lcl at REZ.LCL > for krbtgt/REZ.LCL at REZ.LCL > Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.0.1 : NEEDED_PREAUTH: > admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional > pre-authentication required > Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.0.1 : ISSUE: authtime > 1425589590, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL for > krbtgt/REZ.LCL at REZ.LCL > > /var/log/httpd/access_log shows the same thing as the Firefox console: > 10.1.1.15 - - [05/Mar/2015:21:06:30 +0000] "POST > /ipa/session/login_password HTTP/1.1" 200 25 > 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json > HTTP/1.1" 401 - > 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "GET > /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 401 1469 > 10.1.1.15 - admin at REZ.LCL [05/Mar/2015:21:06:31 +0000] "GET > /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 200 20 > 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json > HTTP/1.1" 401 - > > Nothing is entered into any error logs, the audit log, or the system > journal. I am at my wits end here, and lost. What other information do > you need to help me solve this problem? > > Thank you, > Dan Mossor > > -- > 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 > > Can you authenticate using UI from the server host? It seems that the Kerberos authentication goes through but then it is lost. So here are some wild ideas: - Is the browser properly configured? May be there is something with the browser that is not working? Have you cleaned the old IPA CA cert? It might not be related but I have seen issues in the past with it. - Are you sure that server has all the components? For example session on the server side is stored in memcached. If it is not running or something is not right with it the ticket sharing might be broken. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danofsatx at gmail.com Thu Mar 5 22:34:37 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 5 Mar 2015 16:34:37 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54F8D5D8.4010509@redhat.com> References: <54F8D5D8.4010509@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 4:16 PM, Dmitri Pal wrote: > On 03/05/2015 04:15 PM, Dan Mossor wrote: > > Good day, folks. > > This time it is something different, yet the same. I have re-deployed my > IPA installation due to some underlying issues with the host of the virtual > machine. Even with the new installation, I cannot authenticate through the > web UI. > > So far, there is exactly one client in the domain (my workstation), and > exactly one user - admin. I am not comfortable with the command line tools, > and I have others below my position that require a GUI for management > purposes, so I have to make this work to proceed any further. > > Following up with the information Martin asked for in my previous > thread, let me walk you through the process: > > I attempted to log in to https://vader.rez.lcl/, and received the error > "Your session has expired. Please re-login." At this point, I clicked the > link to configure Firefox. On the command line, I obtained a kerberos > ticket for admin (note - I am root on this workstation for the time being): > > [root at dmfedora ~]# kinit admin > Password for admin at REZ.LCL: > [root at dmfedora ~]# klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: admin at REZ.LCL > > Valid starting Expires Service principal > 03/05/2015 14:46:22 03/06/2015 14:46:15 krbtgt/REZ.LCL at REZ.LCL > > I then finished the Firefox configuration, and attempted to log in > again. I still received the error. The Firefox console shows: > > POST https://vader.rez.lcl/ipa/session/login_password [HTTP/1.1 200 > Success 756ms] > POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized > 3ms] > GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 401 > Unauthorized 2ms] > GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 200 > Success 26ms] > POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized > 4ms] > > /var/log/krb5kdc.log during the process: > Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: HTTP/vader.rez.lcl at REZ.LCL for > krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required > Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425589590, etypes {rep=18 tkt=18 > ses=18}, HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL > Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: admin at REZ.LCL for > krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required > Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425589590, etypes {rep=18 tkt=18 > ses=18}, admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL > > /var/log/httpd/access_log shows the same thing as the Firefox console: > 10.1.1.15 - - [05/Mar/2015:21:06:30 +0000] "POST > /ipa/session/login_password HTTP/1.1" 200 25 > 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json > HTTP/1.1" 401 - > 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "GET > /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 401 1469 > 10.1.1.15 - admin at REZ.LCL [05/Mar/2015:21:06:31 +0000] "GET > /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 200 20 > 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json > HTTP/1.1" 401 - > > Nothing is entered into any error logs, the audit log, or the system > journal. I am at my wits end here, and lost. What other information do you > need to help me solve this problem? > > Thank you, > Dan Mossor > > -- > > 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 > > > > Can you authenticate using UI from the server host? > It seems that the Kerberos authentication goes through but then it is lost. > So here are some wild ideas: > - Is the browser properly configured? May be there is something with the > browser that is not working? Have you cleaned the old IPA CA cert? It might > not be related but I have seen issues in the past with it. > - Are you sure that server has all the components? For example session on > the server side is stored in memcached. If it is not running or something > is not right with it the ticket sharing might be broken. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > First off, apologies if the thread is broken - I am stuck using the Gmail interface temporarily. The server host - both the actual host and the IPA server - do not have GUIs on them, so I cannot launch a web browser from them. The old IPA CA cert was never on this workstation - this workstation was built Tuesday, and the IPA server deployed yesterday. The previous one I was having issues with had already been wiped - so this is starting off from scratch with both the server and the client. I did check the ipa_memcached service as suggested by Martin in my previous thread. [root at vader ipa]# systemctl status httpd.service dirsrv at REZ-LCL.service ipa_memcached.service ? httpd.service - The Apache HTTP Server Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) Active: active (running) since Fri 2015-03-06 18:19:16 GMT; 19h left Main PID: 1103 (httpd) Status: "Total requests: 150; Idle/Busy workers 100/0;Requests/sec: 3.49e-08; Bytes served/sec: 0 B/sec" CGroup: /system.slice/httpd.service ??1103 /usr/sbin/httpd -DFOREGROUND ??1104 /usr/libexec/nss_pcache 98307 off /etc/httpd/alias ??1105 /usr/sbin/httpd -DFOREGROUND ??1107 /usr/sbin/httpd -DFOREGROUND ??1108 /usr/sbin/httpd -DFOREGROUND ??1111 /usr/sbin/httpd -DFOREGROUND ??1113 /usr/sbin/httpd -DFOREGROUND ??1339 /usr/sbin/httpd -DFOREGROUND ??1471 /usr/sbin/httpd -DFOREGROUND ??1473 /usr/sbin/httpd -DFOREGROUND ??1474 /usr/sbin/httpd -DFOREGROUND ??1475 /usr/sbin/httpd -DFOREGROUND ??1926 /usr/sbin/httpd -DFOREGROUND ??1927 /usr/sbin/httpd -DFOREGROUND Mar 05 19:58:34 vader.rez.lcl httpd[1107]: GSSAPI client step 1 Mar 05 19:58:34 vader.rez.lcl httpd[1107]: GSSAPI client step 2 Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 2 Mar 05 19:58:35 vader.rez.lcl httpd[1107]: GSSAPI client step 1 Mar 05 19:58:35 vader.rez.lcl httpd[1107]: GSSAPI client step 1 Mar 05 19:58:36 vader.rez.lcl httpd[1107]: GSSAPI client step 1 Mar 05 19:58:36 vader.rez.lcl httpd[1107]: GSSAPI client step 2 ? dirsrv at REZ-LCL.service - 389 Directory Server REZ-LCL. Loaded: loaded (/usr/lib/systemd/system/dirsrv at .service; enabled) Active: active (running) since Fri 2015-03-06 18:18:53 GMT; 19h left Process: 1006 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS) Main PID: 1020 (ns-slapd) CGroup: /system.slice/system-dirsrv.slice/dirsrv at REZ-LCL.service ??1020 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-REZ-LCL -i /var/run/dirsrv/slapd-REZ-LCL.pid -w /var/run/dirsrv/slapd-REZ-LCL.startpid Mar 05 21:43:46 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 Mar 05 21:58:46 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 Mar 05 21:58:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 Mar 05 21:58:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 ? ipa_memcached.service - IPA memcached daemon, increases IPA server performance Loaded: loaded (/usr/lib/systemd/system/ipa_memcached.service; disabled) Active: active (running) since Fri 2015-03-06 18:19:15 GMT; 19h left Process: 1094 ExecStart=/usr/bin/memcached -d -s $SOCKET_PATH -u $USER -m $CACHESIZE -c $MAXCONN -P /var/run/ipa_memcached/ipa_memcached.pid $OPTIONS (code=exited, status=0/SUCCESS) Main PID: 1095 (memcached) CGroup: /system.slice/ipa_memcached.service ??1095 /usr/bin/memcached -d -s /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P /var/run/ipa_memcached/ipa_memcached.pid [root at vader ipa]# Thanks, 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danofsatx at gmail.com Thu Mar 5 22:51:52 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 5 Mar 2015 16:51:52 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 4:34 PM, Dan Mossor wrote: > > > On Thu, Mar 5, 2015 at 4:16 PM, Dmitri Pal wrote: > >> On 03/05/2015 04:15 PM, Dan Mossor wrote: >> >> Good day, folks. >> >> This time it is something different, yet the same. I have re-deployed >> my IPA installation due to some underlying issues with the host of the >> virtual machine. Even with the new installation, I cannot authenticate >> through the web UI. >> >> So far, there is exactly one client in the domain (my workstation), and >> exactly one user - admin. I am not comfortable with the command line tools, >> and I have others below my position that require a GUI for management >> purposes, so I have to make this work to proceed any further. >> >> Following up with the information Martin asked for in my previous >> thread, let me walk you through the process: >> >> I attempted to log in to https://vader.rez.lcl/, and received the error >> "Your session has expired. Please re-login." At this point, I clicked the >> link to configure Firefox. On the command line, I obtained a kerberos >> ticket for admin (note - I am root on this workstation for the time being): >> >> [root at dmfedora ~]# kinit admin >> Password for admin at REZ.LCL: >> [root at dmfedora ~]# klist >> Ticket cache: KEYRING:persistent:0:0 >> Default principal: admin at REZ.LCL >> >> Valid starting Expires Service principal >> 03/05/2015 14:46:22 03/06/2015 14:46:15 krbtgt/REZ.LCL at REZ.LCL >> >> I then finished the Firefox configuration, and attempted to log in >> again. I still received the error. The Firefox console shows: >> >> POST https://vader.rez.lcl/ipa/session/login_password [HTTP/1.1 200 >> Success 756ms] >> POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized >> 3ms] >> GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 401 >> Unauthorized 2ms] >> GET https://vader.rez.lcl/ipa/session/login_kerberos [HTTP/1.1 200 >> Success 26ms] >> POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 Unauthorized >> 4ms] >> >> /var/log/krb5kdc.log during the process: >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 >> 17 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: HTTP/vader.rez.lcl at REZ.LCL >> for krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 >> 17 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425589590, etypes {rep=18 >> tkt=18 ses=18}, HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 >> 17 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: admin at REZ.LCL for >> krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 >> 17 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425589590, etypes {rep=18 >> tkt=18 ses=18}, admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL >> >> /var/log/httpd/access_log shows the same thing as the Firefox console: >> 10.1.1.15 - - [05/Mar/2015:21:06:30 +0000] "POST >> /ipa/session/login_password HTTP/1.1" 200 25 >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json >> HTTP/1.1" 401 - >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "GET >> /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 401 1469 >> 10.1.1.15 - admin at REZ.LCL [05/Mar/2015:21:06:31 +0000] "GET >> /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 200 20 >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST /ipa/session/json >> HTTP/1.1" 401 - >> >> Nothing is entered into any error logs, the audit log, or the system >> journal. I am at my wits end here, and lost. What other information do you >> need to help me solve this problem? >> >> Thank you, >> Dan Mossor >> >> -- >> >> 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 >> >> >> >> Can you authenticate using UI from the server host? >> It seems that the Kerberos authentication goes through but then it is >> lost. >> So here are some wild ideas: >> - Is the browser properly configured? May be there is something with the >> browser that is not working? Have you cleaned the old IPA CA cert? It might >> not be related but I have seen issues in the past with it. >> - Are you sure that server has all the components? For example session on >> the server side is stored in memcached. If it is not running or something >> is not right with it the ticket sharing might be broken. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> First off, apologies if the thread is broken - I am stuck using the Gmail > interface temporarily. > > The server host - both the actual host and the IPA server - do not have > GUIs on them, so I cannot launch a web browser from them. The old IPA CA > cert was never on this workstation - this workstation was built Tuesday, > and the IPA server deployed yesterday. The previous one I was having issues > with had already been wiped - so this is starting off from scratch with > both the server and the client. I did check the ipa_memcached service as > suggested by Martin in my previous thread. > > [root at vader ipa]# systemctl status httpd.service dirsrv at REZ-LCL.service > ipa_memcached.service > ? httpd.service - The Apache HTTP Server > Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) > Active: active (running) since Fri 2015-03-06 18:19:16 GMT; 19h left > Main PID: 1103 (httpd) > Status: "Total requests: 150; Idle/Busy workers 100/0;Requests/sec: > 3.49e-08; Bytes served/sec: 0 B/sec" > CGroup: /system.slice/httpd.service > ??1103 /usr/sbin/httpd -DFOREGROUND > ??1104 /usr/libexec/nss_pcache 98307 off /etc/httpd/alias > ??1105 /usr/sbin/httpd -DFOREGROUND > ??1107 /usr/sbin/httpd -DFOREGROUND > ??1108 /usr/sbin/httpd -DFOREGROUND > ??1111 /usr/sbin/httpd -DFOREGROUND > ??1113 /usr/sbin/httpd -DFOREGROUND > ??1339 /usr/sbin/httpd -DFOREGROUND > ??1471 /usr/sbin/httpd -DFOREGROUND > ??1473 /usr/sbin/httpd -DFOREGROUND > ??1474 /usr/sbin/httpd -DFOREGROUND > ??1475 /usr/sbin/httpd -DFOREGROUND > ??1926 /usr/sbin/httpd -DFOREGROUND > ??1927 /usr/sbin/httpd -DFOREGROUND > > Mar 05 19:58:34 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1107]: GSSAPI client step 2 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 2 > Mar 05 19:58:35 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:35 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:36 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:36 vader.rez.lcl httpd[1107]: GSSAPI client step 2 > > ? dirsrv at REZ-LCL.service - 389 Directory Server REZ-LCL. > Loaded: loaded (/usr/lib/systemd/system/dirsrv at .service; enabled) > Active: active (running) since Fri 2015-03-06 18:18:53 GMT; 19h left > Process: 1006 ExecStart=/usr/sbin/ns-slapd -D /etc/dirsrv/slapd-%i -i > /var/run/dirsrv/slapd-%i.pid -w /var/run/dirsrv/slapd-%i.startpid > (code=exited, status=0/SUCCESS) > Main PID: 1020 (ns-slapd) > CGroup: /system.slice/system-dirsrv.slice/dirsrv at REZ-LCL.service > ??1020 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-REZ-LCL -i > /var/run/dirsrv/slapd-REZ-LCL.pid -w /var/run/dirsrv/slapd-REZ-LCL.startpid > > Mar 05 21:43:46 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 21:58:46 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 21:58:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 21:58:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > > ? ipa_memcached.service - IPA memcached daemon, increases IPA server > performance > Loaded: loaded (/usr/lib/systemd/system/ipa_memcached.service; disabled) > Active: active (running) since Fri 2015-03-06 18:19:15 GMT; 19h left > Process: 1094 ExecStart=/usr/bin/memcached -d -s $SOCKET_PATH -u $USER > -m $CACHESIZE -c $MAXCONN -P /var/run/ipa_memcached/ipa_memcached.pid > $OPTIONS (code=exited, status=0/SUCCESS) > Main PID: 1095 (memcached) > CGroup: /system.slice/ipa_memcached.service > ??1095 /usr/bin/memcached -d -s > /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P > /var/run/ipa_memcached/ipa_memcached.pid > [root at vader ipa]# > > Thanks, > 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 > > > As an additional test, I created a new user on my workstation and switched to it. the first thing I did was kinit as admin, then started Firefox, went through the browser configuration provided by the IPA server, and attempted to log in. I received the same error[1]. [1]http://i.imgur.com/mhX86Ng.png -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Mar 5 22:55:20 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Mar 2015 17:55:20 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> Message-ID: <54F8DED8.8040402@redhat.com> On 03/05/2015 05:51 PM, Dan Mossor wrote: > On Thu, Mar 5, 2015 at 4:34 PM, Dan Mossor > wrote: > > > > On Thu, Mar 5, 2015 at 4:16 PM, Dmitri Pal > wrote: > > On 03/05/2015 04:15 PM, Dan Mossor wrote: >> Good day, folks. >> >> This time it is something different, yet the same. I have >> re-deployed my IPA installation due to some underlying issues >> with the host of the virtual machine. Even with the new >> installation, I cannot authenticate through the web UI. >> >> So far, there is exactly one client in the domain (my >> workstation), and exactly one user - admin. I am not >> comfortable with the command line tools, and I have others >> below my position that require a GUI for management purposes, >> so I have to make this work to proceed any further. >> >> Following up with the information Martin asked for in my >> previous thread, let me walk you through the process: >> >> I attempted to log in to https://vader.rez.lcl/, and received >> the error "Your session has expired. Please re-login." At >> this point, I clicked the link to configure Firefox. On the >> command line, I obtained a kerberos ticket for admin (note - >> I am root on this workstation for the time being): >> >> [root at dmfedora ~]# kinit admin >> Password for admin at REZ.LCL : >> [root at dmfedora ~]# klist >> Ticket cache: KEYRING:persistent:0:0 >> Default principal: admin at REZ.LCL >> >> Valid starting Expires Service principal >> 03/05/2015 14:46:22 03/06/2015 14:46:15 >> krbtgt/REZ.LCL at REZ.LCL >> >> I then finished the Firefox configuration, and attempted to >> log in again. I still received the error. The Firefox console >> shows: >> >> POST https://vader.rez.lcl/ipa/session/login_password >> [HTTP/1.1 200 Success 756ms] >> POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 >> Unauthorized 3ms] >> GET https://vader.rez.lcl/ipa/session/login_kerberos >> [HTTP/1.1 401 Unauthorized 2ms] >> GET https://vader.rez.lcl/ipa/session/login_kerberos >> [HTTP/1.1 200 Success 26ms] >> POST https://vader.rez.lcl/ipa/session/json [HTTP/1.1 401 >> Unauthorized 4ms] >> >> /var/log/krb5kdc.log during the process: >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.0.1 : >> NEEDED_PREAUTH: HTTP/vader.rez.lcl at REZ.LCL >> for >> krbtgt/REZ.LCL at REZ.LCL , >> Additional pre-authentication required >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.0.1 : >> ISSUE: authtime 1425589590, etypes {rep=18 tkt=18 ses=18}, >> HTTP/vader.rez.lcl at REZ.LCL >> for >> krbtgt/REZ.LCL at REZ.LCL >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.0.1 : >> NEEDED_PREAUTH: admin at REZ.LCL for >> krbtgt/REZ.LCL at REZ.LCL , >> Additional pre-authentication required >> Mar 05 21:06:30 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.0.1 : >> ISSUE: authtime 1425589590, etypes {rep=18 tkt=18 ses=18}, >> admin at REZ.LCL for >> krbtgt/REZ.LCL at REZ.LCL >> >> /var/log/httpd/access_log shows the same thing as the Firefox >> console: >> 10.1.1.15 - - [05/Mar/2015:21:06:30 +0000] "POST >> /ipa/session/login_password HTTP/1.1" 200 25 >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST >> /ipa/session/json HTTP/1.1" 401 - >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "GET >> /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 401 1469 >> 10.1.1.15 - admin at REZ.LCL >> [05/Mar/2015:21:06:31 +0000] "GET >> /ipa/session/login_kerberos?_=1425587158134 HTTP/1.1" 200 20 >> 10.1.1.15 - - [05/Mar/2015:21:06:31 +0000] "POST >> /ipa/session/json HTTP/1.1" 401 - >> >> Nothing is entered into any error logs, the audit log, or the >> system journal. I am at my wits end here, and lost. What >> other information do you need to help me solve this problem? >> >> Thank you, >> Dan Mossor >> >> -- >> 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 >> >> > Can you authenticate using UI from the server host? > It seems that the Kerberos authentication goes through but > then it is lost. > So here are some wild ideas: > - Is the browser properly configured? May be there is > something with the browser that is not working? Have you > cleaned the old IPA CA cert? It might not be related but I > have seen issues in the past with it. > - Are you sure that server has all the components? For example > session on the server side is stored in memcached. If it is > not running or something is not right with it the ticket > sharing might be broken. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > First off, apologies if the thread is broken - I am stuck using > the Gmail interface temporarily. > > The server host - both the actual host and the IPA server - do not > have GUIs on them, so I cannot launch a web browser from them. The > old IPA CA cert was never on this workstation - this workstation > was built Tuesday, and the IPA server deployed yesterday. The > previous one I was having issues with had already been wiped - so > this is starting off from scratch with both the server and the > client. I did check the ipa_memcached service as suggested by > Martin in my previous thread. > > [root at vader ipa]# systemctl status httpd.service > dirsrv at REZ-LCL.service ipa_memcached.service > ? httpd.service - The Apache HTTP Server > Loaded: loaded (/usr/lib/systemd/system/httpd.service; disabled) > Active: active (running) since Fri 2015-03-06 18:19:16 GMT; 19h > left > Main PID: 1103 (httpd) > Status: "Total requests: 150; Idle/Busy workers > 100/0;Requests/sec: 3.49e-08; Bytes served/sec: 0 B/sec" > CGroup: /system.slice/httpd.service > ??1103 /usr/sbin/httpd -DFOREGROUND > ??1104 /usr/libexec/nss_pcache 98307 off /etc/httpd/alias > ??1105 /usr/sbin/httpd -DFOREGROUND > ??1107 /usr/sbin/httpd -DFOREGROUND > ??1108 /usr/sbin/httpd -DFOREGROUND > ??1111 /usr/sbin/httpd -DFOREGROUND > ??1113 /usr/sbin/httpd -DFOREGROUND > ??1339 /usr/sbin/httpd -DFOREGROUND > ??1471 /usr/sbin/httpd -DFOREGROUND > ??1473 /usr/sbin/httpd -DFOREGROUND > ??1474 /usr/sbin/httpd -DFOREGROUND > ??1475 /usr/sbin/httpd -DFOREGROUND > ??1926 /usr/sbin/httpd -DFOREGROUND > ??1927 /usr/sbin/httpd -DFOREGROUND > > Mar 05 19:58:34 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1107]: GSSAPI client step 2 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 1 > Mar 05 19:58:34 vader.rez.lcl httpd[1105]: GSSAPI client step 2 > Mar 05 19:58:35 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:35 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:36 vader.rez.lcl httpd[1107]: GSSAPI client step 1 > Mar 05 19:58:36 vader.rez.lcl httpd[1107]: GSSAPI client step 2 > > ? dirsrv at REZ-LCL.service - 389 Directory Server REZ-LCL. > Loaded: loaded (/usr/lib/systemd/system/dirsrv at .service; enabled) > Active: active (running) since Fri 2015-03-06 18:18:53 GMT; 19h > left > Process: 1006 ExecStart=/usr/sbin/ns-slapd -D > /etc/dirsrv/slapd-%i -i /var/run/dirsrv/slapd-%i.pid -w > /var/run/dirsrv/slapd-%i.startpid (code=exited, status=0/SUCCESS) > Main PID: 1020 (ns-slapd) > CGroup: /system.slice/system-dirsrv.slice/dirsrv at REZ-LCL.service > ??1020 /usr/sbin/ns-slapd -D /etc/dirsrv/slapd-REZ-LCL > -i /var/run/dirsrv/slapd-REZ-LCL.pid -w > /var/run/dirsrv/slapd-REZ-LCL.startpid > > Mar 05 21:43:46 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 21:58:46 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 21:58:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 21:58:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 22:13:47 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 1 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 2 > Mar 05 22:28:48 vader.rez.lcl ns-slapd[1020]: GSSAPI server step 3 > > ? ipa_memcached.service - IPA memcached daemon, increases IPA > server performance > Loaded: loaded (/usr/lib/systemd/system/ipa_memcached.service; > disabled) > Active: active (running) since Fri 2015-03-06 18:19:15 GMT; 19h > left > Process: 1094 ExecStart=/usr/bin/memcached -d -s $SOCKET_PATH -u > $USER -m $CACHESIZE -c $MAXCONN -P > /var/run/ipa_memcached/ipa_memcached.pid $OPTIONS (code=exited, > status=0/SUCCESS) > Main PID: 1095 (memcached) > CGroup: /system.slice/ipa_memcached.service > ??1095 /usr/bin/memcached -d -s > /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P > /var/run/ipa_memcached/ipa_memcached.pid > [root at vader ipa]# > > Thanks, > 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 > > As an additional test, I created a new user on my workstation and > switched to it. the first thing I did was kinit as admin, then started > Firefox, went through the browser configuration provided by the IPA > server, and attempted to log in. I received the same error[1]. > > [1]http://i.imgur.com/mhX86Ng.png > > Have you checked times and time zones on the client and on the server? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Mar 5 22:56:34 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Mar 2015 17:56:34 -0500 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <20150305062644.GI25455@redhat.com> <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> <20150305191343.GQ25455@redhat.com> <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> Message-ID: <54F8DF22.9060503@redhat.com> nathan at nathanpeters.com wrote: > Ok, I sort of have this working now, but there are still some loose ends. > Comments inline > >>>> 2. Setup Solaris properly >>>> NS_LDAP_AUTH=tls:simple >>>> NS_LDAP_CREDENTIAL_LEVEL=proxy >>>> NS_LDAP_BINDDN=uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test >>>> NS_LDAP_BINDPASSWD=ohaimakethissimethingtoughtobreak >>>> NS_LDAP_CACHETTL=0 >>>> NS_LDAP_HOST_CERTPATH=/var/ldap > > When I added NS_LDAP_HOST_CERTPATH to the ldap_client_file it complained > about that particular setting being invalid. I think that setting doesn't > exist on Solaris 10? I had to remove that line. > >>> Is that functionally equivalent to what you were trying to do with the >>> cert database or were you trying to do something different? >> More or less -- create an NSS database and add a CA cert there. > > OK, great, I think the manual copy worked. The reason is because if I > delete those 2 .db files I get the following log entries: > > [ID 293258 daemon.warning] libsldap: Status: 91 Mesg: createTLSSession: > failed to initialize TLS security (security library: bad database.) > [ID 545954 daemon.error] libsldap: makeConnection: failed to open > connection to ipadc1.ipadomain.net > [ID 687686 daemon.warning] libsldap: Falling back to anonymous, non-SSL > mode for __ns_ldap_getRootDSE. createTLSSession: failed to initialize TLS > security (security library: bad database.) > > But if those 2 files I manually copied exist, then those messages don't > happen. > > Also, FYI, certutil is not really supported on Solaris 10. Any download > links to that program are now 404. It wasn't included in the Solaris 10 > cd either. SUNWtlsu which installs in /usr/sfw/bin/certutil. It's in my install. I don't recall if I did any CD swapping during the install or not, though I installed x86 from iso. > >> PAM has different stages -- authentication, session, etc. Shell, >> UID/GID and other parameters are coming from nsswitch interface, not >> PAM. >> >> On the other hand PAM allows to stack multiple modules to perform the >> same action so you can have both pam_krb5 and pam_ldap in the stack and >> cover both Kerberos ticket and password-based logins. >> >>> Also, if what you wrote below is true and AD users are authenticated not >>> by kerberos, but by authenticated ldap binds, won't that totally fail if >>> I >>> don't mention pam_ldap in my pam configuration? >> Yep, it would fail but there are few separate things we need to clarify >> first. >> >> Did you add your Solaris host into IPA? Did you create a keytab for >> it? Is your Solaris host FQDN >> >> If answers are yes, yes, and yes, then AD users, when connecting to >> Solaris host from their Windows machines will attempt to obtain Kerberos >> ticket and IPA KDC will grant a service ticket to them thanks to >> cross-forest trust. When AD user using putty would present that ticket >> to Solaris, chances are that pam_krb5 will accept it and allow to login. >> >> When AD users have no Kerberos ticket, then they would attempt to do a >> password login. To verify this login you would need to bind to IPA >> LDAP's as AD user, using its DN from the compat tree and then actual >> authentication would happen on IPA master as part of LDAP bind >> processing. > > Yes, yes, and yes :) > > OK, I have added the following 2 lines to my pam.conf file and I can now > authenticate AD users: > other auth sufficient pam_ldap.so.1 > other account required pam_ldap.so.1 > > However, I had to use a slighly different setting when initiating ldap > client: > > ldapclient manual -a credentialLevel=proxy -a authenticationMethod=simple > > Note that if I chose tls:simple, the bind failed and I received the > following log entries : > Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net > ldap_cachemgr[650]: [ID 293258 daemon.warning] libsldap: Status: 81 Mesg: > openConnection: simple bind failed - Can't contact LDAP server > Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net > ldap_cachemgr[650]: [ID 545954 daemon.error] libsldap: makeConnection: > failed to open connection to ipadc1.ipadomain.net > Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net > ldap_cachemgr[650]: [ID 687686 daemon.warning] libsldap: Falling back to > anonymous, non-SSL mode for __ns_ldap_getRootDSE. openConnection: simple > bind failed - Can't contact LDAP server > > So... any ideas why I could bind 'simple' but not 'tls:simple' ? I'd check the 389-ds access log for connection problems. This works for me: ldapclient -v manual -a authenticationMethod=tls:simple \ -a defaultSearchBase=dc=example,dc=com \ -a defaultServerList=ipa.example.com \ -a serviceSearchDescriptor=passwd:cn=users,cn=accounts,dc=example,dc=com \ -a serviceSearchDescriptor=group:cn=groups,cn=compat,dc=example,dc=com \ -a proxyDN=uid=solaris,cn=sysaccounts,cn=etc,dc=example,dc=com \ -a proxyPassword=secret123 \ -a objectclassMap=shadow:shadowAccount=posixAccount I'd suggest you look bug https://bugzilla.redhat.com/show_bug.cgi?id=815515 Another IPA user contributed a secure DUA Profile which is quite complete. rob From rcritten at redhat.com Thu Mar 5 22:59:53 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 05 Mar 2015 17:59:53 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> Message-ID: <54F8DFE9.6070008@redhat.com> Dan Mossor wrote: > On Thu, Mar 5, 2015 at 4:34 PM, Dan Mossor > wrote: > > > As an additional test, I created a new user on my workstation and > switched to it. the first thing I did was kinit as admin, then started > Firefox, went through the browser configuration provided by the IPA > server, and attempted to log in. I received the same error[1]. > > [1]http://i.imgur.com/mhX86Ng.png I'd look for SELinux errors: ausearch -m AVC -ts recent Perhaps we can't create a login session for some reason. rob From danofsatx at gmail.com Thu Mar 5 23:17:10 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 5 Mar 2015 17:17:10 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54F8DED8.8040402@redhat.com> References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 4:55 PM, Dmitri Pal wrote: > On 03/05/2015 05:51 PM, Dan Mossor wrote: > > As an additional test, I created a new user on my workstation and > switched to it. the first thing I did was kinit as admin, then started > Firefox, went through the browser configuration provided by the IPA server, > and attempted to log in. I received the same error[1]. > > [1]http://i.imgur.com/mhX86Ng.png > > > Have you checked times and time zones on the client and on the server? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > The server is set for GMT time, whereas the client is set for local time, US Central Standard Time. Except for that difference, they are within 1 second of each other. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danofsatx at gmail.com Thu Mar 5 23:19:15 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 5 Mar 2015 17:19:15 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54F8DFE9.6070008@redhat.com> References: <54F8D5D8.4010509@redhat.com> <54F8DFE9.6070008@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 4:59 PM, Rob Crittenden wrote: > Dan Mossor wrote: > > On Thu, Mar 5, 2015 at 4:34 PM, Dan Mossor > > wrote: > > > > > > As an additional test, I created a new user on my workstation and > > switched to it. the first thing I did was kinit as admin, then started > > Firefox, went through the browser configuration provided by the IPA > > server, and attempted to log in. I received the same error[1]. > > > > [1]http://i.imgur.com/mhX86Ng.png > > I'd look for SELinux errors: ausearch -m AVC -ts recent > > Perhaps we can't create a login session for some reason. > > rob > > I checked the /var/log/audit/audit.log, and selinux is not reporting anything during the time I am attempting to access the gui. But, for the sake of thoroughness: [root at vader ipa]# ausearch -m AVC -ts recent [root at vader ipa]# 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From danofsatx at gmail.com Fri Mar 6 00:36:35 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 5 Mar 2015 18:36:35 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 5:17 PM, Dan Mossor wrote: > > > On Thu, Mar 5, 2015 at 4:55 PM, Dmitri Pal wrote: > >> On 03/05/2015 05:51 PM, Dan Mossor wrote: >> >> As an additional test, I created a new user on my workstation and >> switched to it. the first thing I did was kinit as admin, then started >> Firefox, went through the browser configuration provided by the IPA server, >> and attempted to log in. I received the same error[1]. >> >> [1]http://i.imgur.com/mhX86Ng.png >> >> >> Have you checked times and time zones on the client and on the server? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> The server is set for GMT time, whereas the client is set for local time, > US Central Standard Time. Except for that difference, they are within 1 > second of each other. > > Dan > As an experiment after this email exchange, I switched the server to Central Standard Time using timedatctl. I then ran kinit again, and attempted to log into the GUI. There was no change - I still cannot access the GUI. Here is the krb5kdc.log from the period: Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.1.15: NEEDED_PREAUTH: host/dmfedora.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.1.15: ISSUE: authtime 1425601734, etypes {rep=18 tkt=18 ses=18}, host/dmfedora.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.1.15: ISSUE: authtime 1425601734, etypes {rep=18 tkt=18 ses=18}, host/dmfedora.rez.lcl at REZ.LCL for ldap/vader.rez.lcl at REZ.LCL Mar 05 18:29:20 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.1.15: NEEDED_PREAUTH: admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required Mar 05 18:29:25 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.1.15: ISSUE: authtime 1425601765, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL Mar 05 18:29:26 vader.rez.lcl krb5kdc[1073](info): DISPATCH: repeated (retransmitted?) request from 10.1.1.15, resending previous response Mar 05 18:29:26 vader.rez.lcl krb5kdc[1073](info): closing down fd 12 Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425601784, etypes {rep=18 tkt=18 ses=18}, HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425601784, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.1.1.15: ISSUE: authtime 1425601765, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL for HTTP/vader.rez.lcl at REZ.LCL One thing I did determine is the authtime in the krb5kdc log is epoch time. I checked it, and it translates directly to the standard time. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 6 00:44:31 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Mar 2015 19:44:31 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> Message-ID: <54F8F86F.7000203@redhat.com> On 03/05/2015 07:36 PM, Dan Mossor wrote: > On Thu, Mar 5, 2015 at 5:17 PM, Dan Mossor > wrote: > > > > On Thu, Mar 5, 2015 at 4:55 PM, Dmitri Pal > wrote: > > On 03/05/2015 05:51 PM, Dan Mossor wrote: >> As an additional test, I created a new user on my workstation >> and switched to it. the first thing I did was kinit as admin, >> then started Firefox, went through the browser configuration >> provided by the IPA server, and attempted to log in. I >> received the same error[1]. >> >> [1]http://i.imgur.com/mhX86Ng.png >> >> > Have you checked times and time zones on the client and on the > server? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > The server is set for GMT time, whereas the client is set for > local time, US Central Standard Time. Except for that difference, > they are within 1 second of each other. > > Dan > > As an experiment after this email exchange, I switched the server to > Central Standard Time using timedatctl. I then ran kinit again, and > attempted to log into the GUI. There was no change - I still cannot > access the GUI. Here is the krb5kdc.log from the period: > > Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.1.15 : NEEDED_PREAUTH: > host/dmfedora.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional > pre-authentication required > Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.1.15 : ISSUE: authtime > 1425601734, etypes {rep=18 tkt=18 ses=18}, > host/dmfedora.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL > Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): TGS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.1.15 : ISSUE: authtime > 1425601734, etypes {rep=18 tkt=18 ses=18}, > host/dmfedora.rez.lcl at REZ.LCL for ldap/vader.rez.lcl at REZ.LCL > Mar 05 18:29:20 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.1.15 : NEEDED_PREAUTH: > admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional > pre-authentication required > Mar 05 18:29:25 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.1.15 : ISSUE: authtime > 1425601765, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL for > krbtgt/REZ.LCL at REZ.LCL > Mar 05 18:29:26 vader.rez.lcl krb5kdc[1073](info): DISPATCH: repeated > (retransmitted?) request from 10.1.1.15, resending previous response > Mar 05 18:29:26 vader.rez.lcl krb5kdc[1073](info): closing down fd 12 > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.0.1 : NEEDED_PREAUTH: > HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional > pre-authentication required > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.0.1 : ISSUE: authtime > 1425601784, etypes {rep=18 tkt=18 ses=18}, HTTP/vader.rez.lcl at REZ.LCL > for krbtgt/REZ.LCL at REZ.LCL > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.0.1 : NEEDED_PREAUTH: > admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL, Additional > pre-authentication required > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.0.1 : ISSUE: authtime > 1425601784, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL for > krbtgt/REZ.LCL at REZ.LCL > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): TGS_REQ (6 etypes > {18 17 16 23 25 26}) 10.1.1.15 : ISSUE: authtime > 1425601765, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL for > HTTP/vader.rez.lcl at REZ.LCL > > > One thing I did determine is the authtime in the krb5kdc log is epoch > time. I checked it, and it translates directly to the standard time. > > Dan Hm. OK. I do not think there was ever mentioned which version of the server and client you are running but based on the UI it seems like the latest. Also you are trying to log in after using kinit. Can you log using forms based authentication or it does not work too? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From danofsatx at gmail.com Fri Mar 6 01:09:19 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 5 Mar 2015 19:09:19 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54F8F86F.7000203@redhat.com> References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 6:44 PM, Dmitri Pal wrote: > On 03/05/2015 07:36 PM, Dan Mossor wrote: > > On Thu, Mar 5, 2015 at 5:17 PM, Dan Mossor wrote: > >> >> >> On Thu, Mar 5, 2015 at 4:55 PM, Dmitri Pal wrote: >> >>> On 03/05/2015 05:51 PM, Dan Mossor wrote: >>> >>> As an additional test, I created a new user on my workstation and >>> switched to it. the first thing I did was kinit as admin, then started >>> Firefox, went through the browser configuration provided by the IPA server, >>> and attempted to log in. I received the same error[1]. >>> >>> [1]http://i.imgur.com/mhX86Ng.png >>> >>> >>> Have you checked times and time zones on the client and on the server? >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >>> >>> >>> The server is set for GMT time, whereas the client is set for local >> time, US Central Standard Time. Except for that difference, they are within >> 1 second of each other. >> >> Dan >> > As an experiment after this email exchange, I switched the server to > Central Standard Time using timedatctl. I then ran kinit again, and > attempted to log into the GUI. There was no change - I still cannot access > the GUI. Here is the krb5kdc.log from the period: > > Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.1.15: NEEDED_PREAUTH: host/dmfedora.rez.lcl at REZ.LCL > for krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required > Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.1.15: ISSUE: authtime 1425601734, etypes {rep=18 > tkt=18 ses=18}, host/dmfedora.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL > Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): TGS_REQ (6 etypes {18 > 17 16 23 25 26}) 10.1.1.15: ISSUE: authtime 1425601734, etypes {rep=18 > tkt=18 ses=18}, host/dmfedora.rez.lcl at REZ.LCL for > ldap/vader.rez.lcl at REZ.LCL > Mar 05 18:29:20 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.1.15: NEEDED_PREAUTH: admin at REZ.LCL for > krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required > Mar 05 18:29:25 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.1.15: ISSUE: authtime 1425601765, etypes {rep=18 > tkt=18 ses=18}, admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL > Mar 05 18:29:26 vader.rez.lcl krb5kdc[1073](info): DISPATCH: repeated > (retransmitted?) request from 10.1.1.15, resending previous response > Mar 05 18:29:26 vader.rez.lcl krb5kdc[1073](info): closing down fd 12 > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: HTTP/vader.rez.lcl at REZ.LCL for > krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425601784, etypes {rep=18 tkt=18 > ses=18}, HTTP/vader.rez.lcl at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.0.1: NEEDED_PREAUTH: admin at REZ.LCL for > krbtgt/REZ.LCL at REZ.LCL, Additional pre-authentication required > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 etypes {18 17 > 16 23 25 26}) 10.1.0.1: ISSUE: authtime 1425601784, etypes {rep=18 tkt=18 > ses=18}, admin at REZ.LCL for krbtgt/REZ.LCL at REZ.LCL > Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): TGS_REQ (6 etypes {18 > 17 16 23 25 26}) 10.1.1.15: ISSUE: authtime 1425601765, etypes {rep=18 > tkt=18 ses=18}, admin at REZ.LCL for HTTP/vader.rez.lcl at REZ.LCL > > > One thing I did determine is the authtime in the krb5kdc log is epoch > time. I checked it, and it translates directly to the standard time. > > Dan > > > Hm. OK. > > I do not think there was ever mentioned which version of the server and > client you are running but based on the UI it seems like the latest. > Also you are trying to log in after using kinit. Can you log using forms > based authentication or it does not work too? > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > I can't seem to locate the form based authentication for 4.1.2-1 - I was going to try that in order to add the information to this thread, but I can find no reference as to where it is and I can't find it manually on the file system. Can you give me the default URL for it? freeipa-server-4.1.2-1.fc21.x86_64 freeipa-client-4.1.2-1.fc21.x86_64 Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 6 01:21:19 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Mar 2015 20:21:19 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> Message-ID: <54F9010F.7040507@redhat.com> On 03/05/2015 08:09 PM, Dan Mossor wrote: > > > On Thu, Mar 5, 2015 at 6:44 PM, Dmitri Pal > wrote: > > On 03/05/2015 07:36 PM, Dan Mossor wrote: >> On Thu, Mar 5, 2015 at 5:17 PM, Dan Mossor > > wrote: >> >> >> >> On Thu, Mar 5, 2015 at 4:55 PM, Dmitri Pal > > wrote: >> >> On 03/05/2015 05:51 PM, Dan Mossor wrote: >>> As an additional test, I created a new user on my >>> workstation and switched to it. the first thing I did >>> was kinit as admin, then started Firefox, went through >>> the browser configuration provided by the IPA server, >>> and attempted to log in. I received the same error[1]. >>> >>> [1]http://i.imgur.com/mhX86Ng.png >>> >>> >> Have you checked times and time zones on the client and >> on the server? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> >> The server is set for GMT time, whereas the client is set for >> local time, US Central Standard Time. Except for that >> difference, they are within 1 second of each other. >> >> Dan >> >> As an experiment after this email exchange, I switched the server >> to Central Standard Time using timedatctl. I then ran kinit >> again, and attempted to log into the GUI. There was no change - I >> still cannot access the GUI. Here is the krb5kdc.log from the period: >> >> Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.1.15 : >> NEEDED_PREAUTH: host/dmfedora.rez.lcl at REZ.LCL >> for krbtgt/REZ.LCL at REZ.LCL >> , Additional pre-authentication >> required >> Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.1.15 : ISSUE: >> authtime 1425601734, etypes {rep=18 tkt=18 ses=18}, >> host/dmfedora.rez.lcl at REZ.LCL >> for krbtgt/REZ.LCL at REZ.LCL >> >> Mar 06 00:28:54 vader.rez.lcl krb5kdc[1073](info): TGS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.1.15 : ISSUE: >> authtime 1425601734, etypes {rep=18 tkt=18 ses=18}, >> host/dmfedora.rez.lcl at REZ.LCL >> for >> ldap/vader.rez.lcl at REZ.LCL >> Mar 05 18:29:20 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.1.15 : >> NEEDED_PREAUTH: admin at REZ.LCL for >> krbtgt/REZ.LCL at REZ.LCL , >> Additional pre-authentication required >> Mar 05 18:29:25 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.1.15 : ISSUE: >> authtime 1425601765, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL >> for krbtgt/REZ.LCL at REZ.LCL >> >> Mar 05 18:29:26 vader.rez.lcl krb5kdc[1073](info): DISPATCH: >> repeated (retransmitted?) request from 10.1.1.15, resending >> previous response >> Mar 05 18:29:26 vader.rez.lcl krb5kdc[1073](info): closing down fd 12 >> Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.0.1 : >> NEEDED_PREAUTH: HTTP/vader.rez.lcl at REZ.LCL >> for krbtgt/REZ.LCL at REZ.LCL >> , Additional pre-authentication >> required >> Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.0.1 : ISSUE: >> authtime 1425601784, etypes {rep=18 tkt=18 ses=18}, >> HTTP/vader.rez.lcl at REZ.LCL >> for krbtgt/REZ.LCL at REZ.LCL >> Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.0.1 : >> NEEDED_PREAUTH: admin at REZ.LCL for >> krbtgt/REZ.LCL at REZ.LCL , >> Additional pre-authentication required >> Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.0.1 : ISSUE: >> authtime 1425601784, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL >> for krbtgt/REZ.LCL at REZ.LCL >> >> Mar 05 18:29:44 vader.rez.lcl krb5kdc[1073](info): TGS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.1.1.15 : ISSUE: >> authtime 1425601765, etypes {rep=18 tkt=18 ses=18}, admin at REZ.LCL >> for HTTP/vader.rez.lcl at REZ.LCL >> >> >> >> One thing I did determine is the authtime in the krb5kdc log is >> epoch time. I checked it, and it translates directly to the >> standard time. >> >> Dan > > Hm. OK. > > I do not think there was ever mentioned which version of the > server and client you are running but based on the UI it seems > like the latest. > Also you are trying to log in after using kinit. Can you log using > forms based authentication or it does not work too? > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > I can't seem to locate the form based authentication for 4.1.2-1 - I > was going to try that in order to add the information to this thread, > but I can find no reference as to where it is and I can't find it > manually on the file system. Can you give me the default URL for it? > > freeipa-server-4.1.2-1.fc21.x86_64 > freeipa-client-4.1.2-1.fc21.x86_64 > > Dan http://i.imgur.com/mhX86Ng.png It should show up if you do not have a ticket. Destroy the ticket on the client and try to access the server via browser, you should be redirected. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From reesb at hushmail.com Fri Mar 6 01:24:38 2015 From: reesb at hushmail.com (reesb at hushmail.com) Date: Fri, 06 Mar 2015 09:24:38 +0800 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <54F8255E.4000401@redhat.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> <20150305081603.64785C043C@smtp.hushmail.com> <54F8255E.4000401@redhat.com> Message-ID: <20150306012439.1D96BC043C@smtp.hushmail.com> Just to confirm I should restart the server after i've run the ldapmodify? Also I've used ldap modify to remove the 'uniqueMember' object class from the compat schema and added the 'sn=%{sn}' attribute and I still am having no luck. I get the same 'identity source may be malfunctioning error' from vpshere. On 3/5/2015 at 5:44 PM, "Martin Kosek" wrote: > >Thanks. The configuration looks OK, I wonder why the uniqueMember >is not >generated for your compat groups - it works on my FreeIPA 4.1.3 >server. > >Did you restart the Directory Server after you changed the Schema >Compatibility >plugin? > >On 03/05/2015 09:16 AM, reesb at hushmail.com wrote: >> Ok here is the search result; >> # ldapsearch -x -D "cn=Directory Manager" -W -b "cn=config" >cn=groups >> Enter LDAP Password: >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: cn=groups >> # requesting: ALL >> # >> >> # groups, Schema Compatibility, plugins, config >> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >> cn: groups >> objectClass: top >> objectClass: extensibleObject >> schema-compat-container-group: cn=compat, dc=localdomain,dc=local >> schema-compat-search-filter: objectclass=posixGroup >> schema-compat-container-rdn: cn=groups >> schema-compat-entry-rdn: cn=%{cn} >> schema-compat-search-base: cn=groups, cn=accounts, >dc=localdomain,dc=local >> schema-compat-entry-attribute: >%ifeq("ipaanchoruuid","%{ipaanchoruuid}","objec >> tclass=ipaOverrideTarget","") >> schema-compat-entry-attribute: gidNumber=%{gidNumber} >> schema-compat-entry-attribute: memberUid=%deref_r("member","uid") >> schema-compat-entry-attribute: >%ifeq("ipauniqueid","%{ipauniqueid}","ipaanchor >> uuid=:IPA:cloud.local:%{ipauniqueid}","") >> schema-compat-entry-attribute: memberUid=%{memberUid} >> schema-compat-entry-attribute: >%ifeq("ipauniqueid","%{ipauniqueid}","objectcla >> ss=ipaOverrideTarget","") >> schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} >> schema-compat-entry-attribute: objectclass=posixGroup >> schema-compat-entry-attribute: objectclass=groupOfUniqueNames >> schema-compat-entry-attribute: >uniqueMember=%regsub("%{member}","^(.*)accounts >> (.*)","%1compat%2") >> schema-compat-restrict-subtree: cn=Schema >Compatibility,cn=plugins,cn=config >> schema-compat-restrict-subtree: dc=localdomain,dc=local >> >> # search result >> search: 2 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> On 3/5/2015 at 3:54 PM, "Martin Kosek" wrote: >>> >>> On 03/05/2015 02:37 AM, reesb at hushmail.com wrote: >>>> Opps, I got that wrong, my groups don't show the >'uniqueMember' >>> attribute. Here is an example returned from ldapsearch; >>>> >>>> # admins, groups, compat, localdomain.local >>>> dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local >>>> gidNumber: 756200000 >>>> memberUid: admin >>>> memberUid: vadmin >>>> objectClass: posixGroup >>>> objectClass: groupOfUniqueNames >>>> objectClass: top >>>> cn: admins >>>> >>>> >>>> On 3/5/2015 at 9:15 AM, reesb at hushmail.com wrote: >>>> >>>> Hi Martin, >>>> >>>> Using my vadmin account, >>> "uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local", the >>> search completes successfully and i get a list of my users and >>> groups however when I've watched the ldap queries between >vcenter >>> and freeipa I can see it's applying a filter to the user search >>> looking for 'objectClass=groupOfUniqueNames' which my groups >don't >>> seem to contain. >>>> >>>> >>>> I'm very much an ldap newbie but I thought at step two in the >>> vsphere integration howto I modified the groups schema to >include >>> that object class? >>>> >>>> On 3/4/2015 at 8:32 PM, "Martin Kosek" >wrote: >>>> >>>> Given that this HOWTO does not use the vanilla Schema >>> Compatibility settings >>>> (FreeIPA Compat Tree by default uses posixGroup objectclass >and >>> memberUid >>>> attribute for user membership), I would check if the groups >>> really have the >>>> right objectclass and uniqueMember generated: >>>> >>>> # ldapsearch -D "VSPHERE_DN" -x -w "$VSPHERE_DN_PASSWORD" -b >>>> "cn=groups,cn=compat,dc=localdomain,dc=local" >>>> >>>> I expect there will be some problem preventing the LDAP search >>> to succeed. Then >>>> we would know where to look next. >>>> >>>> Martin >>>> >>> >>> I am also CCing Gialunca who contributed the HOWTO. I checked >it >>> again and >>> tried to apply it on my FreeIPA 4.1.3, my compat group now >contain >>> the proper >>> uniqueMember attribute and groupOfUniqueNames objectclass. >>> >>> I am not sure though why are also users updated (mostly >question >>> to Gialunca): >>> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>> changetype: modify >>> add: schema-compat-entry-attribute >>> schema-compat-entry-attribute: objectclass=uniqueMember >>> - >>> add: schema-compat-entry-attribute >>> schema-compat-entry-attribute: objectclass=inetOrgPerson >>> - >>> >>> For instance, "uniqueMember" is not valid objectclass. Also, if >>> you are adding >>> iNetOrgPerson objectclass, you should have all it's MUST >>> attributes also >>> generated - otherwise consuming programs may break if they >depend >>> on such >>> attributes to exist. I see that "sn" is missing in my compat >user >>> entries. >>> >>> Can you show the "cn=groups,cn=Schema >>> Compatibility,cn=plugins,cn=config" entry >>> so that we can see if the uniqueMember attribute is really >>> configured correctly? >>> >>> Thanks, >>> Martin >> From danofsatx at gmail.com Fri Mar 6 01:38:24 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Thu, 5 Mar 2015 19:38:24 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54F9010F.7040507@redhat.com> References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> Message-ID: On Thu, Mar 5, 2015 at 7:21 PM, Dmitri Pal wrote: > http://i.imgur.com/mhX86Ng.png > > It should show up if you do not have a ticket. Destroy the ticket on the > client and try to access the server via browser, you should be redirected. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > Ok then, that is the page that keeps returning. I've tried from this workstation using Konquerer, which does not support Kerberos, I've from from Internet Explorer on a Windows 7 Professional desktop, and I've tried from a Fedora 21 system that is not enrolled in the domain. I get the exact same response with every attempt. One additional step I attempted to take was to change the admin password on the IPA server. I am getting a ldap_sasl_interactive_bind_s: Unknown authentication method (-6) error back. I think this installation is hosed. I am ready to wipe and start over from scratch tomorrow. I've already wasted 16 hours on it. Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From root at linuxcoding.org Fri Mar 6 03:38:18 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Fri, 06 Mar 2015 10:38:18 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO Message-ID: <54F9212A.4010907@linuxcoding.org> Problems with FreeIPA 4.1.3 for vCenter 5.5u2b SSO, only the admin user can be used and always get an error for other users. -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 10.32.07 AM.png Type: image/png Size: 130580 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 10.32.12 AM.png Type: image/png Size: 174335 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 10.32.51 AM.png Type: image/png Size: 139331 bytes Desc: not available URL: From dpal at redhat.com Fri Mar 6 04:23:16 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 05 Mar 2015 23:23:16 -0500 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9212A.4010907@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> Message-ID: <54F92BB4.6090300@redhat.com> On 03/05/2015 10:38 PM, Herwono W Wijaya wrote: > Problems with FreeIPA 4.1.3 for vCenter 5.5u2b SSO, only the admin > user can be used and always get an error for other users. > > Can you check without full name? It seems like the name is expanded twice. -- 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 Fri Mar 6 07:20:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 08:20:30 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <20150306012439.1D96BC043C@smtp.hushmail.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> <20150305081603.64785C043C@smtp.hushmail.com> <54F8255E.4000401@redhat.com> <20150306012439.1D96BC043C@smtp.hushmail.com> Message-ID: <54F9553E.4050703@redhat.com> On 03/06/2015 02:24 AM, reesb at hushmail.com wrote: > Just to confirm I should restart the server after i've run the ldapmodify? Right. It would be safer thing to do, if you modified the Schema Compatibility config. At least to make sure it re-creates the entries from scratch. > Also I've used ldap modify to remove the 'uniqueMember' object class from the compat schema and added the 'sn=%{sn}' attribute and I still am having no luck. I get the same 'identity source may be malfunctioning error' from vpshere. The key here is to see the Directory Server access log, to see what kind of LDAP searches is vSphere doing and then seeing the actual entries in FreeIPA with ldapsearch (or any GUI, I use Apache Directory Studio). With this knowledge, you should just need to update either the Schema Compatibility plugin configuration or vSphere configuration. Martin > > On 3/5/2015 at 5:44 PM, "Martin Kosek" wrote: >> >> Thanks. The configuration looks OK, I wonder why the uniqueMember >> is not >> generated for your compat groups - it works on my FreeIPA 4.1.3 >> server. >> >> Did you restart the Directory Server after you changed the Schema >> Compatibility >> plugin? >> >> On 03/05/2015 09:16 AM, reesb at hushmail.com wrote: >>> Ok here is the search result; >>> # ldapsearch -x -D "cn=Directory Manager" -W -b "cn=config" >> cn=groups >>> Enter LDAP Password: >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope subtree >>> # filter: cn=groups >>> # requesting: ALL >>> # >>> >>> # groups, Schema Compatibility, plugins, config >>> dn: cn=groups,cn=Schema Compatibility,cn=plugins,cn=config >>> cn: groups >>> objectClass: top >>> objectClass: extensibleObject >>> schema-compat-container-group: cn=compat, dc=localdomain,dc=local >>> schema-compat-search-filter: objectclass=posixGroup >>> schema-compat-container-rdn: cn=groups >>> schema-compat-entry-rdn: cn=%{cn} >>> schema-compat-search-base: cn=groups, cn=accounts, >> dc=localdomain,dc=local >>> schema-compat-entry-attribute: >> %ifeq("ipaanchoruuid","%{ipaanchoruuid}","objec >>> tclass=ipaOverrideTarget","") >>> schema-compat-entry-attribute: gidNumber=%{gidNumber} >>> schema-compat-entry-attribute: memberUid=%deref_r("member","uid") >>> schema-compat-entry-attribute: >> %ifeq("ipauniqueid","%{ipauniqueid}","ipaanchor >>> uuid=:IPA:cloud.local:%{ipauniqueid}","") >>> schema-compat-entry-attribute: memberUid=%{memberUid} >>> schema-compat-entry-attribute: >> %ifeq("ipauniqueid","%{ipauniqueid}","objectcla >>> ss=ipaOverrideTarget","") >>> schema-compat-entry-attribute: ipaanchoruuid=%{ipaanchoruuid} >>> schema-compat-entry-attribute: objectclass=posixGroup >>> schema-compat-entry-attribute: objectclass=groupOfUniqueNames >>> schema-compat-entry-attribute: >> uniqueMember=%regsub("%{member}","^(.*)accounts >>> (.*)","%1compat%2") >>> schema-compat-restrict-subtree: cn=Schema >> Compatibility,cn=plugins,cn=config >>> schema-compat-restrict-subtree: dc=localdomain,dc=local >>> >>> # search result >>> search: 2 >>> result: 0 Success >>> >>> # numResponses: 2 >>> # numEntries: 1 >>> >>> On 3/5/2015 at 3:54 PM, "Martin Kosek" wrote: >>>> >>>> On 03/05/2015 02:37 AM, reesb at hushmail.com wrote: >>>>> Opps, I got that wrong, my groups don't show the >> 'uniqueMember' >>>> attribute. Here is an example returned from ldapsearch; >>>>> >>>>> # admins, groups, compat, localdomain.local >>>>> dn: cn=admins,cn=groups,cn=compat,dc=localdomain,dc=local >>>>> gidNumber: 756200000 >>>>> memberUid: admin >>>>> memberUid: vadmin >>>>> objectClass: posixGroup >>>>> objectClass: groupOfUniqueNames >>>>> objectClass: top >>>>> cn: admins >>>>> >>>>> >>>>> On 3/5/2015 at 9:15 AM, reesb at hushmail.com wrote: >>>>> >>>>> Hi Martin, >>>>> >>>>> Using my vadmin account, >>>> "uid=vadmin,cn=users,cn=compat,dc=localdomain,dc=local", the >>>> search completes successfully and i get a list of my users and >>>> groups however when I've watched the ldap queries between >> vcenter >>>> and freeipa I can see it's applying a filter to the user search >>>> looking for 'objectClass=groupOfUniqueNames' which my groups >> don't >>>> seem to contain. >>>>> >>>>> >>>>> I'm very much an ldap newbie but I thought at step two in the >>>> vsphere integration howto I modified the groups schema to >> include >>>> that object class? >>>>> >>>>> On 3/4/2015 at 8:32 PM, "Martin Kosek" >> wrote: >>>>> >>>>> Given that this HOWTO does not use the vanilla Schema >>>> Compatibility settings >>>>> (FreeIPA Compat Tree by default uses posixGroup objectclass >> and >>>> memberUid >>>>> attribute for user membership), I would check if the groups >>>> really have the >>>>> right objectclass and uniqueMember generated: >>>>> >>>>> # ldapsearch -D "VSPHERE_DN" -x -w "$VSPHERE_DN_PASSWORD" -b >>>>> "cn=groups,cn=compat,dc=localdomain,dc=local" >>>>> >>>>> I expect there will be some problem preventing the LDAP search >>>> to succeed. Then >>>>> we would know where to look next. >>>>> >>>>> Martin >>>>> >>>> >>>> I am also CCing Gialunca who contributed the HOWTO. I checked >> it >>>> again and >>>> tried to apply it on my FreeIPA 4.1.3, my compat group now >> contain >>>> the proper >>>> uniqueMember attribute and groupOfUniqueNames objectclass. >>>> >>>> I am not sure though why are also users updated (mostly >> question >>>> to Gialunca): >>>> dn: cn=users,cn=Schema Compatibility,cn=plugins,cn=config >>>> changetype: modify >>>> add: schema-compat-entry-attribute >>>> schema-compat-entry-attribute: objectclass=uniqueMember >>>> - >>>> add: schema-compat-entry-attribute >>>> schema-compat-entry-attribute: objectclass=inetOrgPerson >>>> - >>>> >>>> For instance, "uniqueMember" is not valid objectclass. Also, if >>>> you are adding >>>> iNetOrgPerson objectclass, you should have all it's MUST >>>> attributes also >>>> generated - otherwise consuming programs may break if they >> depend >>>> on such >>>> attributes to exist. I see that "sn" is missing in my compat >> user >>>> entries. >>>> >>>> Can you show the "cn=groups,cn=Schema >>>> Compatibility,cn=plugins,cn=config" entry >>>> so that we can see if the uniqueMember attribute is really >>>> configured correctly? >>>> >>>> Thanks, >>>> Martin >>> > From mkosek at redhat.com Fri Mar 6 07:28:48 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 08:28:48 +0100 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> Message-ID: <54F95730.40408@redhat.com> On 03/06/2015 02:38 AM, Dan Mossor wrote: > > > On Thu, Mar 5, 2015 at 7:21 PM, Dmitri Pal > wrote: > > http://i.imgur.com/mhX86Ng.png > > It should show up if you do not have a ticket. Destroy the ticket on the > client and try to access the server via browser, you should be redirected. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > Ok then, that is the page that keeps returning. I've tried from this > workstation using Konquerer, which does not support Kerberos, I've from from > Internet Explorer on a Windows 7 Professional desktop, and I've tried from a > Fedora 21 system that is not enrolled in the domain. I get the exact same > response with every attempt. > > One additional step I attempted to take was to change the admin password on the > IPA server. I am getting a ldap_sasl_interactive_bind_s: Unknown authentication > method (-6) error back. > > I think this installation is hosed. I am ready to wipe and start over from > scratch tomorrow. I've already wasted 16 hours on it. Sorry to hear that. But I think you should start taking gradual steps in your testing and trying to make Web UI over GSSAPI work. I would suggest this procedure: 1) Can I "kinit admin" and run CLI command ("ipa user-show admin")? If yes, basic FreeIPA is functioning. Run kdestroy to get rid of Kerberos. 2) Can I login with form basic auth to my FreeIPA? If not, did you verify all the items in http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI ? Did you try logging with form based auth in FreeIPA public demo for example (user "admin", password "Secret123"): https://ipa.demo1.freeipa.org/ipa/ui/ If not, we can dig further. If yes, you can continue with kinit + SSO for the Web UI. From abokovoy at redhat.com Fri Mar 6 07:31:19 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Mar 2015 09:31:19 +0200 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <20150305062644.GI25455@redhat.com> <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> <20150305191343.GQ25455@redhat.com> <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> Message-ID: <20150306073119.GR25455@redhat.com> On Thu, 05 Mar 2015, nathan at nathanpeters.com wrote: >Ok, I sort of have this working now, but there are still some loose ends. >Comments inline > >>>> 2. Setup Solaris properly >>>> NS_LDAP_AUTH=tls:simple >>>> NS_LDAP_CREDENTIAL_LEVEL=proxy >>>> NS_LDAP_BINDDN=uid=solaris,cn=sysaccounts,cn=etc,dc=ipacloud,dc=test >>>> NS_LDAP_BINDPASSWD=ohaimakethissimethingtoughtobreak >>>> NS_LDAP_CACHETTL=0 >>>> NS_LDAP_HOST_CERTPATH=/var/ldap > >When I added NS_LDAP_HOST_CERTPATH to the ldap_client_file it complained >about that particular setting being invalid. I think that setting doesn't >exist on Solaris 10? I had to remove that line. Perhaps it always defaults to /var/ldap. >>>Is that functionally equivalent to what you were trying to do with the >>>cert database or were you trying to do something different? >> More or less -- create an NSS database and add a CA cert there. > >OK, great, I think the manual copy worked. The reason is because if I >delete those 2 .db files I get the following log entries: > >[ID 293258 daemon.warning] libsldap: Status: 91 Mesg: createTLSSession: >failed to initialize TLS security (security library: bad database.) >[ID 545954 daemon.error] libsldap: makeConnection: failed to open >connection to ipadc1.ipadomain.net >[ID 687686 daemon.warning] libsldap: Falling back to anonymous, non-SSL >mode for __ns_ldap_getRootDSE. createTLSSession: failed to initialize TLS >security (security library: bad database.) > >But if those 2 files I manually copied exist, then those messages don't >happen. Good. > >Also, FYI, certutil is not really supported on Solaris 10. Any download >links to that program are now 404. It wasn't included in the Solaris 10 >cd either. See Rob's answer, I'm pretty sure there is a package somewhere that allows to manipulate these databases or otherwise they wouldn't be used by the system tools. >OK, I have added the following 2 lines to my pam.conf file and I can now >authenticate AD users: >other auth sufficient pam_ldap.so.1 >other account required pam_ldap.so.1 > >However, I had to use a slighly different setting when initiating ldap >client: > >ldapclient manual -a credentialLevel=proxy -a authenticationMethod=simple > >Note that if I chose tls:simple, the bind failed and I received the >following log entries : >Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net >ldap_cachemgr[650]: [ID 293258 daemon.warning] libsldap: Status: 81 Mesg: >openConnection: simple bind failed - Can't contact LDAP server >Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net >ldap_cachemgr[650]: [ID 545954 daemon.error] libsldap: makeConnection: >failed to open connection to ipadc1.ipadomain.net >Mar 5 13:07:21 ipaclient6-sandbox-atdev-van.ipadomain.net >ldap_cachemgr[650]: [ID 687686 daemon.warning] libsldap: Falling back to >anonymous, non-SSL mode for __ns_ldap_getRootDSE. openConnection: simple >bind failed - Can't contact LDAP server > >So... any ideas why I could bind 'simple' but not 'tls:simple' ? Perhaps tls:simple requires LDAPS (636) connection? "Can't contact LDAP server" sounds like inability to reach a port on IPA master. Do you have it open in your firewall? -- / Alexander Bokovoy From mkosek at redhat.com Fri Mar 6 07:34:13 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 08:34:13 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9212A.4010907@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> Message-ID: <54F95875.10007@redhat.com> On 03/06/2015 04:38 AM, Herwono W Wijaya wrote: > Problems with FreeIPA 4.1.3 for vCenter 5.5u2b SSO, only the admin user can be > used and always get an error for other users. You mean admin user from vCenter, not admin user from FreeIPA, right? Did you follow this HOWTO: http://www.freeipa.org/page/HowTo/vsphere5_integration Note that the vSphere integration topic is being discussed this week, CCing also Gialunca (author of the HOWTO), he may have some ideas where the problem is too. Martin From abokovoy at redhat.com Fri Mar 6 07:35:57 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 6 Mar 2015 09:35:57 +0200 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <54F9553E.4050703@redhat.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> <20150305081603.64785C043C@smtp.hushmail.com> <54F8255E.4000401@redhat.com> <20150306012439.1D96BC043C@smtp.hushmail.com> <54F9553E.4050703@redhat.com> Message-ID: <20150306073557.GS25455@redhat.com> On Fri, 06 Mar 2015, Martin Kosek wrote: >On 03/06/2015 02:24 AM, reesb at hushmail.com wrote: >>Just to confirm I should restart the server after i've run the ldapmodify? > >Right. It would be safer thing to do, if you modified the Schema >Compatibility config. At least to make sure it re-creates the entries >from scratch. > >>Also I've used ldap modify to remove the 'uniqueMember' object class from the compat schema and added the 'sn=%{sn}' attribute and I still am having no luck. I get the same 'identity source may be malfunctioning error' from vpshere. > >The key here is to see the Directory Server access log, to see what >kind of LDAP searches is vSphere doing and then seeing the actual >entries in FreeIPA with ldapsearch (or any GUI, I use Apache Directory >Studio). With this knowledge, you should just need to update either >the Schema Compatibility plugin configuration or vSphere >configuration. Note also that in 4.1 we have ACIs that only give access to certain attributes within compat tree and not all of them. Adding a new attribute requires to add an ACI to allow serving it. If this is an issue, you'd see the difference when accessing as cn=Directory Manager or as any other authenticated bind. -- / Alexander Bokovoy From mkosek at redhat.com Fri Mar 6 07:44:54 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 08:44:54 +0100 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <20150306073557.GS25455@redhat.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> <20150305081603.64785C043C@smtp.hushmail.com> <54F8255E.4000401@redhat.com> <20150306012439.1D96BC043C@smtp.hushmail.com> <54F9553E.4050703@redhat.com> <20150306073557.GS25455@redhat.com> Message-ID: <54F95AF6.7010604@redhat.com> On 03/06/2015 08:35 AM, Alexander Bokovoy wrote: > On Fri, 06 Mar 2015, Martin Kosek wrote: >> On 03/06/2015 02:24 AM, reesb at hushmail.com wrote: >>> Just to confirm I should restart the server after i've run the ldapmodify? >> >> Right. It would be safer thing to do, if you modified the Schema >> Compatibility config. At least to make sure it re-creates the entries from >> scratch. >> >>> Also I've used ldap modify to remove the 'uniqueMember' object class from >>> the compat schema and added the 'sn=%{sn}' attribute and I still am having >>> no luck. I get the same 'identity source may be malfunctioning error' from >>> vpshere. >> >> The key here is to see the Directory Server access log, to see what kind of >> LDAP searches is vSphere doing and then seeing the actual entries in FreeIPA >> with ldapsearch (or any GUI, I use Apache Directory Studio). With this >> knowledge, you should just need to update either the Schema Compatibility >> plugin configuration or vSphere configuration. > Note also that in 4.1 we have ACIs that only give access to certain > attributes within compat tree and not all of them. Adding a new > attribute requires to add an ACI to allow serving it. > > If this is an issue, you'd see the difference when accessing as > cn=Directory Manager or as any other authenticated bind. Very good point Alexander! I unfortunately did my tests either as admin or DM. I updated the HOWTO with the new step that fixed it for me. http://www.freeipa.org/page/HowTo/vsphere5_integration#Permission_Update So reesb, after the update above, you should get it working. Martin From andrew.holway at gmail.com Fri Mar 6 08:15:44 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 6 Mar 2015 09:15:44 +0100 Subject: [Freeipa-users] Freeipa and dns In-Reply-To: <54F8D2C8.8090800@redhat.com> References: <54F8D2C8.8090800@redhat.com> Message-ID: > > > FreeIPA does not support DNS sites yet. > > https://fedorahosted.org/freeipa/ticket/2008 > > https://fedorahosted.org/bind-dyndb-ldap/ticket/126 > > > > It is in plans for the next release but as a stretch goal. > > > For now the work around would be to have an explicit set of servers > configured on the clients. You will loose a bit of agility if you plan to > deploy replicas dynamically but if you do not plan to do that static server > list might be a work around for now. > That's actually not too much trouble with our configuration management system. Thanks, Andrew > > > Thanks, > > Andrew > > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Fri Mar 6 08:34:41 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 6 Mar 2015 09:34:41 +0100 Subject: [Freeipa-users] verified certificates both sides of a TLS channel Message-ID: Hi, Were using rabbitmq to shunt bits of data around various systems to provide better security we would like all of our acmq connections to be authenticated and encrypted. I'm looking for appropriate documentation or some friendly guidance of how server to server SSL authentication is done with freeipa and if indeed this is the best way to ensure privacy in such scenarios. Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianluca.cecchi at gmail.com Fri Mar 6 08:37:39 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 6 Mar 2015 09:37:39 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F95875.10007@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 8:34 AM, Martin Kosek wrote: > On 03/06/2015 04:38 AM, Herwono W Wijaya wrote: > >> Problems with FreeIPA 4.1.3 for vCenter 5.5u2b SSO, only the admin user >> can be >> used and always get an error for other users. >> > > You mean admin user from vCenter, not admin user from FreeIPA, right? > > Did you follow this HOWTO: > http://www.freeipa.org/page/HowTo/vsphere5_integration > > Note that the vSphere integration topic is being discussed this week, > CCing also Gialunca (author of the HOWTO), he may have some ideas where the > problem is too. > > Martin > The logs that let us know the kind of queries generated b vSPhere are in /var/log/dirsrv/slapd-REALM-NAME/ (at least for 3.3.3) Also, searching through my e-mails I found one direct contact using vSphere 5.5 and that was doing some tests with VMware support connected to his systems. It seems they found out that it almost all worked correctly when using accounts instead of compat BUT you can't log in. An action was the to add objectclass=groupOfUniqueNames to a single test group and they were able to login I asked more information about his setup if still in place and to eventually share with others. Stay tuned... Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Fri Mar 6 08:56:36 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 6 Mar 2015 09:56:36 +0100 Subject: [Freeipa-users] Freeipa and dns In-Reply-To: References: <54F8D2C8.8090800@redhat.com> Message-ID: <20150306085636.GH26395@redhat.com> On Fri, Mar 06, 2015 at 09:15:44AM +0100, Andrew Holway wrote: > > > > For now the work around would be to have an explicit set of servers > > configured on the clients. You will loose a bit of agility if you plan to > > deploy replicas dynamically but if you do not plan to do that static server > > list might be a work around for now. > > That's actually not too much trouble with our configuration management > system. Then ipa_server = local-geo-replica.example.com, _srv_ in sssd.conf is probably the best approach. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Fri Mar 6 09:32:16 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 10:32:16 +0100 Subject: [Freeipa-users] verified certificates both sides of a TLS channel In-Reply-To: References: Message-ID: <54F97420.6020601@redhat.com> On 03/06/2015 09:34 AM, Andrew Holway wrote: > Hi, > > Were using rabbitmq to shunt bits of data around various systems to provide > better security we would like all of our acmq connections to be authenticated > and encrypted. > > I'm looking for appropriate documentation or some friendly guidance of how > server to server SSL authentication is done with freeipa and if indeed this is > the best way to ensure privacy in such scenarios. These are the best documentation sources I could find: Creating certs for FreeIPA hosts: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/host-certificates.html Creating certs for FreeIPA hosts: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html With these certificates, you would need to manually configure SSL-based authentication with mod_ssl/mod_nss. Partially related user howto is http://www.freeipa.org/page/Apache_SNI_With_Kerberos I wonder if RabbitMQ has GSSAPI support, that would be more easy to configure with FreeIPA than SSL certs. Btw FreeIPA 4.2 plans to have much better support for different cert profiles or sub-CAs that you may later use for purposes like this one. Ticket: https://fedorahosted.org/freeipa/ticket/57 CCing Fraser from Dogtag team for reference. Martin From roberto.cornacchia at gmail.com Fri Mar 6 09:56:09 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 6 Mar 2015 10:56:09 +0100 Subject: [Freeipa-users] Synology DSM5 and freeIPA Message-ID: Hi there, I'm planning to deploy freeIPA on our lan. It's small-ish and completely based on FC21, so I expect everything to work like a charm. Except one detail. We have Synology NAS station, which uses DSM 5.0. The ideal plan is to use it as host for shared NFS home dirs once we switch our desktops to freeIPA. I've already tried on a VirtualBox replica of our lan how to configure the Synology station against freeIPA. LDAP enrolling worked, and I created a srv entry in the freeIPA dns, but I didn't go further than that. SSSD does not seem to exist for DSM 5. What are the implications? Can it do without? I understood SSSD works as a caching system, so that the machine keeps working when freeIPA is unavailable. Does it have any other vital role? Thanks for your input. Roberto PS. This mailing list is pleasantly active. Keep up the good work! -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Mar 6 10:15:22 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 11:15:22 +0100 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: References: Message-ID: <54F97E3A.6090803@redhat.com> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: > Hi there, > > I'm planning to deploy freeIPA on our lan. > It's small-ish and completely based on FC21, so I expect everything to work > like a charm. > > Except one detail. We have Synology NAS station, which uses DSM 5.0. > The ideal plan is to use it as host for shared NFS home dirs once we switch our > desktops to freeIPA. Great! > I've already tried on a VirtualBox replica of our lan how to configure the > Synology station against freeIPA. > LDAP enrolling worked, and I created a srv entry in the freeIPA dns, but I > didn't go further than that. > > SSSD does not seem to exist for DSM 5. What are the implications? Can it do > without? I understood SSSD works as a caching system, so that the machine keeps > working when freeIPA is unavailable. Does it have any other vital role? It depends what you want to achieve. I do not know what client DSM users (nss_ldap?), but I assume it should be able to at least do UID/GID translation, using FreeIPA server. nss_ldap is sufficient for the task. SSSD 1.12 has for example CIFS client, that may be useful NFS as well. (See ticket https://fedorahosted.org/sssd/ticket/1534). CCing Jakub from SSSD team for further reference. > Thanks for your input. > > Roberto > > PS. This mailing list is pleasantly active. Keep up the good work! Thanks, you too! :-) Martin From jhrozek at redhat.com Fri Mar 6 10:39:03 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 6 Mar 2015 11:39:03 +0100 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: References: Message-ID: <20150306103903.GJ3978@hendrix.redhat.com> On Fri, Mar 06, 2015 at 10:56:09AM +0100, Roberto Cornacchia wrote: > Hi there, > > I'm planning to deploy freeIPA on our lan. > It's small-ish and completely based on FC21, so I expect everything to work > like a charm. > > Except one detail. We have Synology NAS station, which uses DSM 5.0. > The ideal plan is to use it as host for shared NFS home dirs once we switch > our desktops to freeIPA. > > I've already tried on a VirtualBox replica of our lan how to configure the > Synology station against freeIPA. > LDAP enrolling worked, and I created a srv entry in the freeIPA dns, but I > didn't go further than that. > > SSSD does not seem to exist for DSM 5. What are the implications? Can it do > without? I understood SSSD works as a caching system, so that the machine > keeps working when freeIPA is unavailable. Yes, I think you should configure the regular LDAP and/or Kerberos authentication. > Does it have any other vital > role? HBAC access control enforcement and setting the SELinux labels. The latter is not really possible on Synology anyway. > > Thanks for your input. > > Roberto > > PS. This mailing list is pleasantly active. Keep up the good work! thank you very much, it would be awesome if you could contribute a HOWTO to freeipa.org.. (I'm a bit selfish here because I also run a Synology NAS at home :-)) From root at linuxcoding.org Fri Mar 6 11:11:37 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Fri, 06 Mar 2015 18:11:37 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> Message-ID: <54F98B69.306@linuxcoding.org> Now all works well, I use another method *FreeIPA:** **Users:* - admin - herwono (member of "ssogroups" group) - vcadmin (member of "ssogroups" group) *Group**s:** **Only one group for vCenter SSO.* - ssogroups *Modif "ssogroups" using ldif file* 
dn: cn=ssogroups,cn=groups,cn=accounts,dc=server,dc=local
changetype: modify
add: objectClass
objectClass: groupOfUniqueNames
-
add: uniqueMember
uniqueMember: uid=herwono,cn=users,cn=accounts,dc=server,dc=local
uniqueMember: uid=vcadmin,cn=users,cn=accounts,dc=server,dc=local
-
*vCenter Identity Source Config:* Name: IPA Base DN for users: cn=users,cn=accounts,dc=server,dc=local Domain name: server.local Base DN for groups: cn=groups,cn=accounts,dc=server,dc=local Primary server url: ldap://identity.server.local:389 Username: uid=admin,cn=users,cn=accounts,dc=server,dc=local Password: ****** *FreeIPA users and groups for vCenter with Administrator permission:* User: herwono (SERVER.LOCAL\herwono) Group: ssogroups (SERVER.LOCAL\ssogroups) On 3/6/15 3:37 PM, Gianluca Cecchi wrote: > On Fri, Mar 6, 2015 at 8:34 AM, Martin Kosek > wrote: > > On 03/06/2015 04:38 AM, Herwono W Wijaya wrote: > > Problems with FreeIPA 4.1.3 for vCenter 5.5u2b SSO, only the > admin user can be > used and always get an error for other users. > > > You mean admin user from vCenter, not admin user from FreeIPA, right? > > Did you follow this HOWTO: > http://www.freeipa.org/page/HowTo/vsphere5_integration > > Note that the vSphere integration topic is being discussed this > week, CCing also Gialunca (author of the HOWTO), he may have some > ideas where the problem is too. > > Martin > > > > The logs that let us know the kind of queries generated b vSPhere are in > /var/log/dirsrv/slapd-REALM-NAME/ > (at least for 3.3.3) > > Also, searching through my e-mails I found one direct contact using > vSphere 5.5 and that was doing some tests with VMware support > connected to his systems. > It seems they found out that it almost all worked correctly when using > accounts instead of compat BUT > you can't log in. > > An action was the to add objectclass=groupOfUniqueNames to a single > test group and they were able to login > > I asked more information about his setup if still in place and to > eventually share with others. > > Stay tuned... > > Gianluca -- Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 5.22.06 PM.png Type: image/png Size: 304114 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 5.26.45 PM.png Type: image/png Size: 145491 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 5.27.09 PM.png Type: image/png Size: 283494 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 5.27.31 PM.png Type: image/png Size: 214276 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 5.27.46 PM.png Type: image/png Size: 245207 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: Screen Shot 2015-03-06 at 6.05.33 PM.png Type: image/png Size: 421175 bytes Desc: not available URL: From dpal at redhat.com Fri Mar 6 12:16:57 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Mar 2015 07:16:57 -0500 Subject: [Freeipa-users] verified certificates both sides of a TLS channel In-Reply-To: <54F97420.6020601@redhat.com> References: <54F97420.6020601@redhat.com> Message-ID: <54F99AB9.6050809@redhat.com> On 03/06/2015 04:32 AM, Martin Kosek wrote: > On 03/06/2015 09:34 AM, Andrew Holway wrote: >> Hi, >> >> Were using rabbitmq to shunt bits of data around various systems to >> provide >> better security we would like all of our acmq connections to be >> authenticated >> and encrypted. >> >> I'm looking for appropriate documentation or some friendly guidance >> of how >> server to server SSL authentication is done with freeipa and if >> indeed this is >> the best way to ensure privacy in such scenarios. > > These are the best documentation sources I could find: > > Creating certs for FreeIPA hosts: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/host-certificates.html > > Creating certs for FreeIPA hosts: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html > > With these certificates, you would need to manually configure > SSL-based authentication with mod_ssl/mod_nss. Partially related user > howto is > http://www.freeipa.org/page/Apache_SNI_With_Kerberos > > I wonder if RabbitMQ has GSSAPI support, that would be more easy to > configure with FreeIPA than SSL certs. > > Btw FreeIPA 4.2 plans to have much better support for different cert > profiles or sub-CAs that you may later use for purposes like this one. > > Ticket: > https://fedorahosted.org/freeipa/ticket/57 > > CCing Fraser from Dogtag team for reference. > > Martin > What we still missing is the client side certs. So AFAIU we would be able to provide certs for one way authentication not two way yet. It is in works. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Fri Mar 6 12:30:11 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 6 Mar 2015 13:30:11 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice Message-ID: Hi, I'm figuring out how to regenerate the webserver certificates so I can use a loadbalancer in front of my ipa servers. I see in the docs there is information about this, but not for the webservice. Does anyone have some directions ? Thanks. Matt From mkosek at redhat.com Fri Mar 6 12:49:23 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 13:49:23 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F98B69.306@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> Message-ID: <54F9A253.2090403@redhat.com> I am glad you have it working. However, I would like to discourage from this another method as this way, you would need to maintain uniqueMember attribute yourself. FreeIPA only maintains the "member" attribute. I would recommend using the Gianluca's method in http://www.freeipa.org/page/HowTo/vsphere5_integration with taking users and groups from compat tree. This way, you will have uniqueMember populated when you do changes to the group using FreeIPA CLI or UI. If it was not working for you in the past, note that we identified a change today that needs to be done with FreeIPA 4.0+: http://www.freeipa.org/page/HowTo/vsphere5_integration#Permission_Update Martin On 03/06/2015 12:11 PM, Herwono W Wijaya wrote: > Now all works well, I use another method > > *FreeIPA:** > **Users:* > - admin > - herwono (member of "ssogroups" group) > - vcadmin (member of "ssogroups" group) > > *Group**s:** > **Only one group for vCenter SSO.* > - ssogroups > > *Modif "ssogroups" using ldif file* > 
> dn: cn=ssogroups,cn=groups,cn=accounts,dc=server,dc=local
> changetype: modify
> add: objectClass
> objectClass: groupOfUniqueNames
> -
> add: uniqueMember
> uniqueMember: uid=herwono,cn=users,cn=accounts,dc=server,dc=local
> uniqueMember: uid=vcadmin,cn=users,cn=accounts,dc=server,dc=local
> -
>
> > *vCenter Identity Source Config:* > Name: IPA > Base DN for users: cn=users,cn=accounts,dc=server,dc=local > Domain name: server.local > Base DN for groups: cn=groups,cn=accounts,dc=server,dc=local > Primary server url: ldap://identity.server.local:389 > Username: uid=admin,cn=users,cn=accounts,dc=server,dc=local > Password: ****** > > *FreeIPA users and groups for vCenter with Administrator permission:* > User: herwono (SERVER.LOCAL\herwono) > Group: ssogroups (SERVER.LOCAL\ssogroups) > > > On 3/6/15 3:37 PM, Gianluca Cecchi wrote: >> On Fri, Mar 6, 2015 at 8:34 AM, Martin Kosek > > wrote: >> >> On 03/06/2015 04:38 AM, Herwono W Wijaya wrote: >> >> Problems with FreeIPA 4.1.3 for vCenter 5.5u2b SSO, only the admin >> user can be >> used and always get an error for other users. >> >> >> You mean admin user from vCenter, not admin user from FreeIPA, right? >> >> Did you follow this HOWTO: >> http://www.freeipa.org/page/HowTo/vsphere5_integration >> >> Note that the vSphere integration topic is being discussed this week, >> CCing also Gialunca (author of the HOWTO), he may have some ideas where >> the problem is too. >> >> Martin >> >> >> >> The logs that let us know the kind of queries generated b vSPhere are in >> /var/log/dirsrv/slapd-REALM-NAME/ >> (at least for 3.3.3) >> >> Also, searching through my e-mails I found one direct contact using vSphere >> 5.5 and that was doing some tests with VMware support connected to his systems. >> It seems they found out that it almost all worked correctly when using >> accounts instead of compat BUT >> you can't log in. >> >> An action was the to add objectclass=groupOfUniqueNames to a single test >> group and they were able to login >> >> I asked more information about his setup if still in place and to eventually >> share with others. >> >> Stay tuned... >> >> Gianluca > > -- > Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 > * > From mkosek at redhat.com Fri Mar 6 13:05:09 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 14:05:09 +0100 Subject: [Freeipa-users] verified certificates both sides of a TLS channel In-Reply-To: <54F99AB9.6050809@redhat.com> References: <54F97420.6020601@redhat.com> <54F99AB9.6050809@redhat.com> Message-ID: <54F9A605.5010303@redhat.com> On 03/06/2015 01:16 PM, Dmitri Pal wrote: > On 03/06/2015 04:32 AM, Martin Kosek wrote: >> On 03/06/2015 09:34 AM, Andrew Holway wrote: >>> Hi, >>> >>> Were using rabbitmq to shunt bits of data around various systems to provide >>> better security we would like all of our acmq connections to be authenticated >>> and encrypted. >>> >>> I'm looking for appropriate documentation or some friendly guidance of how >>> server to server SSL authentication is done with freeipa and if indeed this is >>> the best way to ensure privacy in such scenarios. >> >> These are the best documentation sources I could find: >> >> Creating certs for FreeIPA hosts: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/host-certificates.html >> >> >> Creating certs for FreeIPA hosts: >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html >> >> >> With these certificates, you would need to manually configure SSL-based >> authentication with mod_ssl/mod_nss. Partially related user howto is >> http://www.freeipa.org/page/Apache_SNI_With_Kerberos >> >> I wonder if RabbitMQ has GSSAPI support, that would be more easy to configure >> with FreeIPA than SSL certs. >> >> Btw FreeIPA 4.2 plans to have much better support for different cert profiles >> or sub-CAs that you may later use for purposes like this one. >> >> Ticket: >> https://fedorahosted.org/freeipa/ticket/57 >> >> CCing Fraser from Dogtag team for reference. >> >> Martin >> > What we still missing is the client side certs. So AFAIU we would be able to > provide certs for one way authentication not two way yet. > It is in works. Couldn't the authentication be provided with service certs and current default certificate profile? This is the ticket for the client certificate work, it was missing: https://fedorahosted.org/freeipa/ticket/4938 Martin From mkosek at redhat.com Fri Mar 6 13:08:15 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 14:08:15 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: Message-ID: <54F9A6BF.5000306@redhat.com> On 03/06/2015 01:30 PM, Matt . wrote: > Hi, > > I'm figuring out how to regenerate the webserver certificates so I can > use a loadbalancer in front of my ipa servers. > > I see in the docs there is information about this, but not for the > webservice. Does anyone have some directions ? > > Thanks. > > Matt > Certificate SubjectAltName was fixed in FreeIPA 4.0, this is the upstream ticket: https://fedorahosted.org/freeipa/ticket/3977 The procedure is described in upstream wiki for example: http://www.freeipa.org/page/PKI#Automated_certificate_requests_with_Certmonger HTH, Martin From root at linuxcoding.org Fri Mar 6 13:09:05 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Fri, 06 Mar 2015 20:09:05 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9A253.2090403@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> Message-ID: <54F9A6F1.40701@linuxcoding.org> Gianluca's method not working for me, always get this error Error: Idm client exception: control not found and also try using this: http://www.freeipa.org/page/HowTo/vsphere5_integration#Permission_Update On 3/6/15 7:49 PM, Martin Kosek wrote: > I am glad you have it working. However, I would like to discourage > from this another method as this way, you would need to maintain > uniqueMember attribute yourself. FreeIPA only maintains the "member" > attribute. > > I would recommend using the Gianluca's method in > http://www.freeipa.org/page/HowTo/vsphere5_integration > > with taking users and groups from compat tree. This way, you will have > uniqueMember populated when you do changes to the group using FreeIPA > CLI or UI. > > If it was not working for you in the past, note that we identified a > change today that needs to be done with FreeIPA 4.0+: > > http://www.freeipa.org/page/HowTo/vsphere5_integration#Permission_Update > > Martin > > > On 03/06/2015 12:11 PM, Herwono W Wijaya wrote: >> Now all works well, I use another method >> >> *FreeIPA:** >> **Users:* >> - admin >> - herwono (member of "ssogroups" group) >> - vcadmin (member of "ssogroups" group) >> >> *Group**s:** >> **Only one group for vCenter SSO.* >> - ssogroups >> >> *Modif "ssogroups" using ldif file* >> 
>> dn: cn=ssogroups,cn=groups,cn=accounts,dc=server,dc=local
>> changetype: modify
>> add: objectClass
>> objectClass: groupOfUniqueNames
>> -
>> add: uniqueMember
>> uniqueMember: uid=herwono,cn=users,cn=accounts,dc=server,dc=local
>> uniqueMember: uid=vcadmin,cn=users,cn=accounts,dc=server,dc=local
>> -
>>
>> >> *vCenter Identity Source Config:* >> Name: IPA >> Base DN for users: cn=users,cn=accounts,dc=server,dc=local >> Domain name: server.local >> Base DN for groups: cn=groups,cn=accounts,dc=server,dc=local >> Primary server url: ldap://identity.server.local:389 >> Username: uid=admin,cn=users,cn=accounts,dc=server,dc=local >> Password: ****** >> >> *FreeIPA users and groups for vCenter with Administrator permission:* >> User: herwono (SERVER.LOCAL\herwono) >> Group: ssogroups (SERVER.LOCAL\ssogroups) >> >> >> On 3/6/15 3:37 PM, Gianluca Cecchi wrote: >>> On Fri, Mar 6, 2015 at 8:34 AM, Martin Kosek >> > wrote: >>> >>> On 03/06/2015 04:38 AM, Herwono W Wijaya wrote: >>> >>> Problems with FreeIPA 4.1.3 for vCenter 5.5u2b SSO, only the >>> admin >>> user can be >>> used and always get an error for other users. >>> >>> >>> You mean admin user from vCenter, not admin user from FreeIPA, >>> right? >>> >>> Did you follow this HOWTO: >>> http://www.freeipa.org/page/HowTo/vsphere5_integration >>> >>> Note that the vSphere integration topic is being discussed this >>> week, >>> CCing also Gialunca (author of the HOWTO), he may have some >>> ideas where >>> the problem is too. >>> >>> Martin >>> >>> >>> >>> The logs that let us know the kind of queries generated b vSPhere >>> are in >>> /var/log/dirsrv/slapd-REALM-NAME/ >>> (at least for 3.3.3) >>> >>> Also, searching through my e-mails I found one direct contact using >>> vSphere >>> 5.5 and that was doing some tests with VMware support connected to >>> his systems. >>> It seems they found out that it almost all worked correctly when using >>> accounts instead of compat BUT >>> you can't log in. >>> >>> An action was the to add objectclass=groupOfUniqueNames to a single >>> test >>> group and they were able to login >>> >>> I asked more information about his setup if still in place and to >>> eventually >>> share with others. >>> >>> Stay tuned... >>> >>> Gianluca >> >> -- >> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >> 2014, 2015 >> * >> >> > -- Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: error.png Type: image/png Size: 352533 bytes Desc: not available URL: From mkosek at redhat.com Fri Mar 6 13:12:49 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 14:12:49 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9A6F1.40701@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> Message-ID: <54F9A7D1.5000100@redhat.com> Ah, I am not sure what control do they mean. But in general, when, it is always interesting to check the LDAP access logs to see the last failed request and then try the same search with ldapsearch and fix things. Martin On 03/06/2015 02:09 PM, Herwono W Wijaya wrote: > Gianluca's method not working for me, always get this error > > Error: Idm client exception: control not found > > and also try using this: > http://www.freeipa.org/page/HowTo/vsphere5_integration#Permission_Update > > On 3/6/15 7:49 PM, Martin Kosek wrote: >> I am glad you have it working. However, I would like to discourage from this >> another method as this way, you would need to maintain uniqueMember attribute >> yourself. FreeIPA only maintains the "member" attribute. >> >> I would recommend using the Gianluca's method in >> http://www.freeipa.org/page/HowTo/vsphere5_integration >> >> with taking users and groups from compat tree. This way, you will have >> uniqueMember populated when you do changes to the group using FreeIPA CLI or UI. >> >> If it was not working for you in the past, note that we identified a change >> today that needs to be done with FreeIPA 4.0+: >> >> http://www.freeipa.org/page/HowTo/vsphere5_integration#Permission_Update >> >> Martin >> >> >> On 03/06/2015 12:11 PM, Herwono W Wijaya wrote: >>> Now all works well, I use another method >>> >>> *FreeIPA:** >>> **Users:* >>> - admin >>> - herwono (member of "ssogroups" group) >>> - vcadmin (member of "ssogroups" group) >>> >>> *Group**s:** >>> **Only one group for vCenter SSO.* >>> - ssogroups >>> >>> *Modif "ssogroups" using ldif file* >>> 
>>> dn: cn=ssogroups,cn=groups,cn=accounts,dc=server,dc=local
>>> changetype: modify
>>> add: objectClass
>>> objectClass: groupOfUniqueNames
>>> -
>>> add: uniqueMember
>>> uniqueMember: uid=herwono,cn=users,cn=accounts,dc=server,dc=local
>>> uniqueMember: uid=vcadmin,cn=users,cn=accounts,dc=server,dc=local
>>> -
>>>
>>> >>> *vCenter Identity Source Config:* >>> Name: IPA >>> Base DN for users: cn=users,cn=accounts,dc=server,dc=local >>> Domain name: server.local >>> Base DN for groups: cn=groups,cn=accounts,dc=server,dc=local >>> Primary server url: ldap://identity.server.local:389 >>> Username: uid=admin,cn=users,cn=accounts,dc=server,dc=local >>> Password: ****** >>> >>> *FreeIPA users and groups for vCenter with Administrator permission:* >>> User: herwono (SERVER.LOCAL\herwono) >>> Group: ssogroups (SERVER.LOCAL\ssogroups) >>> >>> >>> On 3/6/15 3:37 PM, Gianluca Cecchi wrote: >>>> On Fri, Mar 6, 2015 at 8:34 AM, Martin Kosek >>> > wrote: >>>> >>>> On 03/06/2015 04:38 AM, Herwono W Wijaya wrote: >>>> >>>> Problems with FreeIPA 4.1.3 for vCenter 5.5u2b SSO, only the admin >>>> user can be >>>> used and always get an error for other users. >>>> >>>> >>>> You mean admin user from vCenter, not admin user from FreeIPA, right? >>>> >>>> Did you follow this HOWTO: >>>> http://www.freeipa.org/page/HowTo/vsphere5_integration >>>> >>>> Note that the vSphere integration topic is being discussed this week, >>>> CCing also Gialunca (author of the HOWTO), he may have some ideas where >>>> the problem is too. >>>> >>>> Martin >>>> >>>> >>>> >>>> The logs that let us know the kind of queries generated b vSPhere are in >>>> /var/log/dirsrv/slapd-REALM-NAME/ >>>> (at least for 3.3.3) >>>> >>>> Also, searching through my e-mails I found one direct contact using vSphere >>>> 5.5 and that was doing some tests with VMware support connected to his >>>> systems. >>>> It seems they found out that it almost all worked correctly when using >>>> accounts instead of compat BUT >>>> you can't log in. >>>> >>>> An action was the to add objectclass=groupOfUniqueNames to a single test >>>> group and they were able to login >>>> >>>> I asked more information about his setup if still in place and to eventually >>>> share with others. >>>> >>>> Stay tuned... >>>> >>>> Gianluca >>> >>> -- >>> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 >>> * >>> >>> >> > > -- > Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 > * > From pspacek at redhat.com Fri Mar 6 13:24:31 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 06 Mar 2015 14:24:31 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <54F9A6BF.5000306@redhat.com> References: <54F9A6BF.5000306@redhat.com> Message-ID: <54F9AA8F.6060404@redhat.com> On 6.3.2015 14:08, Martin Kosek wrote: > I'm figuring out how to regenerate the webserver certificates so I can > use a loadbalancer in front of my ipa servers. Are you talking about FreeIPA web interface? It is technically possible to use load-balancer but it will be really hacky. You would have to solve certificates and also distribute shared keytabs and so on. I would recommend you to use "something" which issues HTTP redirect to ipa server 1/2/3/4/5 according to current state instead of using classical load balancer on the network level. Normal HTTP redirect will not force you to mess with certs and keytabs. -- Petr^2 Spacek From yamakasi.014 at gmail.com Fri Mar 6 13:25:57 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 6 Mar 2015 14:25:57 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <54F9A6BF.5000306@redhat.com> References: <54F9A6BF.5000306@redhat.com> Message-ID: Hi Martin, Thanks, I saw that ticket but didn't got to the wiki part yet. What I wonder in Step 6: 6. Request a signed certificate for the service and see the entry in Certmonger. In case you created a NSS database with a PIN (see the step 3.), use -P $PIN or -p /etc/httpd/nssdb/pwdfile.txt option to tell certmonger about it: # ipa-getcert request -d /etc/httpd/nssdb -n Server-Cert -K HTTP/`hostname` -N CN=`hostname`,O=EXAMPLE.COM -g 2048 -p /etc/httpd/nssdb/pwdfile.txt SAN names: in FreeIPA 4.0 and later, you can add optional SAN DNS names to your request with -D. Note that you need to first create respective host or service objects and configure that given host can manage them with service-add-host or host-add-managedby command. These objects are being verified when FreeIPA cert-req command authorizes the SAN names. Can I just add the alt names in that command, how should I proceed ? I added the host like ldap.domain... where my ldap servers are ldap-01 and ldap-02 Thanks! Matt 2015-03-06 14:08 GMT+01:00 Martin Kosek : > On 03/06/2015 01:30 PM, Matt . wrote: >> >> Hi, >> >> I'm figuring out how to regenerate the webserver certificates so I can >> use a loadbalancer in front of my ipa servers. >> >> I see in the docs there is information about this, but not for the >> webservice. Does anyone have some directions ? >> >> Thanks. >> >> Matt >> > > Certificate SubjectAltName was fixed in FreeIPA 4.0, this is the upstream > ticket: > https://fedorahosted.org/freeipa/ticket/3977 > > The procedure is described in upstream wiki for example: > http://www.freeipa.org/page/PKI#Automated_certificate_requests_with_Certmonger > > HTH, > Martin From gianluca.cecchi at gmail.com Fri Mar 6 13:34:47 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 6 Mar 2015 14:34:47 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9A7D1.5000100@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 2:12 PM, Martin Kosek wrote: > Ah, I am not sure what control do they mean. > > But in general, when, it is always interesting to check the LDAP access > logs to see the last failed request and then try the same search with > ldapsearch and fix things. > > Martin > > see my previous e-mail: /var/log/dirsrv/slapd-REALM-NAME/ contains log and you will see which kind of queries vSphere is doing. Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From root at linuxcoding.org Fri Mar 6 13:40:23 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Fri, 06 Mar 2015 20:40:23 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> Message-ID: <54F9AE47.7050705@linuxcoding.org> there is no directory "/var/log/dirsrv/" in 5.5u2b version On 3/6/15 8:34 PM, Gianluca Cecchi wrote: > On Fri, Mar 6, 2015 at 2:12 PM, Martin Kosek > wrote: > > Ah, I am not sure what control do they mean. > > But in general, when, it is always interesting to check the LDAP > access logs to see the last failed request and then try the same > search with ldapsearch and fix things. > > Martin > > > see my previous e-mail: > > /var/log/dirsrv/slapd-REALM-NAME/ > > contains log and you will see which kind of queries vSphere is doing. > > Gianluca -- Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Mar 6 13:43:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 14:43:01 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9AE47.7050705@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> Message-ID: <54F9AEE5.4030306@redhat.com> This is the directory on FreeIPA server that the vCenter is authenticating useres against. On 03/06/2015 02:40 PM, Herwono W Wijaya wrote: > there is no directory "/var/log/dirsrv/" in 5.5u2b version > > On 3/6/15 8:34 PM, Gianluca Cecchi wrote: >> On Fri, Mar 6, 2015 at 2:12 PM, Martin Kosek > > wrote: >> >> Ah, I am not sure what control do they mean. >> >> But in general, when, it is always interesting to check the LDAP access >> logs to see the last failed request and then try the same search with >> ldapsearch and fix things. >> >> Martin >> >> >> see my previous e-mail: >> >> /var/log/dirsrv/slapd-REALM-NAME/ >> >> contains log and you will see which kind of queries vSphere is doing. >> >> Gianluca > > -- > Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 > * > From root at linuxcoding.org Fri Mar 6 13:45:02 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Fri, 06 Mar 2015 20:45:02 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9AEE5.4030306@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> Message-ID: <54F9AF5E.9010001@linuxcoding.org> sorry my mistake, okay I'll check slapd log files and try to figure out what happened On 3/6/15 8:43 PM, Martin Kosek wrote: > This is the directory on FreeIPA server that the vCenter is > authenticating useres against. > > On 03/06/2015 02:40 PM, Herwono W Wijaya wrote: >> there is no directory "/var/log/dirsrv/" in 5.5u2b version >> >> On 3/6/15 8:34 PM, Gianluca Cecchi wrote: >>> On Fri, Mar 6, 2015 at 2:12 PM, Martin Kosek >> > wrote: >>> >>> Ah, I am not sure what control do they mean. >>> >>> But in general, when, it is always interesting to check the LDAP >>> access >>> logs to see the last failed request and then try the same search >>> with >>> ldapsearch and fix things. >>> >>> Martin >>> >>> >>> see my previous e-mail: >>> >>> /var/log/dirsrv/slapd-REALM-NAME/ >>> >>> contains log and you will see which kind of queries vSphere is doing. >>> >>> Gianluca >> >> -- >> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >> 2014, 2015 >> * >> >> > -- Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Fri Mar 6 14:13:05 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 6 Mar 2015 15:13:05 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <54F9AA8F.6060404@redhat.com> References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> Message-ID: Hi, But as the user is the same, I could use the same keytab for each ipa server ? I need to use the API indeed, so need to issue the http service. Any other options ? 2015-03-06 14:24 GMT+01:00 Petr Spacek : > On 6.3.2015 14:08, Martin Kosek wrote: >> I'm figuring out how to regenerate the webserver certificates so I can >> use a loadbalancer in front of my ipa servers. > > Are you talking about FreeIPA web interface? It is technically possible to use > load-balancer but it will be really hacky. You would have to solve > certificates and also distribute shared keytabs and so on. > > I would recommend you to use "something" which issues HTTP redirect to ipa > server 1/2/3/4/5 according to current state instead of using classical load > balancer on the network level. Normal HTTP redirect will not force you to mess > with certs and keytabs. > > -- > Petr^2 Spacek > > -- > 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 Fri Mar 6 14:26:29 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Fri, 6 Mar 2015 08:26:29 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54F95730.40408@redhat.com> References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> <54F95730.40408@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 1:28 AM, Martin Kosek wrote: > On 03/06/2015 02:38 AM, Dan Mossor wrote: > >> >> >> On Thu, Mar 5, 2015 at 7:21 PM, Dmitri Pal > > wrote: >> >> http://i.imgur.com/mhX86Ng.png >> >> It should show up if you do not have a ticket. Destroy the ticket on >> the >> client and try to access the server via browser, you should be >> redirected. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> Ok then, that is the page that keeps returning. I've tried from this >> workstation using Konquerer, which does not support Kerberos, I've from >> from >> Internet Explorer on a Windows 7 Professional desktop, and I've tried >> from a >> Fedora 21 system that is not enrolled in the domain. I get the exact same >> response with every attempt. >> >> One additional step I attempted to take was to change the admin password >> on the >> IPA server. I am getting a ldap_sasl_interactive_bind_s: Unknown >> authentication >> method (-6) error back. >> >> I think this installation is hosed. I am ready to wipe and start over from >> scratch tomorrow. I've already wasted 16 hours on it. >> > > Sorry to hear that. But I think you should start taking gradual steps in > your testing and trying to make Web UI over GSSAPI work. I would suggest > this procedure: > > 1) Can I "kinit admin" and run CLI command ("ipa user-show admin")? If > yes, basic FreeIPA is functioning. Run kdestroy to get rid of Kerberos. > > 2) Can I login with form basic auth to my FreeIPA? If not, did you verify > all the items in http://www.freeipa.org/page/Troubleshooting#Cannot_ > authenticate_to_Web_UI ? Did you try logging with form based auth in > FreeIPA public demo for example (user "admin", password "Secret123"): > > https://ipa.demo1.freeipa.org/ipa/ui/ > > If not, we can dig further. If yes, you can continue with kinit + SSO for > the Web UI. > Martin, Dmitri, Thanks for your help, but I've taken every step available on the page you linked. I just checked this morning before I started over, and on the server I can kinit as admin and run ipa user-show admin. The ipa tools are not on my workstation. I then ran kdestroy on both the server and workstation, and the error remains when logging in to the web UI - it returns me to the screen I showed above in the link to the screenshot. Regards, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Mar 6 14:31:13 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 06 Mar 2015 15:31:13 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> Message-ID: <54F9BA31.9070706@redhat.com> On 6.3.2015 15:13, Matt . wrote: > Hi, > > But as the user is the same, I could use the same keytab for each ipa server ? > > I need to use the API indeed, so need to issue the http service. > > Any other options ? I do not really understand your use case. Could you describe it in detail, please? Petr^2 Spacek > 2015-03-06 14:24 GMT+01:00 Petr Spacek : >> On 6.3.2015 14:08, Martin Kosek wrote: >>> I'm figuring out how to regenerate the webserver certificates so I can >>> use a loadbalancer in front of my ipa servers. >> >> Are you talking about FreeIPA web interface? It is technically possible to use >> load-balancer but it will be really hacky. You would have to solve >> certificates and also distribute shared keytabs and so on. >> >> I would recommend you to use "something" which issues HTTP redirect to ipa >> server 1/2/3/4/5 according to current state instead of using classical load >> balancer on the network level. Normal HTTP redirect will not force you to mess >> with certs and keytabs. >> >> -- >> Petr^2 Spacek From yamakasi.014 at gmail.com Fri Mar 6 14:39:10 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 6 Mar 2015 15:39:10 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <54F9BA31.9070706@redhat.com> References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> Message-ID: I have 2 IPA servers where I kinit to and post to the api using curl/json. As I need redundancy and don't want to have it script managed, but one central point where I can tal to I use a loadbalancer. As I connect to the loadbalancer using DNAT, so the client IP is known on the IPA server because this is needed for the http service principals I need to add the loadbalancer hostname to my IPA server and make it as an ALT name to it's Certificate. As the users are the same on both servers I would asume i can use a keytab for a user against both servers from my clients. Does this make it more clear ? 2015-03-06 15:31 GMT+01:00 Petr Spacek : > On 6.3.2015 15:13, Matt . wrote: >> Hi, >> >> But as the user is the same, I could use the same keytab for each ipa server ? >> >> I need to use the API indeed, so need to issue the http service. >> >> Any other options ? > > I do not really understand your use case. Could you describe it in detail, please? > > Petr^2 Spacek > >> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>> On 6.3.2015 14:08, Martin Kosek wrote: >>>> I'm figuring out how to regenerate the webserver certificates so I can >>>> use a loadbalancer in front of my ipa servers. >>> >>> Are you talking about FreeIPA web interface? It is technically possible to use >>> load-balancer but it will be really hacky. You would have to solve >>> certificates and also distribute shared keytabs and so on. >>> >>> I would recommend you to use "something" which issues HTTP redirect to ipa >>> server 1/2/3/4/5 according to current state instead of using classical load >>> balancer on the network level. Normal HTTP redirect will not force you to mess >>> with certs and keytabs. >>> >>> -- >>> Petr^2 Spacek From root at linuxcoding.org Fri Mar 6 14:54:51 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Fri, 06 Mar 2015 21:54:51 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9AF5E.9010001@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> Message-ID: <54F9BFBB.1070101@linuxcoding.org> FreeIPA logs: [06/Mar/2015:21:51:15 +0700] conn=30 op=0 BIND dn="uid=admin,cn=users,cn=compat,dc=server,dc=local" method=128 version=3 [06/Mar/2015:21:51:15 +0700] conn=30 op=0 RESULT err=0 tag=97 nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=server,dc=local" [06/Mar/2015:21:51:15 +0700] conn=30 op=1 SRCH base="cn=users,cn=compat,dc=server,dc=local" scope=2 filter="(objectClass=inetOrgPerson)" attrs="uid description givenName sn mail useraccountcontrol pwdaccountlockedtime entryuuid" [06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101 nentries=2 etime=0 notes=P [06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND [06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1 vCenter SSO error: Error: Idm client exception: Control not found On 3/6/15 8:45 PM, Herwono W Wijaya wrote: > sorry my mistake, okay I'll check slapd log files and try to figure > out what happened > > On 3/6/15 8:43 PM, Martin Kosek wrote: >> This is the directory on FreeIPA server that the vCenter is >> authenticating useres against. >> >> On 03/06/2015 02:40 PM, Herwono W Wijaya wrote: >>> there is no directory "/var/log/dirsrv/" in 5.5u2b version >>> >>> On 3/6/15 8:34 PM, Gianluca Cecchi wrote: >>>> On Fri, Mar 6, 2015 at 2:12 PM, Martin Kosek >>> > wrote: >>>> >>>> Ah, I am not sure what control do they mean. >>>> >>>> But in general, when, it is always interesting to check the >>>> LDAP access >>>> logs to see the last failed request and then try the same >>>> search with >>>> ldapsearch and fix things. >>>> >>>> Martin >>>> >>>> >>>> see my previous e-mail: >>>> >>>> /var/log/dirsrv/slapd-REALM-NAME/ >>>> >>>> contains log and you will see which kind of queries vSphere is doing. >>>> >>>> Gianluca >>> >>> -- >>> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >>> 2014, 2015 >>> * >>> >>> >> > > -- > Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert > 2014, 2015 > * > > > -- Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 6 15:11:34 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Mar 2015 10:11:34 -0500 Subject: [Freeipa-users] verified certificates both sides of a TLS channel In-Reply-To: <54F9A605.5010303@redhat.com> References: <54F97420.6020601@redhat.com> <54F99AB9.6050809@redhat.com> <54F9A605.5010303@redhat.com> Message-ID: <54F9C3A6.8060307@redhat.com> On 03/06/2015 08:05 AM, Martin Kosek wrote: > On 03/06/2015 01:16 PM, Dmitri Pal wrote: >> On 03/06/2015 04:32 AM, Martin Kosek wrote: >>> On 03/06/2015 09:34 AM, Andrew Holway wrote: >>>> Hi, >>>> >>>> Were using rabbitmq to shunt bits of data around various systems to >>>> provide >>>> better security we would like all of our acmq connections to be >>>> authenticated >>>> and encrypted. >>>> >>>> I'm looking for appropriate documentation or some friendly guidance >>>> of how >>>> server to server SSL authentication is done with freeipa and if >>>> indeed this is >>>> the best way to ensure privacy in such scenarios. >>> >>> These are the best documentation sources I could find: >>> >>> Creating certs for FreeIPA hosts: >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/host-certificates.html >>> >>> >>> >>> Creating certs for FreeIPA hosts: >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html >>> >>> >>> >>> With these certificates, you would need to manually configure SSL-based >>> authentication with mod_ssl/mod_nss. Partially related user howto is >>> http://www.freeipa.org/page/Apache_SNI_With_Kerberos >>> >>> I wonder if RabbitMQ has GSSAPI support, that would be more easy to >>> configure >>> with FreeIPA than SSL certs. >>> >>> Btw FreeIPA 4.2 plans to have much better support for different cert >>> profiles >>> or sub-CAs that you may later use for purposes like this one. >>> >>> Ticket: >>> https://fedorahosted.org/freeipa/ticket/57 >>> >>> CCing Fraser from Dogtag team for reference. >>> >>> Martin >>> >> What we still missing is the client side certs. So AFAIU we would be >> able to >> provide certs for one way authentication not two way yet. >> It is in works. > > Couldn't the authentication be provided with service certs and current > default certificate profile? I do not think so. I added Rob to the thread. I think he explained one time what is missing but I do not recall the details. > > This is the ticket for the client certificate work, it was missing: > https://fedorahosted.org/freeipa/ticket/4938 > > Martin -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From pspacek at redhat.com Fri Mar 6 15:16:24 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 06 Mar 2015 16:16:24 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> Message-ID: <54F9C4C8.8020008@redhat.com> On 6.3.2015 15:39, Matt . wrote: > I have 2 IPA servers where I kinit to and post to the api using curl/json. If we are talking purely about scripting, you can use IPA Python API. It will handle fail over for you even without any load balancer. That would be easiest way. > As I need redundancy and don't want to have it script managed, but one > central point where I can tal to I use a loadbalancer. Well, if you can control clients then the easiest and most universal way is to use DNS SRV records and add failover logic to clients. That solution works even when servers are geographically distributed/in different networks and does not have single point of failure (the load balancer). > As I connect to the loadbalancer using DNAT, so the client IP is known > on the IPA server because this is needed for the http service > principals I need to add the loadbalancer hostname to my IPA server > and make it as an ALT name to it's Certificate. > > As the users are the same on both servers I would asume i can use a > keytab for a user against both servers from my clients. I'm talking about keytabs on the FreeIPA servers - services running on IPA server have their own keytabs too. Every service on every server has own keytab with different key. You need to talk with Simo or some other Kerberos guru about possibility of sharing keytabs between IPA services. > Does this make it more clear ? I'm still not sure if you want to have human users too or just API clients. Petr^2 Spacek > 2015-03-06 15:31 GMT+01:00 Petr Spacek : >> On 6.3.2015 15:13, Matt . wrote: >>> Hi, >>> >>> But as the user is the same, I could use the same keytab for each ipa server ? >>> >>> I need to use the API indeed, so need to issue the http service. >>> >>> Any other options ? >> >> I do not really understand your use case. Could you describe it in detail, please? >> >> Petr^2 Spacek >> >>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>> I'm figuring out how to regenerate the webserver certificates so I can >>>>> use a loadbalancer in front of my ipa servers. >>>> >>>> Are you talking about FreeIPA web interface? It is technically possible to use >>>> load-balancer but it will be really hacky. You would have to solve >>>> certificates and also distribute shared keytabs and so on. >>>> >>>> I would recommend you to use "something" which issues HTTP redirect to ipa >>>> server 1/2/3/4/5 according to current state instead of using classical load >>>> balancer on the network level. Normal HTTP redirect will not force you to mess >>>> with certs and keytabs. >>>> >>>> -- >>>> Petr^2 Spacek -- Petr Spacek @ Red Hat From dpal at redhat.com Fri Mar 6 15:21:38 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Mar 2015 10:21:38 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> <54F95730.40408@redhat.com> Message-ID: <54F9C602.3080608@redhat.com> On 03/06/2015 09:26 AM, Dan Mossor wrote: > On Fri, Mar 6, 2015 at 1:28 AM, Martin Kosek > wrote: > > On 03/06/2015 02:38 AM, Dan Mossor wrote: > > > > On Thu, Mar 5, 2015 at 7:21 PM, Dmitri Pal > >> wrote: > > http://i.imgur.com/mhX86Ng.png > > It should show up if you do not have a ticket. Destroy the > ticket on the > client and try to access the server via browser, you > should be redirected. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > Ok then, that is the page that keeps returning. I've tried > from this > workstation using Konquerer, which does not support Kerberos, > I've from from > Internet Explorer on a Windows 7 Professional desktop, and > I've tried from a > Fedora 21 system that is not enrolled in the domain. I get the > exact same > response with every attempt. > > One additional step I attempted to take was to change the > admin password on the > IPA server. I am getting a ldap_sasl_interactive_bind_s: > Unknown authentication > method (-6) error back. > > I think this installation is hosed. I am ready to wipe and > start over from > scratch tomorrow. I've already wasted 16 hours on it. > > > Sorry to hear that. But I think you should start taking gradual > steps in your testing and trying to make Web UI over GSSAPI work. > I would suggest this procedure: > > 1) Can I "kinit admin" and run CLI command ("ipa user-show > admin")? If yes, basic FreeIPA is functioning. Run kdestroy to get > rid of Kerberos. > > 2) Can I login with form basic auth to my FreeIPA? If not, did you > verify all the items in > http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI > ? Did you try logging with form based auth in FreeIPA public demo > for example (user "admin", password "Secret123"): > > https://ipa.demo1.freeipa.org/ipa/ui/ > > If not, we can dig further. If yes, you can continue with kinit + > SSO for the Web UI. > > Martin, Dmitri, > > Thanks for your help, but I've taken every step available on the page > you linked. I just checked this morning before I started over, and on > the server I can kinit as admin and run ipa user-show admin. The ipa > tools are not on my workstation. I then ran kdestroy on both the > server and workstation, and the error remains when logging in to the > web UI - it returns me to the screen I showed above in the link to the > screenshot. > > Regards, > Dan From your workstation can you use the demo instance https://ipa.demo1.freeipa.org/ipa/ui/ or it returns the same error? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Fri Mar 6 15:24:28 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 6 Mar 2015 16:24:28 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <54F9C4C8.8020008@redhat.com> References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> Message-ID: Hi, I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, SRV won't fit here sorry to say. I auth users, so their keytab should be the same between two masters I believe ? In that case... I need to add the altnames to the certs, but I'm not 100% there in step 6 Thanks again! Cheers, Matthijs 2015-03-06 16:16 GMT+01:00 Petr Spacek : > On 6.3.2015 15:39, Matt . wrote: >> I have 2 IPA servers where I kinit to and post to the api using curl/json. > > If we are talking purely about scripting, you can use IPA Python API. It will > handle fail over for you even without any load balancer. That would be easiest > way. > >> As I need redundancy and don't want to have it script managed, but one >> central point where I can tal to I use a loadbalancer. > > Well, if you can control clients then the easiest and most universal way is to > use DNS SRV records and add failover logic to clients. That solution works > even when servers are geographically distributed/in different networks and > does not have single point of failure (the load balancer). > >> As I connect to the loadbalancer using DNAT, so the client IP is known >> on the IPA server because this is needed for the http service >> principals I need to add the loadbalancer hostname to my IPA server >> and make it as an ALT name to it's Certificate. >> >> As the users are the same on both servers I would asume i can use a >> keytab for a user against both servers from my clients. > > I'm talking about keytabs on the FreeIPA servers - services running on IPA > server have their own keytabs too. Every service on every server has own > keytab with different key. > > You need to talk with Simo or some other Kerberos guru about possibility of > sharing keytabs between IPA services. > >> Does this make it more clear ? > > I'm still not sure if you want to have human users too or just API clients. > > Petr^2 Spacek > >> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>> On 6.3.2015 15:13, Matt . wrote: >>>> Hi, >>>> >>>> But as the user is the same, I could use the same keytab for each ipa server ? >>>> >>>> I need to use the API indeed, so need to issue the http service. >>>> >>>> Any other options ? >>> >>> I do not really understand your use case. Could you describe it in detail, please? >>> >>> Petr^2 Spacek >>> >>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>> I'm figuring out how to regenerate the webserver certificates so I can >>>>>> use a loadbalancer in front of my ipa servers. >>>>> >>>>> Are you talking about FreeIPA web interface? It is technically possible to use >>>>> load-balancer but it will be really hacky. You would have to solve >>>>> certificates and also distribute shared keytabs and so on. >>>>> >>>>> I would recommend you to use "something" which issues HTTP redirect to ipa >>>>> server 1/2/3/4/5 according to current state instead of using classical load >>>>> balancer on the network level. Normal HTTP redirect will not force you to mess >>>>> with certs and keytabs. >>>>> >>>>> -- >>>>> Petr^2 Spacek > > > -- > Petr Spacek @ Red Hat From pspacek at redhat.com Fri Mar 6 15:26:40 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 06 Mar 2015 16:26:40 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> Message-ID: <54F9C730.3040706@redhat.com> On 6.3.2015 16:24, Matt . wrote: > Hi, > > I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, > SRV won't fit here sorry to say. > > I auth users, so their keytab should be the same between two masters I believe ? Keytabs are used by Kerberos and MIT kerberos libraries fully support SRV records and failover. > > In that case... I need to add the altnames to the certs, but I'm not > 100% there in step 6 I hope someone else can advise you how to do that but be prepared for hickups, this setup is not tested. Petr^2 Spacek > > Thanks again! > > Cheers, > > Matthijs > > 2015-03-06 16:16 GMT+01:00 Petr Spacek : >> On 6.3.2015 15:39, Matt . wrote: >>> I have 2 IPA servers where I kinit to and post to the api using curl/json. >> >> If we are talking purely about scripting, you can use IPA Python API. It will >> handle fail over for you even without any load balancer. That would be easiest >> way. >> >>> As I need redundancy and don't want to have it script managed, but one >>> central point where I can tal to I use a loadbalancer. >> >> Well, if you can control clients then the easiest and most universal way is to >> use DNS SRV records and add failover logic to clients. That solution works >> even when servers are geographically distributed/in different networks and >> does not have single point of failure (the load balancer). >> >>> As I connect to the loadbalancer using DNAT, so the client IP is known >>> on the IPA server because this is needed for the http service >>> principals I need to add the loadbalancer hostname to my IPA server >>> and make it as an ALT name to it's Certificate. >>> >>> As the users are the same on both servers I would asume i can use a >>> keytab for a user against both servers from my clients. >> >> I'm talking about keytabs on the FreeIPA servers - services running on IPA >> server have their own keytabs too. Every service on every server has own >> keytab with different key. >> >> You need to talk with Simo or some other Kerberos guru about possibility of >> sharing keytabs between IPA services. >> >>> Does this make it more clear ? >> >> I'm still not sure if you want to have human users too or just API clients. >> >> Petr^2 Spacek >> >>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>> On 6.3.2015 15:13, Matt . wrote: >>>>> Hi, >>>>> >>>>> But as the user is the same, I could use the same keytab for each ipa server ? >>>>> >>>>> I need to use the API indeed, so need to issue the http service. >>>>> >>>>> Any other options ? >>>> >>>> I do not really understand your use case. Could you describe it in detail, please? >>>> >>>> Petr^2 Spacek >>>> >>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>> I'm figuring out how to regenerate the webserver certificates so I can >>>>>>> use a loadbalancer in front of my ipa servers. >>>>>> >>>>>> Are you talking about FreeIPA web interface? It is technically possible to use >>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>> certificates and also distribute shared keytabs and so on. >>>>>> >>>>>> I would recommend you to use "something" which issues HTTP redirect to ipa >>>>>> server 1/2/3/4/5 according to current state instead of using classical load >>>>>> balancer on the network level. Normal HTTP redirect will not force you to mess >>>>>> with certs and keytabs. >>>>>> >>>>>> -- >>>>>> Petr^2 Spacek >> >> >> -- >> Petr Spacek @ Red Hat -- Petr Spacek @ Red Hat From danofsatx at gmail.com Fri Mar 6 15:35:11 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Fri, 6 Mar 2015 09:35:11 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54F9C602.3080608@redhat.com> References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> <54F95730.40408@redhat.com> <54F9C602.3080608@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 9:21 AM, Dmitri Pal wrote: > > From your workstation can you use the demo instance > https://ipa.demo1.freeipa.org/ipa/ui/ or it returns the same error? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > Oh, sorry, I didn't realize I was supposed to check that. For the record, yes - I can log into the demo instance on Firefox from my workstation. For the sake of completeness, I checked with Konquerer also and can log in to the demo instance. Regards, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From simo at redhat.com Fri Mar 6 15:40:13 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 06 Mar 2015 10:40:13 -0500 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> Message-ID: <1425656413.2889.12.camel@willson.usersys.redhat.com> On Fri, 2015-03-06 at 16:24 +0100, Matt . wrote: > Hi, > > I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, > SRV won't fit here sorry to say. > > I auth users, so their keytab should be the same between two masters I believe ? What kind of load balancing ? An IPA server offers multiple different kerberized services, not all of them may be able to work using multiple keys (you would need one key for the real name and one for the load balanced name). Simo. > In that case... I need to add the altnames to the certs, but I'm not > 100% there in step 6 > > Thanks again! > > Cheers, > > Matthijs > > 2015-03-06 16:16 GMT+01:00 Petr Spacek : > > On 6.3.2015 15:39, Matt . wrote: > >> I have 2 IPA servers where I kinit to and post to the api using curl/json. > > > > If we are talking purely about scripting, you can use IPA Python API. It will > > handle fail over for you even without any load balancer. That would be easiest > > way. > > > >> As I need redundancy and don't want to have it script managed, but one > >> central point where I can tal to I use a loadbalancer. > > > > Well, if you can control clients then the easiest and most universal way is to > > use DNS SRV records and add failover logic to clients. That solution works > > even when servers are geographically distributed/in different networks and > > does not have single point of failure (the load balancer). > > > >> As I connect to the loadbalancer using DNAT, so the client IP is known > >> on the IPA server because this is needed for the http service > >> principals I need to add the loadbalancer hostname to my IPA server > >> and make it as an ALT name to it's Certificate. > >> > >> As the users are the same on both servers I would asume i can use a > >> keytab for a user against both servers from my clients. > > > > I'm talking about keytabs on the FreeIPA servers - services running on IPA > > server have their own keytabs too. Every service on every server has own > > keytab with different key. > > > > You need to talk with Simo or some other Kerberos guru about possibility of > > sharing keytabs between IPA services. > > > >> Does this make it more clear ? > > > > I'm still not sure if you want to have human users too or just API clients. > > > > Petr^2 Spacek > > > >> 2015-03-06 15:31 GMT+01:00 Petr Spacek : > >>> On 6.3.2015 15:13, Matt . wrote: > >>>> Hi, > >>>> > >>>> But as the user is the same, I could use the same keytab for each ipa server ? > >>>> > >>>> I need to use the API indeed, so need to issue the http service. > >>>> > >>>> Any other options ? > >>> > >>> I do not really understand your use case. Could you describe it in detail, please? > >>> > >>> Petr^2 Spacek > >>> > >>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : > >>>>> On 6.3.2015 14:08, Martin Kosek wrote: > >>>>>> I'm figuring out how to regenerate the webserver certificates so I can > >>>>>> use a loadbalancer in front of my ipa servers. > >>>>> > >>>>> Are you talking about FreeIPA web interface? It is technically possible to use > >>>>> load-balancer but it will be really hacky. You would have to solve > >>>>> certificates and also distribute shared keytabs and so on. > >>>>> > >>>>> I would recommend you to use "something" which issues HTTP redirect to ipa > >>>>> server 1/2/3/4/5 according to current state instead of using classical load > >>>>> balancer on the network level. Normal HTTP redirect will not force you to mess > >>>>> with certs and keytabs. > >>>>> > >>>>> -- > >>>>> Petr^2 Spacek > > > > > > -- > > Petr Spacek @ Red Hat -- Simo Sorce * Red Hat, Inc * New York From rmeggins at redhat.com Fri Mar 6 15:40:25 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 06 Mar 2015 08:40:25 -0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9BFBB.1070101@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> Message-ID: <54F9CA69.6040503@redhat.com> On 03/06/2015 07:54 AM, Herwono W Wijaya wrote: > FreeIPA logs: > [06/Mar/2015:21:51:15 +0700] conn=30 op=0 BIND > dn="uid=admin,cn=users,cn=compat,dc=server,dc=local" method=128 version=3 > [06/Mar/2015:21:51:15 +0700] conn=30 op=0 RESULT err=0 tag=97 > nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=server,dc=local" > [06/Mar/2015:21:51:15 +0700] conn=30 op=1 SRCH > base="cn=users,cn=compat,dc=server,dc=local" scope=2 > filter="(objectClass=inetOrgPerson)" attrs="uid description givenName > sn mail useraccountcontrol pwdaccountlockedtime entryuuid" > [06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101 > nentries=2 etime=0 notes=P > [06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND > [06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1 > > vCenter SSO error: > Error: Idm client exception: Control not found There's no error log debug level which will give us all of the controls received by the server or all of the controls sent back by the server. The TRACE level will give us some information. But the problem appears to be that vCenter is expecting some control. There is no way we can tell what control that might be by analyzing the LDAP protocol, even with wireshark. If the vCenter documentation does not suffice, and VMWare support is not forthcoming, then we might be able to reverse engineer the code. For example, search the code, if scripts, or use something like the "strings" command on binaries, to look for well known OID prefixes. For example, from dirsrv: # strings /usr/lib64/lib/dirsrv/libslapd.so.0.0.0|grep "1.3.6.1.4" 1.3.6.1.4.1.1466.115.121.1.34 1.3.6.1.4.1.1466.115.121.1.12 1.3.6.1.4.1.1466.115.121.1.15 1.3.6.1.4.1.42.2.27.8.5.1 1.3.6.1.4.1.42.2.27.9.5.2 ... If we can narrow down the list of possible control OIDs that vCenter knows about, we can perhaps figure out if 389 supports them. > > On 3/6/15 8:45 PM, Herwono W Wijaya wrote: >> sorry my mistake, okay I'll check slapd log files and try to figure >> out what happened >> >> On 3/6/15 8:43 PM, Martin Kosek wrote: >>> This is the directory on FreeIPA server that the vCenter is >>> authenticating useres against. >>> >>> On 03/06/2015 02:40 PM, Herwono W Wijaya wrote: >>>> there is no directory "/var/log/dirsrv/" in 5.5u2b version >>>> >>>> On 3/6/15 8:34 PM, Gianluca Cecchi wrote: >>>>> On Fri, Mar 6, 2015 at 2:12 PM, Martin Kosek >>>> > wrote: >>>>> >>>>> Ah, I am not sure what control do they mean. >>>>> >>>>> But in general, when, it is always interesting to check the >>>>> LDAP access >>>>> logs to see the last failed request and then try the same >>>>> search with >>>>> ldapsearch and fix things. >>>>> >>>>> Martin >>>>> >>>>> >>>>> see my previous e-mail: >>>>> >>>>> /var/log/dirsrv/slapd-REALM-NAME/ >>>>> >>>>> contains log and you will see which kind of queries vSphere is doing. >>>>> >>>>> Gianluca >>>> >>>> -- >>>> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >>>> 2014, 2015 >>>> * >>>> >>>> >>> >> >> -- >> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >> 2014, 2015 >> * >> >> >> > > -- > Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert > 2014, 2015 > * > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 6 15:41:40 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Mar 2015 10:41:40 -0500 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> Message-ID: <54F9CAB4.9060808@redhat.com> On 03/06/2015 10:24 AM, Matt . wrote: > Hi, > > I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, > SRV won't fit here sorry to say. > > I auth users, so their keytab should be the same between two masters I believe ? Each entity in Kerberos exchange has its own identity and key. If you send a ticket that is destined to service A instead to service B it would not work unless they share the same keys and identity. Sharinf same keys and identities between the servers just would not work with IPA. Keep in mind that IPA clients and server need to work and fail over if you do not have any load balancers and this is the common case. You are trying to add one where it is really not needed creating overhead for yourself. > > In that case... I need to add the altnames to the certs, but I'm not > 100% there in step 6 > > Thanks again! > > Cheers, > > Matthijs > > 2015-03-06 16:16 GMT+01:00 Petr Spacek : >> On 6.3.2015 15:39, Matt . wrote: >>> I have 2 IPA servers where I kinit to and post to the api using curl/json. >> If we are talking purely about scripting, you can use IPA Python API. It will >> handle fail over for you even without any load balancer. That would be easiest >> way. >> >>> As I need redundancy and don't want to have it script managed, but one >>> central point where I can tal to I use a loadbalancer. >> Well, if you can control clients then the easiest and most universal way is to >> use DNS SRV records and add failover logic to clients. That solution works >> even when servers are geographically distributed/in different networks and >> does not have single point of failure (the load balancer). >> >>> As I connect to the loadbalancer using DNAT, so the client IP is known >>> on the IPA server because this is needed for the http service >>> principals I need to add the loadbalancer hostname to my IPA server >>> and make it as an ALT name to it's Certificate. >>> >>> As the users are the same on both servers I would asume i can use a >>> keytab for a user against both servers from my clients. >> I'm talking about keytabs on the FreeIPA servers - services running on IPA >> server have their own keytabs too. Every service on every server has own >> keytab with different key. >> >> You need to talk with Simo or some other Kerberos guru about possibility of >> sharing keytabs between IPA services. >> >>> Does this make it more clear ? >> I'm still not sure if you want to have human users too or just API clients. >> >> Petr^2 Spacek >> >>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>> On 6.3.2015 15:13, Matt . wrote: >>>>> Hi, >>>>> >>>>> But as the user is the same, I could use the same keytab for each ipa server ? >>>>> >>>>> I need to use the API indeed, so need to issue the http service. >>>>> >>>>> Any other options ? >>>> I do not really understand your use case. Could you describe it in detail, please? >>>> >>>> Petr^2 Spacek >>>> >>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>> I'm figuring out how to regenerate the webserver certificates so I can >>>>>>> use a loadbalancer in front of my ipa servers. >>>>>> Are you talking about FreeIPA web interface? It is technically possible to use >>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>> certificates and also distribute shared keytabs and so on. >>>>>> >>>>>> I would recommend you to use "something" which issues HTTP redirect to ipa >>>>>> server 1/2/3/4/5 according to current state instead of using classical load >>>>>> balancer on the network level. Normal HTTP redirect will not force you to mess >>>>>> with certs and keytabs. >>>>>> >>>>>> -- >>>>>> Petr^2 Spacek >> >> -- >> Petr Spacek @ Red Hat -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri Mar 6 15:43:47 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Mar 2015 10:43:47 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> <54F95730.40408@redhat.com> <54F9C602.3080608@redhat.com> Message-ID: <54F9CB33.3040206@redhat.com> On 03/06/2015 10:35 AM, Dan Mossor wrote: > > > On Fri, Mar 6, 2015 at 9:21 AM, Dmitri Pal > wrote: > > > From your workstation can you use the demo instance > https://ipa.demo1.freeipa.org/ipa/ui/ or it returns the same error? > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > Oh, sorry, I didn't realize I was supposed to check that. For the > record, yes - I can log into the demo instance on Firefox from my > workstation. For the sake of completeness, I checked with Konquerer > also and can log in to the demo instance. > > Regards, > Dan OK, so it seems that something is really broken on that server. May be it is easier to start over - up to you. If you want to continue troubleshooting we are here to help. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From root at linuxcoding.org Fri Mar 6 16:01:48 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Fri, 06 Mar 2015 23:01:48 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9CA69.6040503@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> Message-ID: <54F9CF6C.7050803@linuxcoding.org> this result from #strings /usr/lib/openldap/slapd | grep "1.3.6.1.4" On 3/6/15 10:40 PM, Rich Megginson wrote: > On 03/06/2015 07:54 AM, Herwono W Wijaya wrote: >> FreeIPA logs: >> [06/Mar/2015:21:51:15 +0700] conn=30 op=0 BIND >> dn="uid=admin,cn=users,cn=compat,dc=server,dc=local" method=128 version=3 >> [06/Mar/2015:21:51:15 +0700] conn=30 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="uid=admin,cn=users,cn=accounts,dc=server,dc=local" >> [06/Mar/2015:21:51:15 +0700] conn=30 op=1 SRCH >> base="cn=users,cn=compat,dc=server,dc=local" scope=2 >> filter="(objectClass=inetOrgPerson)" attrs="uid description givenName >> sn mail useraccountcontrol pwdaccountlockedtime entryuuid" >> [06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101 >> nentries=2 etime=0 notes=P >> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND >> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1 >> >> vCenter SSO error: >> Error: Idm client exception: Control not found > > There's no error log debug level which will give us all of the > controls received by the server or all of the controls sent back by > the server. The TRACE level will give us some information. > > But the problem appears to be that vCenter is expecting some control. > There is no way we can tell what control that might be by analyzing > the LDAP protocol, even with wireshark. If the vCenter documentation > does not suffice, and VMWare support is not forthcoming, then we might > be able to reverse engineer the code. For example, search the code, if > scripts, or use something like the "strings" command on binaries, to > look for well known OID prefixes. > > For example, from dirsrv: > # strings /usr/lib64/lib/dirsrv/libslapd.so.0.0.0|grep "1.3.6.1.4" > 1.3.6.1.4.1.1466.115.121.1.34 > 1.3.6.1.4.1.1466.115.121.1.12 > 1.3.6.1.4.1.1466.115.121.1.15 > 1.3.6.1.4.1.42.2.27.8.5.1 > 1.3.6.1.4.1.42.2.27.9.5.2 > ... > > If we can narrow down the list of possible control OIDs that vCenter > knows about, we can perhaps figure out if 389 supports them. > >> >> On 3/6/15 8:45 PM, Herwono W Wijaya wrote: >>> sorry my mistake, okay I'll check slapd log files and try to figure >>> out what happened >>> >>> On 3/6/15 8:43 PM, Martin Kosek wrote: >>>> This is the directory on FreeIPA server that the vCenter is >>>> authenticating useres against. >>>> >>>> On 03/06/2015 02:40 PM, Herwono W Wijaya wrote: >>>>> there is no directory "/var/log/dirsrv/" in 5.5u2b version >>>>> >>>>> On 3/6/15 8:34 PM, Gianluca Cecchi wrote: >>>>>> On Fri, Mar 6, 2015 at 2:12 PM, Martin Kosek >>>>> > wrote: >>>>>> >>>>>> Ah, I am not sure what control do they mean. >>>>>> >>>>>> But in general, when, it is always interesting to check the >>>>>> LDAP access >>>>>> logs to see the last failed request and then try the same >>>>>> search with >>>>>> ldapsearch and fix things. >>>>>> >>>>>> Martin >>>>>> >>>>>> >>>>>> see my previous e-mail: >>>>>> >>>>>> /var/log/dirsrv/slapd-REALM-NAME/ >>>>>> >>>>>> contains log and you will see which kind of queries vSphere is >>>>>> doing. >>>>>> >>>>>> Gianluca >>>>> >>>>> -- >>>>> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware >>>>> vExpert 2014, 2015 >>>>> * >>>>> >>>>> >>>> >>> >>> -- >>> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >>> 2014, 2015 >>> * >>> >>> >>> >> >> -- >> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >> 2014, 2015 >> * >> >> >> > > > -- Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 * -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- 1.3.6.1.4.1.4203.1.12.2 1.3.6.1.4.1.1466.115.121.1 extended=1.3.6.1.4.1.1466.20037 extended=1.3.6.1.4.1.4203.1.11.1 extended=1.3.6.1.4.1.4203.1.11.3 1.3.6.1.4.1.1466.20036 1.3.6.1.4.1.1466.115.121.1.27 1.3.6.1.4.1.1466.115.121.1.34 1.3.6.1.4.1.1466.115.121.1.12 group "%s" attr "%s": inappropriate syntax: %s; must be 1.3.6.1.4.1.1466.115.121.1.12 (DN), 1.3.6.1.4.1.1466.115.121.1.34 (NameUID) or a subtype of labeledURI. 1.3.6.1.4.1.4203.666.5.15 1.3.6.1.4.1.4203.1.10.1 1.3.6.1.4.1.4203.666.5.2 1.3.6.1.4.1.4203.666.5.12 1.3.6.1.4.1.1466.101.119.1 1.3.6.1.4.1.4203.1.11.1 1.3.6.1.4.1.4203.1.11.3 1.3.6.1.4.1.4203.666.11.2.1 1.3.6.1.4.1.1466.115.121.1.8 1.3.6.1.4.1.1466.115.121.1.9 1.3.6.1.4.1.1466.115.121.1.44 1.3.6.1.4.1.1466.115.121.1.17 1.3.6.1.4.1.1466.115.121.1.38 1.3.6.1.4.1.1466.115.121.1.3 1.3.6.1.4.1.1466.115.121.1.16 1.3.6.1.4.1.1466.115.121.1.54 1.3.6.1.4.1.1466.115.121.1.30 1.3.6.1.4.1.1466.115.121.1.31 1.3.6.1.4.1.1466.115.121.1.35 1.3.6.1.4.1.1466.115.121.1.37 1.3.6.1.4.1.4203.666.4.4 1.3.6.1.4.1.4203.666.4.5 1.3.6.1.4.1.1466.115.121.1.15 1.3.6.1.4.1.1466.115.121.1.26 1.3.6.1.4.1.4203.666.11.10.2.1 ( 1.3.6.1.4.1.1466.115.121.1.1 DESC 'ACI Item' X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.2 DESC 'Access Point' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.3 DESC 'Attribute Type Description' ) ( 1.3.6.1.4.1.1466.115.121.1.4 DESC 'Audio' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.5 DESC 'Binary' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.6 DESC 'Bit String' ) ( 1.3.6.1.4.1.1466.115.121.1.7 DESC 'Boolean' ) ( 1.3.6.1.4.1.1466.115.121.1.8 DESC 'Certificate' X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.9 DESC 'Certificate List' X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.10 DESC 'Certificate Pair' X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.4203.666.11.10.2.1 DESC 'X.509 AttributeCertificate' X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.12 DESC 'Distinguished Name' ) ( 1.3.6.1.4.1.1466.115.121.1.13 DESC 'Data Quality' ) ( 1.3.6.1.4.1.1466.115.121.1.14 DESC 'Delivery Method' ) ( 1.3.6.1.4.1.1466.115.121.1.15 DESC 'Directory String' ) ( 1.3.6.1.4.1.1466.115.121.1.16 DESC 'DIT Content Rule Description' ) ( 1.3.6.1.4.1.1466.115.121.1.17 DESC 'DIT Structure Rule Description' ) ( 1.3.6.1.4.1.1466.115.121.1.19 DESC 'DSA Quality' ) ( 1.3.6.1.4.1.1466.115.121.1.20 DESC 'DSE Type' ) ( 1.3.6.1.4.1.1466.115.121.1.21 DESC 'Enhanced Guide' ) ( 1.3.6.1.4.1.1466.115.121.1.22 DESC 'Facsimile Telephone Number' ) ( 1.3.6.1.4.1.1466.115.121.1.23 DESC 'Fax' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.24 DESC 'Generalized Time' ) ( 1.3.6.1.4.1.1466.115.121.1.25 DESC 'Guide' ) ( 1.3.6.1.4.1.1466.115.121.1.26 DESC 'IA5 String' ) ( 1.3.6.1.4.1.1466.115.121.1.27 DESC 'Integer' ) ( 1.3.6.1.4.1.1466.115.121.1.28 DESC 'JPEG' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.29 DESC 'Master And Shadow Access Points' ) ( 1.3.6.1.4.1.1466.115.121.1.30 DESC 'Matching Rule Description' ) ( 1.3.6.1.4.1.1466.115.121.1.31 DESC 'Matching Rule Use Description' ) ( 1.3.6.1.4.1.1466.115.121.1.32 DESC 'Mail Preference' ) ( 1.3.6.1.4.1.1466.115.121.1.33 DESC 'MHS OR Address' ) ( 1.3.6.1.4.1.1466.115.121.1.34 DESC 'Name And Optional UID' ) ( 1.3.6.1.4.1.1466.115.121.1.35 DESC 'Name Form Description' ) ( 1.3.6.1.4.1.1466.115.121.1.36 DESC 'Numeric String' ) ( 1.3.6.1.4.1.1466.115.121.1.37 DESC 'Object Class Description' ) ( 1.3.6.1.4.1.1466.115.121.1.38 DESC 'OID' ) ( 1.3.6.1.4.1.1466.115.121.1.39 DESC 'Other Mailbox' ) ( 1.3.6.1.4.1.1466.115.121.1.40 DESC 'Octet String' ) ( 1.3.6.1.4.1.1466.115.121.1.41 DESC 'Postal Address' ) ( 1.3.6.1.4.1.1466.115.121.1.42 DESC 'Protocol Information' ) ( 1.3.6.1.4.1.1466.115.121.1.43 DESC 'Presentation Address' ) ( 1.3.6.1.4.1.1466.115.121.1.44 DESC 'Printable String' ) ( 1.3.6.1.4.1.1466.115.121.1.11 DESC 'Country String' ) ( 1.3.6.1.4.1.1466.115.121.1.45 DESC 'SubtreeSpecification' ) ( 1.3.6.1.4.1.1466.115.121.1.49 DESC 'Supported Algorithm' X-BINARY-TRANSFER-REQUIRED 'TRUE' X-NOT-HUMAN-READABLE 'TRUE' ) ( 1.3.6.1.4.1.1466.115.121.1.50 DESC 'Telephone Number' ) ( 1.3.6.1.4.1.1466.115.121.1.51 DESC 'Teletex Terminal Identifier' ) ( 1.3.6.1.4.1.1466.115.121.1.52 DESC 'Telex Number' ) ( 1.3.6.1.4.1.1466.115.121.1.54 DESC 'LDAP Syntax Description' ) ( 1.3.6.1.4.1.1466.115.121.1.55 DESC 'Modify Rights' ) ( 1.3.6.1.4.1.1466.115.121.1.56 DESC 'LDAP Schema Definition' ) ( 1.3.6.1.4.1.1466.115.121.1.57 DESC 'LDAP Schema Description' ) ( 1.3.6.1.4.1.1466.115.121.1.58 DESC 'Substring Assertion' ) ( 1.3.6.1.4.1.4203.666.11.10.2.2 DESC 'AttributeCertificate Exact Assertion' ) ( 1.3.6.1.4.1.4203.666.11.10.2.3 DESC 'AttributeCertificate Assertion' ) ( 1.3.6.1.4.1.4203.666.11.2.1 DESC 'CSN' ) ( 1.3.6.1.4.1.4203.666.11.2.4 DESC 'CSN SID' ) ( 1.3.6.1.4.1.4203.1.1.1 DESC 'OpenLDAP void' ) ( 1.3.6.1.4.1.4203.666.2.7 DESC 'OpenLDAP authz' ) ( 1.3.6.1.4.1.4203.666.4.4 NAME 'directoryStringApproxMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 1.3.6.1.4.1.4203.666.4.5 NAME 'IA5StringApproxMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 2.5.13.0 NAME 'objectIdentifierMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ( 2.5.13.1 NAME 'distinguishedNameMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 1.3.6.1.4.1.4203.666.4.9 NAME 'dnSubtreeMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 1.3.6.1.4.1.4203.666.4.8 NAME 'dnOneLevelMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 1.3.6.1.4.1.4203.666.4.10 NAME 'dnSubordinateMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 1.3.6.1.4.1.4203.666.4.11 NAME 'dnSuperiorMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.5.13.2 NAME 'caseIgnoreMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.5.13.3 NAME 'caseIgnoreOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.5.13.4 NAME 'caseIgnoreSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ( 2.5.13.5 NAME 'caseExactMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.5.13.6 NAME 'caseExactOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.5.13.7 NAME 'caseExactSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ( 2.5.13.8 NAME 'numericStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) ( 2.5.13.9 NAME 'numericStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.36 ) ( 2.5.13.10 NAME 'numericStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ( 2.5.13.11 NAME 'caseIgnoreListMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.41 ) ( 2.5.13.12 NAME 'caseIgnoreListSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ( 2.5.13.13 NAME 'booleanMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 ) ( 2.5.13.14 NAME 'integerMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ( 2.5.13.15 NAME 'integerOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ( 2.5.13.16 NAME 'bitStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.6 ) ( 2.5.13.17 NAME 'octetStringMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) ( 2.5.13.18 NAME 'octetStringOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) ( 2.5.13.19 NAME 'octetStringSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 ) ( 2.5.13.20 NAME 'telephoneNumberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.50 ) ( 2.5.13.21 NAME 'telephoneNumberSubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.58 ) ( 2.5.13.22 NAME 'presentationAddressMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.43 ) ( 2.5.13.23 NAME 'uniqueMemberMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.34 ) ( 2.5.13.24 NAME 'protocolInformationMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.42 ) ( 2.5.13.27 NAME 'generalizedTimeMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ( 2.5.13.28 NAME 'generalizedTimeOrderingMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 ) ( 2.5.13.29 NAME 'integerFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ( 2.5.13.30 NAME 'objectIdentifierFirstComponentMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ( 2.5.13.45 NAME 'attributeCertificateExactMatch' SYNTAX 1.3.6.1.4.1.4203.666.11.10.2.2 ) ( 2.5.13.46 NAME 'attributeCertificateMatch' SYNTAX 1.3.6.1.4.1.4203.666.11.10.2.3 ) ( 1.3.6.1.4.1.1466.109.114.1 NAME 'caseExactIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 1.3.6.1.4.1.1466.109.114.2 NAME 'caseIgnoreIA5Match' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 1.3.6.1.4.1.1466.109.114.3 NAME 'caseIgnoreIA5SubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 1.3.6.1.4.1.4203.1.2.1 NAME 'caseExactIA5SubstringsMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 ) ( 1.2.840.113556.1.4.803 NAME 'integerBitAndMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ( 1.2.840.113556.1.4.804 NAME 'integerBitOrMatch' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 ) ( 1.3.6.1.4.1.4203.666.11.2.2 NAME 'CSNMatch' SYNTAX 1.3.6.1.4.1.4203.666.11.2.1 ) ( 1.3.6.1.4.1.4203.666.11.2.3 NAME 'CSNOrderingMatch' SYNTAX 1.3.6.1.4.1.4203.666.11.2.1 ) ( 1.3.6.1.4.1.4203.666.11.2.5 NAME 'CSNSIDMatch' SYNTAX 1.3.6.1.4.1.4203.666.11.2.4 ) ( 1.3.6.1.4.1.4203.666.4.12 NAME 'authzMatch' SYNTAX 1.3.6.1.4.1.4203.666.2.7 ) 1.3.6.1.4.1.1466.115.121.1.40 ( 2.5.4.0 NAME 'objectClass' DESC 'RFC4512: object classes of the entity' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ( 2.5.21.9 NAME 'structuralObjectClass' DESC 'RFC4512: structural object class of entry' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 2.5.18.1 NAME 'createTimestamp' DESC 'RFC4512: time which object was created' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 2.5.18.2 NAME 'modifyTimestamp' DESC 'RFC4512: time which object was last modified' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 2.5.18.3 NAME 'creatorsName' DESC 'RFC4512: name of creator' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 2.5.18.4 NAME 'modifiersName' DESC 'RFC4512: name of last modifier' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 2.5.18.9 NAME 'hasSubordinates' DESC 'X.501: entry has children' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 2.5.18.10 NAME 'subschemaSubentry' DESC 'RFC4512: name of controlling subschema entry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.1.20 NAME 'entryDN' DESC 'DN of the entry' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.4.1.4203.666.1.7 NAME 'entryCSN' DESC 'change sequence number of the entry content' EQUALITY CSNMatch ORDERING CSNOrderingMatch SYNTAX 1.3.6.1.4.1.4203.666.11.2.1{64} SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.4.1.4203.666.1.13 NAME 'namingCSN' DESC 'change sequence number of the entry naming (RDN)' EQUALITY CSNMatch ORDERING CSNOrderingMatch SYNTAX 1.3.6.1.4.1.4203.666.11.2.1{64} SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.4.1.4203.666.1.23 NAME 'syncreplCookie' DESC 'syncrepl Cookie for shadow copy' EQUALITY octetStringMatch ORDERING octetStringOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.25 NAME 'contextCSN' DESC 'the largest committed CSN of a context' EQUALITY CSNMatch ORDERING CSNOrderingMatch SYNTAX 1.3.6.1.4.1.4203.666.11.2.1{64} NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.1466.101.120.6 NAME 'altServer' DESC 'RFC4512: alternative servers' SYNTAX 1.3.6.1.4.1.1466.115.121.1.26 USAGE dSAOperation ) ( 1.3.6.1.4.1.1466.101.120.5 NAME 'namingContexts' DESC 'RFC4512: naming contexts' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 USAGE dSAOperation ) ( 1.3.6.1.4.1.1466.101.120.13 NAME 'supportedControl' DESC 'RFC4512: supported controls' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) ( 1.3.6.1.4.1.1466.101.120.7 NAME 'supportedExtension' DESC 'RFC4512: supported extended operations' SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) ( 1.3.6.1.4.1.1466.101.120.15 NAME 'supportedLDAPVersion' DESC 'RFC4512: supported LDAP versions' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 USAGE dSAOperation ) ( 1.3.6.1.4.1.1466.101.120.14 NAME 'supportedSASLMechanisms' DESC 'RFC4512: supported SASL mechanisms'SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.1.3.5 NAME 'supportedFeatures' DESC 'RFC4512: features supported by the server' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.10 NAME 'monitorContext' DESC 'monitor context' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.1.12.2.1 NAME 'configContext' DESC 'config context' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 EQUALITY distinguishedNameMatch SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.1.4 NAME 'vendorName' DESC 'RFC3045: name of implementation vendor' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.1.5 NAME 'vendorVersion' DESC 'RFC3045: version of implementation' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 2.5.18.5 NAME 'administrativeRole' DESC 'RFC3672: administrative role' EQUALITY objectIdentifierMatch USAGE directoryOperation SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 ) ( 2.5.18.6 NAME 'subtreeSpecification' DESC 'RFC3672: subtree specification' SINGLE-VALUE USAGE directoryOperation SYNTAX 1.3.6.1.4.1.1466.115.121.1.45 ) ( 2.5.21.1 NAME 'dITStructureRules' DESC 'RFC4512: DIT structure rules' EQUALITY integerFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.17 USAGE directoryOperation ) ( 2.5.21.2 NAME 'dITContentRules' DESC 'RFC4512: DIT content rules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.16 USAGE directoryOperation ) ( 2.5.21.4 NAME 'matchingRules' DESC 'RFC4512: matching rules' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.30 USAGE directoryOperation ) ( 2.5.21.5 NAME 'attributeTypes' DESC 'RFC4512: attribute types' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.3 USAGE directoryOperation ) ( 2.5.21.6 NAME 'objectClasses' DESC 'RFC4512: object classes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.37 USAGE directoryOperation ) ( 2.5.21.7 NAME 'nameForms' DESC 'RFC4512: name forms ' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.35 USAGE directoryOperation ) ( 2.5.21.8 NAME 'matchingRuleUse' DESC 'RFC4512: matching rule uses' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.31 USAGE directoryOperation ) ( 1.3.6.1.4.1.1466.101.120.16 NAME 'ldapSyntaxes' DESC 'RFC4512: LDAP syntaxes' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.54 USAGE directoryOperation ) ( 2.5.4.1 NAME ( 'aliasedObjectName' 'aliasedEntryName' ) DESC 'RFC4512: name of aliased object' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) ( 2.16.840.1.113730.3.1.34 NAME 'ref' DESC 'RFC3296: subordinate referral URL' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 USAGE distributedOperation ) ( 1.3.6.1.4.1.4203.1.3.1 NAME 'entry' DESC 'OpenLDAP ACL entry pseudo-attribute' SYNTAX 1.3.6.1.4.1.4203.1.1.1 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.1.3.2 NAME 'children' DESC 'OpenLDAP ACL children pseudo-attribute' SYNTAX 1.3.6.1.4.1.4203.1.1.1 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.8 NAME ( 'authzTo' 'saslAuthzTo' ) DESC 'proxy authorization targets' EQUALITY authzMatch SYNTAX 1.3.6.1.4.1.4203.666.2.7 X-ORDERED 'VALUES' USAGE distributedOperation ) ( 1.3.6.1.4.1.4203.666.1.9 NAME ( 'authzFrom' 'saslAuthzFrom' ) DESC 'proxy authorization sources' EQUALITY authzMatch SYNTAX 1.3.6.1.4.1.4203.666.2.7 X-ORDERED 'VALUES' USAGE distributedOperation ) ( 1.3.6.1.4.1.1466.101.119.3 NAME 'entryTtl' DESC 'RFC2589: entry time-to-live' SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.1466.101.119.4 NAME 'dynamicSubtrees' DESC 'RFC2589: dynamic subtrees' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION USAGE dSAOperation ) ( 2.5.4.49 NAME 'distinguishedName' DESC 'RFC4519: common supertype of DN attributes' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 ) ( 2.5.4.41 NAME 'name' DESC 'RFC4519: common supertype of name attributes' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} ) ( 0.9.2342.19200300.100.1.1 NAME ( 'uid' 'userid' ) DESC 'RFC4519: user identifier' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{256} ) ( 1.3.6.1.1.1.1.0 NAME 'uidNumber' DESC 'RFC2307: An integer uniquely identifying a user in an administrative domain' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( 1.3.6.1.1.1.1.1 NAME 'gidNumber' DESC 'RFC2307: An integer uniquely identifying a group in an administrative domain' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( 2.5.4.35 NAME 'userPassword' DESC 'RFC4519/2307: password of user' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} ) ( 1.3.6.1.4.1.250.1.57 NAME 'labeledURI' DESC 'RFC2079: Uniform Resource Identifier with optional label' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 2.5.4.13 NAME 'description' DESC 'RFC4519: descriptive information' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024} ) ( 1.3.6.1.4.1.1466.101.120.111 NAME 'extensibleObject' DESC 'RFC4512: extensible object' SUP top AUXILIARY ) ( 1.3.6.1.4.1.4203.1.4.1 NAME ( 'OpenLDAProotDSE' 'LDAProotDSE' ) DESC 'OpenLDAP Root DSE object' SUP top STRUCTURAL MAY cn ) ( 1.3.6.1.4.1.1466.101.119.2 NAME 'dynamicObject' DESC 'RFC2589: Dynamic Object' SUP top AUXILIARY ) ( 1.3.6.1.4.1.4203.666.3.4 NAME 'glue' DESC 'Glue Entry' SUP top STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.3.5 NAME 'syncConsumerSubentry' DESC 'Persistent Info for SyncRepl Consumer' AUXILIARY MAY syncreplCookie ) ( 1.3.6.1.4.1.4203.666.3.6 NAME 'syncProviderSubentry' DESC 'Persistent Info for SyncRepl Producer' AUXILIARY MAY contextCSN ) 1.3.6.1.4.1.1466.20037 1.3.6.1.4.1.4203.1.5.1 1.3.6.1.4.1.4203.1.5.2 1.3.6.1.4.1.4203.1.5.3 1.3.6.1.4.1.4203.1.5.4 1.3.6.1.4.1.4203.1.5.5 1.3.6.1.4.1.4203.1.9.1.1 1.3.6.1.4.1.4203.1.9.1.2 1.3.6.1.4.1.4203.1.9.1.3 1.3.6.1.4.1.4203.1.9.1.4 ( 1.3.6.1.4.1.4203.666.1.5 NAME 'OpenLDAPaci' DESC 'OpenLDAP access control information (experimental)' EQUALITY OpenLDAPaciMatch SYNTAX 1.3.6.1.4.1.4203.666.2.1 USAGE directoryOperation ) ( 1.3.6.1.4.1.4203.666.4.2 NAME 'OpenLDAPaciMatch' SYNTAX 1.3.6.1.4.1.4203.666.2.1 ) ( 1.3.6.1.4.1.4203.666.2.1 DESC 'OpenLDAP Experimental ACI' ) 1.3.6.1.4.1.4203.666.2.1 1.3.6.1.4.1.4203.666.1.55 1.3.6.1.4.1.4203.666.3.16 ( 1.3.6.1.4.1.4203.666.1.55.1 NAME 'monitoredInfo' DESC 'monitored info' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{32768} NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.2 NAME 'managedInfo' DESC 'monitor managed info' SUP name ) ( 1.3.6.1.4.1.4203.666.1.55.3 NAME 'monitorCounter' DESC 'monitor counter' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.4 NAME 'monitorOpCompleted' DESC 'monitor completed operations' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.5 NAME 'monitorOpInitiated' DESC 'monitor initiated operations' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.6 NAME 'monitorConnectionNumber' DESC 'monitor connection number' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.7 NAME 'monitorConnectionAuthzDN' DESC 'monitor connection authorization DN' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.8 NAME 'monitorConnectionLocalAddress' DESC 'monitor connection local address' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.9 NAME 'monitorConnectionPeerAddress' DESC 'monitor connection peer address' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.10 NAME 'monitorTimestamp' DESC 'monitor timestamp' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.11 NAME 'monitorOverlay' DESC 'name of overlays defined for a given database' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.12 NAME 'readOnly' DESC 'read/write status of a given database' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.13 NAME 'restrictedOperation' DESC 'name of restricted operation for a given database' SUP managedInfo ) ( 1.3.6.1.4.1.4203.666.1.55.14 NAME 'monitorConnectionProtocol' DESC 'monitor connection protocol' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.15 NAME 'monitorConnectionOpsReceived' DESC 'monitor number of operations received by the connection' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.16 NAME 'monitorConnectionOpsExecuting' DESC 'monitor number of operations in execution within the connection' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.17 NAME 'monitorConnectionOpsPending' DESC 'monitor number of pending operations within the connection' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.18 NAME 'monitorConnectionOpsCompleted' DESC 'monitor number of operations completed within the connection' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.19 NAME 'monitorConnectionGet' DESC 'number of times connection_get() was called so far' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.20 NAME 'monitorConnectionRead' DESC 'number of times connection_read() was called so far' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.21 NAME 'monitorConnectionWrite' DESC 'number of times connection_write() was called so far' SUP monitorCounter NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.22 NAME 'monitorConnectionMask' DESC 'monitor connection mask' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.23 NAME 'monitorConnectionListener' DESC 'monitor connection listener' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.24 NAME 'monitorConnectionPeerDomain' DESC 'monitor connection peer domain' SUP monitoredInfo NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.25 NAME 'monitorConnectionStartTime' DESC 'monitor connection start time' SUP monitorTimestamp SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.26 NAME 'monitorConnectionActivityTime' DESC 'monitor connection activity time' SUP monitorTimestamp SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.27 NAME 'monitorIsShadow' DESC 'TRUE if the database is shadow' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.28 NAME 'monitorUpdateRef' DESC 'update referral for shadow databases' SUP monitoredInfo SINGLE-VALUE USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.29 NAME 'monitorRuntimeConfig' DESC 'TRUE if component allows runtime configuration' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.1.55.30 NAME 'monitorSuperiorDN' DESC 'monitor superior DN' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.3.16.1 NAME 'monitor' DESC 'OpenLDAP system monitoring' SUP top STRUCTURAL MUST cn MAY ( description $ seeAlso $ labeledURI $ monitoredInfo $ managedInfo $ monitorOverlay ) ) ( 1.3.6.1.4.1.4203.666.3.16.2 NAME 'monitorServer' DESC 'Server monitoring root entry' SUP monitor STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.3.16.3 NAME 'monitorContainer' DESC 'monitor container class' SUP monitor STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.3.16.4 NAME 'monitorCounterObject' DESC 'monitor counter class' SUP monitor STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.3.16.5 NAME 'monitorOperation' DESC 'monitor operation class' SUP monitor STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.3.16.6 NAME 'monitorConnection' DESC 'monitor connection class' SUP monitor STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.3.16.7 NAME 'managedObject' DESC 'monitor managed entity class' SUP monitor STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.3.16.8 NAME 'monitoredObject' DESC 'monitor monitored entity class' SUP monitor STRUCTURAL ) 1.3.6.1.4.1.4203.666.11.3 1.3.6.1.4.1.4203.666.11.6.3 1.3.6.1.4.1.4203.666.11.6.1 1.3.6.1.4.1.4203.666.11.5.3.1 ( 1.3.6.1.4.1.4203.666.11.5.3.1 DESC 'Control' ) ( 1.3.6.1.4.1.4203.666.11.5.1.1 NAME 'reqDN' DESC 'Target DN of request' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.2 NAME 'reqStart' DESC 'Start time of request' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.3 NAME 'reqEnd' DESC 'End time of request' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.4 NAME 'reqType' DESC 'Type of request' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.5 NAME 'reqSession' DESC 'Session ID of request' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.6 NAME 'reqAuthzID' DESC 'Authorization ID of requestor' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.7 NAME 'reqResult' DESC 'Result code of request' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX OMsInteger SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.8 NAME 'reqMessage' DESC 'Error text of request' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX OMsDirectoryString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.9 NAME 'reqReferral' DESC 'Referrals returned for request' SUP labeledURI ) ( 1.3.6.1.4.1.4203.666.11.5.1.10 NAME 'reqControls' DESC 'Request controls' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.4203.666.11.5.3.1 X-ORDERED 'VALUES' ) ( 1.3.6.1.4.1.4203.666.11.5.1.11 NAME 'reqRespControls' DESC 'Response controls of request' EQUALITY objectIdentifierFirstComponentMatch SYNTAX 1.3.6.1.4.1.4203.666.11.5.3.1 X-ORDERED 'VALUES' ) ( 1.3.6.1.4.1.4203.666.11.5.1.12 NAME 'reqId' DESC 'ID of Request to Abandon' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX OMsInteger SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.13 NAME 'reqVersion' DESC 'Protocol version of Bind request' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX OMsInteger SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.14 NAME 'reqMethod' DESC 'Bind method of request' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.15 NAME 'reqAssertion' DESC 'Compare Assertion of request' SYNTAX OMsDirectoryString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.16 NAME 'reqMod' DESC 'Modifications of request' EQUALITY octetStringMatch SUBSTR octetStringSubstringsMatch SYNTAX OMsOctetString ) ( 1.3.6.1.4.1.4203.666.11.5.1.17 NAME 'reqOld' DESC 'Old values of entry before request completed' EQUALITY octetStringMatch SUBSTR octetStringSubstringsMatch SYNTAX OMsOctetString ) ( 1.3.6.1.4.1.4203.666.11.5.1.18 NAME 'reqNewRDN' DESC 'New RDN of request' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.19 NAME 'reqDeleteOldRDN' DESC 'Delete old RDN' EQUALITY booleanMatch SYNTAX OMsBoolean SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.20 NAME 'reqNewSuperior' DESC 'New superior DN of request' EQUALITY distinguishedNameMatch SYNTAX OMsDN SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.21 NAME 'reqScope' DESC 'Scope of request' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.22 NAME 'reqDerefAliases' DESC 'Disposition of Aliases in request' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.23 NAME 'reqAttrsOnly' DESC 'Attributes and values of request' EQUALITY booleanMatch SYNTAX OMsBoolean SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.24 NAME 'reqFilter' DESC 'Filter of request' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX OMsDirectoryString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.25 NAME 'reqAttr' DESC 'Attributes of request' EQUALITY caseIgnoreMatch SYNTAX OMsDirectoryString ) ( 1.3.6.1.4.1.4203.666.11.5.1.26 NAME 'reqSizeLimit' DESC 'Size limit of request' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX OMsInteger SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.27 NAME 'reqTimeLimit' DESC 'Time limit of request' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX OMsInteger SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.28 NAME 'reqEntries' DESC 'Number of entries returned' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX OMsInteger SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.29 NAME 'reqData' DESC 'Data of extended request' EQUALITY octetStringMatch SUBSTR octetStringSubstringsMatch SYNTAX OMsOctetString SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.5.1.30 NAME 'auditContext' DESC 'DN of auditContainer' SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) ( 1.3.6.1.4.1.4203.666.11.5.2.0 NAME 'auditContainer' DESC 'AuditLog container' SUP top STRUCTURAL MAY ( cn $ reqStart $ reqEnd ) ) ( 1.3.6.1.4.1.4203.666.11.5.2.1 NAME 'auditObject' DESC 'OpenLDAP request auditing' SUP top STRUCTURAL MUST ( reqStart $ reqType $ reqSession ) MAY ( reqDN $ reqAuthzID $ reqControls $ reqRespControls $ reqEnd $ reqResult $ reqMessage $ reqReferral ) ) ( 1.3.6.1.4.1.4203.666.11.5.2.2 NAME 'auditReadObject' DESC 'OpenLDAP read request record' SUP auditObject STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.11.5.2.3 NAME 'auditWriteObject' DESC 'OpenLDAP write request record' SUP auditObject STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.11.5.2.4 NAME 'auditAbandon' DESC 'Abandon operation' SUP auditObject STRUCTURAL MUST reqId ) ( 1.3.6.1.4.1.4203.666.11.5.2.5 NAME 'auditAdd' DESC 'Add operation' SUP auditWriteObject STRUCTURAL MUST reqMod ) ( 1.3.6.1.4.1.4203.666.11.5.2.6 NAME 'auditBind' DESC 'Bind operation' SUP auditObject STRUCTURAL MUST ( reqVersion $ reqMethod ) ) ( 1.3.6.1.4.1.4203.666.11.5.2.7 NAME 'auditCompare' DESC 'Compare operation' SUP auditReadObject STRUCTURAL MUST reqAssertion ) ( 1.3.6.1.4.1.4203.666.11.5.2.8 NAME 'auditDelete' DESC 'Delete operation' SUP auditWriteObject STRUCTURAL MAY reqOld ) ( 1.3.6.1.4.1.4203.666.11.5.2.9 NAME 'auditModify' DESC 'Modify operation' SUP auditWriteObject STRUCTURAL MAY reqOld MUST reqMod ) ( 1.3.6.1.4.1.4203.666.11.5.2.10 NAME 'auditModRDN' DESC 'ModRDN operation' SUP auditWriteObject STRUCTURAL MUST ( reqNewRDN $ reqDeleteOldRDN ) MAY ( reqNewSuperior $ reqMod $ reqOld ) ) ( 1.3.6.1.4.1.4203.666.11.5.2.11 NAME 'auditSearch' DESC 'Search operation' SUP auditReadObject STRUCTURAL MUST ( reqScope $ reqDerefAliases $ reqAttrsonly ) MAY ( reqFilter $ reqAttr $ reqEntries $ reqSizeLimit $ reqTimeLimit ) ) ( 1.3.6.1.4.1.4203.666.11.5.2.12 NAME 'auditExtended' DESC 'Extended operation' SUP auditObject STRUCTURAL MAY reqData ) ( 1.3.6.1.4.1.4203.666.1.57 NAME ( 'entryExpireTimestamp' ) DESC 'RFC2589 OpenLDAP extension: expire time of a dynamic object, computed as now + entryTtl' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE dSAOperation ) 1.3.6.1.4.1.4203.666.5.16 ( 1.2.840.113556.1.2.102 NAME 'memberOf' DESC 'Group that the entry belongs to' SYNTAX '1.3.6.1.4.1.1466.115.121.1.12' EQUALITY distinguishedNameMatch USAGE dSAOperation X-ORIGIN 'iPlanet Delegated Administrator' ) ( 1.3.6.1.4.1.42.2.27.8.1.16 NAME ( 'pwdChangedTime' ) DESC 'The time the password was last changed' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.4.1.42.2.27.8.1.17 NAME ( 'pwdAccountLockedTime' ) DESC 'The time an user account was locked' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 SINGLE-VALUE USAGE directoryOperation ) ( 1.3.6.1.4.1.42.2.27.8.1.19 NAME ( 'pwdFailureTime' ) DESC 'The timestamps of the last consecutive authentication failures' EQUALITY generalizedTimeMatch ORDERING generalizedTimeOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.4.1.42.2.27.8.1.20 NAME ( 'pwdHistory' ) DESC 'The history of users passwords' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.4.1.42.2.27.8.1.21 NAME ( 'pwdGraceUseTime' ) DESC 'The timestamps of the grace login once the password has expired' EQUALITY generalizedTimeMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.24 NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.4.1.42.2.27.8.1.22 NAME ( 'pwdReset' ) DESC 'The indication that the password has been reset' EQUALITY booleanMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE USAGE directoryOperation ) ( 1.3.6.1.4.1.42.2.27.8.1.23 NAME ( 'pwdPolicySubentry' ) DESC 'The pwdPolicy subentry in effect for this object' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE USAGE directoryOperation ) 1.3.6.1.4.1.42.2.27.8.5.1 1.3.6.1.4.1.42.2.27.8.5.1 1.3.6.1.4.1.4203.666.11.9.1 ( PCacheAttributes:1 NAME 'pcacheQueryID' DESC 'ID of query the entry belongs to, formatted as a UUID' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{64} NO-USER-MODIFICATION USAGE directoryOperation ) ( PCacheAttributes:2 NAME 'pcacheQueryURL' DESC 'URI describing a cached query' EQUALITY caseExactMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 NO-USER-MODIFICATION USAGE directoryOperation ) ( 1.3.6.1.4.1.4203.666.11.4.3.0 NAME ( 'errAbsObject' ) SUP top ABSTRACT MUST ( errCode ) MAY ( cn $ description $ errOp $ errText $ errSleepTime $ errMatchedDN $ errUnsolicitedOID $ errUnsolicitedData $ errDisconnect ) ) ( 1.3.6.1.4.1.4203.666.11.4.3.1 NAME ( 'errObject' ) SUP errAbsObject STRUCTURAL ) ( 1.3.6.1.4.1.4203.666.11.4.3.2 NAME ( 'errAuxObject' ) SUP errAbsObject AUXILIARY ) ( 1.3.6.1.4.1.4203.666.11.4.1.1 NAME ( 'errCode' ) DESC 'LDAP error code' EQUALITY integerMatch ORDERING integerOrderingMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.4.1.2 NAME ( 'errOp' ) DESC 'Operations the errObject applies to' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 ) ( 1.3.6.1.4.1.4203.666.11.4.1.3 NAME ( 'errText' ) DESC 'LDAP error textual description' EQUALITY caseIgnoreMatch SUBSTR caseIgnoreSubstringsMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.15 SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.4.1.4 NAME ( 'errSleepTime' ) DESC 'Time to wait before returning the error' EQUALITY integerMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.27 SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.4.1.5 NAME ( 'errMatchedDN' ) DESC 'Value to be returned as matched DN' EQUALITY distinguishedNameMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.12 SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.4.1.6 NAME ( 'errUnsolicitedOID' ) DESC 'OID to be returned within unsolicited response' EQUALITY objectIdentifierMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.38 SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.4.1.7 NAME ( 'errUnsolicitedData' ) DESC 'Data to be returned within unsolicited response' SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 SINGLE-VALUE ) ( 1.3.6.1.4.1.4203.666.11.4.1.8 NAME ( 'errDisconnect' ) DESC 'Disconnect without notice' SYNTAX 1.3.6.1.4.1.1466.115.121.1.7 SINGLE-VALUE ) 1.3.6.1.4.1.4203.666.5.14 1.3.6.1.4.1.1466.115.121.1.36 From yamakasi.014 at gmail.com Fri Mar 6 16:05:34 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 6 Mar 2015 17:05:34 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <54F9CAB4.9060808@redhat.com> References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> Message-ID: OK, understood. But when a webservice does execute a command (from scripting) to a SVR record and the first is not reacable, would it try to do it again or will handle DNS this in front of it ? I do a kinit against an IPA server using a keytab after I first checked if the user was able to auth himself using his ldap credentials, if so, this kinit exec is fired and I do some CURL stuff to the IPA server. That's why I wanted a loadbalancer, the loadbalancer sees if a server is down and doesn't even try to direct any of the commands to it... I'm not sure if the SRV will handle this well when doing these command from PHP for an example. Building in extra checks in front could be done but it not ideal as a loadbalancer can handle such things much better. Thanks! Cheers, Matt 2015-03-06 16:41 GMT+01:00 Dmitri Pal : > On 03/06/2015 10:24 AM, Matt . wrote: >> >> Hi, >> >> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >> SRV won't fit here sorry to say. >> >> I auth users, so their keytab should be the same between two masters I >> believe ? > > > Each entity in Kerberos exchange has its own identity and key. > If you send a ticket that is destined to service A instead to service B it > would not work unless they share the same keys and identity. Sharinf same > keys and identities between the servers just would not work with IPA. > Keep in mind that IPA clients and server need to work and fail over if you > do not have any load balancers and this is the common case. You are trying > to add one where it is really not needed creating overhead for yourself. > > > >> >> In that case... I need to add the altnames to the certs, but I'm not >> 100% there in step 6 >> >> Thanks again! >> >> Cheers, >> >> Matthijs >> >> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>> >>> On 6.3.2015 15:39, Matt . wrote: >>>> >>>> I have 2 IPA servers where I kinit to and post to the api using >>>> curl/json. >>> >>> If we are talking purely about scripting, you can use IPA Python API. It >>> will >>> handle fail over for you even without any load balancer. That would be >>> easiest >>> way. >>> >>>> As I need redundancy and don't want to have it script managed, but one >>>> central point where I can tal to I use a loadbalancer. >>> >>> Well, if you can control clients then the easiest and most universal way >>> is to >>> use DNS SRV records and add failover logic to clients. That solution >>> works >>> even when servers are geographically distributed/in different networks >>> and >>> does not have single point of failure (the load balancer). >>> >>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>> on the IPA server because this is needed for the http service >>>> principals I need to add the loadbalancer hostname to my IPA server >>>> and make it as an ALT name to it's Certificate. >>>> >>>> As the users are the same on both servers I would asume i can use a >>>> keytab for a user against both servers from my clients. >>> >>> I'm talking about keytabs on the FreeIPA servers - services running on >>> IPA >>> server have their own keytabs too. Every service on every server has own >>> keytab with different key. >>> >>> You need to talk with Simo or some other Kerberos guru about possibility >>> of >>> sharing keytabs between IPA services. >>> >>>> Does this make it more clear ? >>> >>> I'm still not sure if you want to have human users too or just API >>> clients. >>> >>> Petr^2 Spacek >>> >>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>> >>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> But as the user is the same, I could use the same keytab for each ipa >>>>>> server ? >>>>>> >>>>>> I need to use the API indeed, so need to issue the http service. >>>>>> >>>>>> Any other options ? >>>>> >>>>> I do not really understand your use case. Could you describe it in >>>>> detail, please? >>>>> >>>>> Petr^2 Spacek >>>>> >>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>> >>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>> >>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>> can >>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>> >>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>> possible to use >>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>> >>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>> to ipa >>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>> classical load >>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>> you to mess >>>>>>> with certs and keytabs. >>>>>>> >>>>>>> -- >>>>>>> Petr^2 Spacek >>> >>> >>> -- >>> Petr Spacek @ Red Hat > > > > -- > 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 rmeggins at redhat.com Fri Mar 6 16:10:09 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 06 Mar 2015 09:10:09 -0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9CF6C.7050803@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9CF6C.7050803@linuxcoding.org> Message-ID: <54F9D161.9040208@redhat.com> On 03/06/2015 09:01 AM, Herwono W Wijaya wrote: > this result from > #strings /usr/lib/openldap/slapd | grep "1.3.6.1.4" Sorry, I should have been much more explicit about what you need to do: 1) Are you a VMWare customer with a paid support contract? If so, then contact VMWare support - ask them which LDAP controls vCenter knows about and which ones it can expect in an LDAP response. 2) Look for LDAP Control OIDs in the _vCenter_ code, not the openldap code. I can't help you here - I don't have vCenter, and I have no idea what the code/binary layout looks like on disk. For example, here is a list of well known LDAP Control OIDs: https://www.ldap.com/ldap-oid-reference - scroll down to OIDs for Controls > > On 3/6/15 10:40 PM, Rich Megginson wrote: >> On 03/06/2015 07:54 AM, Herwono W Wijaya wrote: >>> FreeIPA logs: >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=0 BIND >>> dn="uid=admin,cn=users,cn=compat,dc=server,dc=local" method=128 >>> version=3 >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 >>> dn="uid=admin,cn=users,cn=accounts,dc=server,dc=local" >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=1 SRCH >>> base="cn=users,cn=compat,dc=server,dc=local" scope=2 >>> filter="(objectClass=inetOrgPerson)" attrs="uid description >>> givenName sn mail useraccountcontrol pwdaccountlockedtime entryuuid" >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101 >>> nentries=2 etime=0 notes=P >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1 >>> >>> vCenter SSO error: >>> Error: Idm client exception: Control not found >> >> There's no error log debug level which will give us all of the >> controls received by the server or all of the controls sent back by >> the server. The TRACE level will give us some information. >> >> But the problem appears to be that vCenter is expecting some >> control. There is no way we can tell what control that might be by >> analyzing the LDAP protocol, even with wireshark. If the vCenter >> documentation does not suffice, and VMWare support is not >> forthcoming, then we might be able to reverse engineer the code. For >> example, search the code, if scripts, or use something like the >> "strings" command on binaries, to look for well known OID prefixes. >> >> For example, from dirsrv: >> # strings /usr/lib64/lib/dirsrv/libslapd.so.0.0.0|grep "1.3.6.1.4" >> 1.3.6.1.4.1.1466.115.121.1.34 >> 1.3.6.1.4.1.1466.115.121.1.12 >> 1.3.6.1.4.1.1466.115.121.1.15 >> 1.3.6.1.4.1.42.2.27.8.5.1 >> 1.3.6.1.4.1.42.2.27.9.5.2 >> ... >> >> If we can narrow down the list of possible control OIDs that vCenter >> knows about, we can perhaps figure out if 389 supports them. >> >>> >>> On 3/6/15 8:45 PM, Herwono W Wijaya wrote: >>>> sorry my mistake, okay I'll check slapd log files and try to figure >>>> out what happened >>>> >>>> On 3/6/15 8:43 PM, Martin Kosek wrote: >>>>> This is the directory on FreeIPA server that the vCenter is >>>>> authenticating useres against. >>>>> >>>>> On 03/06/2015 02:40 PM, Herwono W Wijaya wrote: >>>>>> there is no directory "/var/log/dirsrv/" in 5.5u2b version >>>>>> >>>>>> On 3/6/15 8:34 PM, Gianluca Cecchi wrote: >>>>>>> On Fri, Mar 6, 2015 at 2:12 PM, Martin Kosek >>>>>> > wrote: >>>>>>> >>>>>>> Ah, I am not sure what control do they mean. >>>>>>> >>>>>>> But in general, when, it is always interesting to check the >>>>>>> LDAP access >>>>>>> logs to see the last failed request and then try the same >>>>>>> search with >>>>>>> ldapsearch and fix things. >>>>>>> >>>>>>> Martin >>>>>>> >>>>>>> >>>>>>> see my previous e-mail: >>>>>>> >>>>>>> /var/log/dirsrv/slapd-REALM-NAME/ >>>>>>> >>>>>>> contains log and you will see which kind of queries vSphere is >>>>>>> doing. >>>>>>> >>>>>>> Gianluca >>>>>> >>>>>> -- >>>>>> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware >>>>>> vExpert 2014, 2015 >>>>>> * >>>>>> >>>>>> >>>>> >>>> >>>> -- >>>> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >>>> 2014, 2015 >>>> * >>>> >>>> >>>> >>> >>> -- >>> Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert >>> 2014, 2015 >>> * >>> >>> >>> >> >> >> > > -- > Regards, > Herwono W Wijaya > https://linuxcoding.org | *VMware vExpert 2014, 2015 > * > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianluca.cecchi at gmail.com Fri Mar 6 16:13:01 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 6 Mar 2015 17:13:01 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9CA69.6040503@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 4:40 PM, Rich Megginson wrote: > > > [06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101 nentries=2 > etime=0 notes=P > [06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND > [06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1 > > vCenter SSO error: > Error: Idm client exception: Control not found > > > There's no error log debug level which will give us all of the controls > received by the server or all of the controls sent back by the server. The > TRACE level will give us some information. > > Could it be that the "Control not found" somehow related with "page results control" as described in https://bugzilla.redhat.com/show_bug.cgi?id=558099 Is the "notes=P" in ipa logs a setting managed by the server or by the type of the query done by the client? In my past IPA 3.3.3 logs I didn't find it at the end of the log line with nentries... Just an attempt... -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Mar 6 16:23:50 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 06 Mar 2015 09:23:50 -0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> Message-ID: <54F9D496.1070302@redhat.com> On 03/06/2015 09:13 AM, Gianluca Cecchi wrote: > On Fri, Mar 6, 2015 at 4:40 PM, Rich Megginson > wrote: > >> >> >> [06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101 >> nentries=2 etime=0 notes=P >> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND >> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1 >> >> vCenter SSO error: >> Error: Idm client exception: Control not found > > There's no error log debug level which will give us all of the > controls received by the server or all of the controls sent back > by the server. The TRACE level will give us some information. > > > > Could it be that the "Control not found" somehow related with "page > results control" as described in > https://bugzilla.redhat.com/show_bug.cgi?id=558099 Could be. > > Is the "notes=P" in ipa logs a setting managed by the server or by the > type of the query done by the client? Yes. It means the client is requesting a Simple Paged Search by using that control. > In my past IPA 3.3.3 logs I didn't find it at the end of the log line > with nentries... It has everything to do with the client. The server has supported Simple Paged Search for a long time. Perhaps some newer version of the client is requesting paged results? > Just an attempt... > One more thing - does vCenter work with another LDAP server, like openldap or active directory? If so, try capturing a wireshark trace of a successful search operation, then capture a wireshark trace of a session using ipa, and we can compare them to see which controls the working server is sending back that ipa is not. -------------- next part -------------- An HTML attachment was scrubbed... URL: From root at linuxcoding.org Fri Mar 6 16:39:38 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Fri, 06 Mar 2015 23:39:38 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9D496.1070302@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9D496.1070302@redhat.com> Message-ID: <54F9D84A.6000001@linuxcoding.org> vCenter SSO works well with Univention LDAP. Here I want to make sure if FreeIPA can work with vCenter SSO, because I read it on this page: http://www.freeipa.org/page/HowTo/vsphere5_integration And thanks for the help and answer any questions from me. Have a nice day. On 3/6/15 11:23 PM, Rich Megginson wrote: > On 03/06/2015 09:13 AM, Gianluca Cecchi wrote: >> On Fri, Mar 6, 2015 at 4:40 PM, Rich Megginson > > wrote: >> >>> >>> >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101 >>> nentries=2 etime=0 notes=P >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND >>> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1 >>> >>> vCenter SSO error: >>> Error: Idm client exception: Control not found >> >> There's no error log debug level which will give us all of the >> controls received by the server or all of the controls sent back >> by the server. The TRACE level will give us some information. >> >> >> >> Could it be that the "Control not found" somehow related with "page >> results control" as described in >> https://bugzilla.redhat.com/show_bug.cgi?id=558099 > > Could be. >> >> Is the "notes=P" in ipa logs a setting managed by the server or by >> the type of the query done by the client? > > Yes. It means the client is requesting a Simple Paged Search by using > that control. > >> In my past IPA 3.3.3 logs I didn't find it at the end of the log line >> with nentries... > > It has everything to do with the client. The server has supported > Simple Paged Search for a long time. Perhaps some newer version of > the client is requesting paged results? > > >> Just an attempt... >> > > One more thing - does vCenter work with another LDAP server, like > openldap or active directory? If so, try capturing a wireshark trace > of a successful search operation, then capture a wireshark trace of a > session using ipa, and we can compare them to see which controls the > working server is sending back that ipa is not. > > -- Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From danofsatx at gmail.com Fri Mar 6 16:59:53 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Fri, 6 Mar 2015 10:59:53 -0600 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54F9CB33.3040206@redhat.com> References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> <54F95730.40408@redhat.com> <54F9C602.3080608@redhat.com> <54F9CB33.3040206@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 9:43 AM, Dmitri Pal wrote: > On 03/06/2015 10:35 AM, Dan Mossor wrote: > > > > On Fri, Mar 6, 2015 at 9:21 AM, Dmitri Pal wrote: > >> >> From your workstation can you use the demo instance >> https://ipa.demo1.freeipa.org/ipa/ui/ or it returns the same error? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> Oh, sorry, I didn't realize I was supposed to check that. For the > record, yes - I can log into the demo instance on Firefox from my > workstation. For the sake of completeness, I checked with Konquerer also > and can log in to the demo instance. > > Regards, > Dan > > > OK, so it seems that something is really broken on that server. > May be it is easier to start over - up to you. If you want to continue > troubleshooting we are here to help. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > IT WORKS! WOOT! In the steps of researching a small issue on another hypervisor, I discovered that my underlying network, while operational, was not properly configured. The IPA server and my workstation were supposed to be talking in VLAN 100 and 110, respectively. The network is temporarily configured to route every packet it receives to the proper VLAN, no matter where it originates. My workstation is indeed on VLAN 110, and is tagging the packets appropriately. The server, however, due to a bridge misconfiguration on the host, was on VLAN 1 and not sending tagged packets at all. But as the router is configured to route all appropriate packets it appeared to be operating normally. I blew away the network configuration on the host and rebuilt it again, this time ensuring that VLAN 1 was not available on that switch port, and that the packets leaving the host were tagged with VLAN 100. I brought the IPA server back up and was able to log in. So, chalk this one up to misrouted packets. I didn't even think to look there, the 401 error gave no clue that networking may be the issue. Regards, Dan Mossor -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Mar 6 17:21:33 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 06 Mar 2015 10:21:33 -0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9D84A.6000001@linuxcoding.org> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9D496.1070302@redhat.com> <54F9D84A.6000001@linuxcoding.org> Message-ID: <54F9E21D.3020206@redhat.com> On 03/06/2015 09:39 AM, Herwono W Wijaya wrote: > vCenter SSO works well with Univention LDAP. Then set up a wireshark session to capture traffic between vCenter SSO and Univention LDAP, then do the same with vCenter SSO and IPA. Then we can compare the TCP traffic dumps. > > Here I want to make sure if FreeIPA can work with vCenter SSO, because > I read it on this page: > http://www.freeipa.org/page/HowTo/vsphere5_integration > > And thanks for the help and answer any questions from me. > Have a nice day. > > On 3/6/15 11:23 PM, Rich Megginson wrote: >> On 03/06/2015 09:13 AM, Gianluca Cecchi wrote: >>> On Fri, Mar 6, 2015 at 4:40 PM, Rich Megginson >> > wrote: >>> >>>> >>>> >>>> [06/Mar/2015:21:51:15 +0700] conn=30 op=1 RESULT err=0 tag=101 >>>> nentries=2 etime=0 notes=P >>>> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 UNBIND >>>> [06/Mar/2015:21:51:15 +0700] conn=30 op=2 fd=99 closed - U1 >>>> >>>> vCenter SSO error: >>>> Error: Idm client exception: Control not found >>> >>> There's no error log debug level which will give us all of the >>> controls received by the server or all of the controls sent back >>> by the server. The TRACE level will give us some information. >>> >>> >>> >>> Could it be that the "Control not found" somehow related with "page >>> results control" as described in >>> https://bugzilla.redhat.com/show_bug.cgi?id=558099 >> >> Could be. >>> >>> Is the "notes=P" in ipa logs a setting managed by the server or by >>> the type of the query done by the client? >> >> Yes. It means the client is requesting a Simple Paged Search by >> using that control. >> >>> In my past IPA 3.3.3 logs I didn't find it at the end of the log >>> line with nentries... >> >> It has everything to do with the client. The server has supported >> Simple Paged Search for a long time. Perhaps some newer version of >> the client is requesting paged results? >> >> >>> Just an attempt... >>> >> >> One more thing - does vCenter work with another LDAP server, like >> openldap or active directory? If so, try capturing a wireshark trace >> of a successful search operation, then capture a wireshark trace of a >> session using ipa, and we can compare them to see which controls the >> working server is sending back that ipa is not. >> >> > > -- > Regards, > Herwono W Wijaya > https://linuxcoding.org | *VMware vExpert 2014, 2015 > * > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianluca.cecchi at gmail.com Fri Mar 6 18:02:03 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 6 Mar 2015 19:02:03 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9E21D.3020206@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9D496.1070302@redhat.com> <54F9D84A.6000001@linuxcoding.org> <54F9E21D.3020206@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 6:21 PM, Rich Megginson wrote: > On 03/06/2015 09:39 AM, Herwono W Wijaya wrote: > > vCenter SSO works well with Univention LDAP. > > > Then set up a wireshark session to capture traffic between vCenter SSO and > Univention LDAP, then do the same with vCenter SSO and IPA. Then we can > compare the TCP traffic dumps. > > And so we can then change the preface that at this moment explicitly contains: " Preface The environment used to write this document is based on pure vSphere 5.1, used in trial mode with vCenter server configured as a virtual appliance. " and update it covering 5.5 and hopefully 6.0 too... ;-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Mar 6 18:06:14 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 06 Mar 2015 11:06:14 -0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9D496.1070302@redhat.com> <54F9D84A.6000001@linuxcoding.org> <54F9E21D.3020206@redhat.com> Message-ID: <54F9EC96.5080702@redhat.com> On 03/06/2015 11:02 AM, Gianluca Cecchi wrote: > On Fri, Mar 6, 2015 at 6:21 PM, Rich Megginson > wrote: > > On 03/06/2015 09:39 AM, Herwono W Wijaya wrote: >> vCenter SSO works well with Univention LDAP. > > Then set up a wireshark session to capture traffic between vCenter > SSO and Univention LDAP, then do the same with vCenter SSO and > IPA. Then we can compare the TCP traffic dumps. > > > And so we can then change the preface that at this moment explicitly > contains: > " > Preface > The environment used to write this document is based on pure vSphere > 5.1, used in trial mode with vCenter server configured as a virtual > appliance. > " > and update it covering 5.5 and hopefully 6.0 too... ;-) > I'm sorry - which preface? Link? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 6 18:09:25 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Mar 2015 13:09:25 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> <54F95730.40408@redhat.com> <54F9C602.3080608@redhat.com> <54F9CB33.3040206@redhat.com> Message-ID: <54F9ED55.4020304@redhat.com> On 03/06/2015 11:59 AM, Dan Mossor wrote: > > > On Fri, Mar 6, 2015 at 9:43 AM, Dmitri Pal > wrote: > > On 03/06/2015 10:35 AM, Dan Mossor wrote: >> >> >> On Fri, Mar 6, 2015 at 9:21 AM, Dmitri Pal > > wrote: >> >> >> From your workstation can you use the demo instance >> https://ipa.demo1.freeipa.org/ipa/ui/ or it returns the same >> error? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> Oh, sorry, I didn't realize I was supposed to check that. For the >> record, yes - I can log into the demo instance on Firefox from my >> workstation. For the sake of completeness, I checked with >> Konquerer also and can log in to the demo instance. >> >> Regards, >> Dan > > OK, so it seems that something is really broken on that server. > May be it is easier to start over - up to you. If you want to > continue troubleshooting we are here to help. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > IT WORKS! WOOT! > > In the steps of researching a small issue on another hypervisor, I > discovered that my underlying network, while operational, was not > properly configured. The IPA server and my workstation were supposed > to be talking in VLAN 100 and 110, respectively. The network is > temporarily configured to route every packet it receives to the proper > VLAN, no matter where it originates. > > My workstation is indeed on VLAN 110, and is tagging the packets > appropriately. The server, however, due to a bridge misconfiguration > on the host, was on VLAN 1 and not sending tagged packets at all. But > as the router is configured to route all appropriate packets it > appeared to be operating normally. > > I blew away the network configuration on the host and rebuilt it > again, this time ensuring that VLAN 1 was not available on that switch > port, and that the packets leaving the host were tagged with VLAN 100. > I brought the IPA server back up and was able to log in. > > So, chalk this one up to misrouted packets. I didn't even think to > look there, the 401 error gave no clue that networking may be the issue. > > Regards, > Dan Mossor I am glad that this hunt is over :-) Have a nice weekend! -- 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 Fri Mar 6 18:16:39 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 06 Mar 2015 13:16:39 -0500 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> Message-ID: <54F9EF07.70807@redhat.com> On 03/06/2015 11:05 AM, Matt . wrote: > OK, understood. > > But when a webservice does execute a command (from scripting) to a SVR > record and the first is not reacable, would it try to do it again or > will handle DNS this in front of it ? > > I do a kinit against an IPA server using a keytab after I first > checked if the user was able to auth himself using his ldap > credentials, if so, this kinit exec is fired and I do some CURL stuff > to the IPA server. > > That's why I wanted a loadbalancer, the loadbalancer sees if a server > is down and doesn't even try to direct any of the commands to it... > I'm not sure if the SRV will handle this well when doing these command > from PHP for an example. Building in extra checks in front could be > done but it not ideal as a loadbalancer can handle such things much > better. OK, this makes things much more clear. Thanks for the explanation. Rob. What is our failover logic for API? For CLI we use a negotiation and then we store a cookie so as long as the whole conversation goes to the same server you should be fine. I do not think you need to re-encrypt the traffic at load balancer and thus have a cert there then if you can enforce the use of the same server in this case. The issue I anticipate is with Kerberos. I think you should not load balance the Kerberos traffic, only the API commands starting with the negotiation. Rob does that make sense for you? > > Thanks! > > Cheers, > > Matt > > 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >> On 03/06/2015 10:24 AM, Matt . wrote: >>> Hi, >>> >>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>> SRV won't fit here sorry to say. >>> >>> I auth users, so their keytab should be the same between two masters I >>> believe ? >> >> Each entity in Kerberos exchange has its own identity and key. >> If you send a ticket that is destined to service A instead to service B it >> would not work unless they share the same keys and identity. Sharinf same >> keys and identities between the servers just would not work with IPA. >> Keep in mind that IPA clients and server need to work and fail over if you >> do not have any load balancers and this is the common case. You are trying >> to add one where it is really not needed creating overhead for yourself. >> >> >> >>> In that case... I need to add the altnames to the certs, but I'm not >>> 100% there in step 6 >>> >>> Thanks again! >>> >>> Cheers, >>> >>> Matthijs >>> >>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>> On 6.3.2015 15:39, Matt . wrote: >>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>> curl/json. >>>> If we are talking purely about scripting, you can use IPA Python API. It >>>> will >>>> handle fail over for you even without any load balancer. That would be >>>> easiest >>>> way. >>>> >>>>> As I need redundancy and don't want to have it script managed, but one >>>>> central point where I can tal to I use a loadbalancer. >>>> Well, if you can control clients then the easiest and most universal way >>>> is to >>>> use DNS SRV records and add failover logic to clients. That solution >>>> works >>>> even when servers are geographically distributed/in different networks >>>> and >>>> does not have single point of failure (the load balancer). >>>> >>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>> on the IPA server because this is needed for the http service >>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>> and make it as an ALT name to it's Certificate. >>>>> >>>>> As the users are the same on both servers I would asume i can use a >>>>> keytab for a user against both servers from my clients. >>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>> IPA >>>> server have their own keytabs too. Every service on every server has own >>>> keytab with different key. >>>> >>>> You need to talk with Simo or some other Kerberos guru about possibility >>>> of >>>> sharing keytabs between IPA services. >>>> >>>>> Does this make it more clear ? >>>> I'm still not sure if you want to have human users too or just API >>>> clients. >>>> >>>> Petr^2 Spacek >>>> >>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>> Hi, >>>>>>> >>>>>>> But as the user is the same, I could use the same keytab for each ipa >>>>>>> server ? >>>>>>> >>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>> >>>>>>> Any other options ? >>>>>> I do not really understand your use case. Could you describe it in >>>>>> detail, please? >>>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>> can >>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>> possible to use >>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>> >>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>> to ipa >>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>> classical load >>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>> you to mess >>>>>>>> with certs and keytabs. >>>>>>>> >>>>>>>> -- >>>>>>>> Petr^2 Spacek >>>> >>>> -- >>>> Petr Spacek @ Red Hat >> >> >> -- >> 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 natxo.asenjo at gmail.com Fri Mar 6 18:31:56 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 6 Mar 2015 19:31:56 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9EC96.5080702@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9D496.1070302@redhat.com> <54F9D84A.6000001@linuxcoding.org> <54F9E21D.3020206@redhat.com> <54F9EC96.5080702@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 7:06 PM, Rich Megginson wrote: > On 03/06/2015 11:02 AM, Gianluca Cecchi wrote: > > On Fri, Mar 6, 2015 at 6:21 PM, Rich Megginson > wrote: > >> On 03/06/2015 09:39 AM, Herwono W Wijaya wrote: >> >> vCenter SSO works well with Univention LDAP. >> >> >> Then set up a wireshark session to capture traffic between vCenter SSO >> and Univention LDAP, then do the same with vCenter SSO and IPA. Then we >> can compare the TCP traffic dumps. >> >> > And so we can then change the preface that at this moment explicitly > contains: > " > Preface > The environment used to write this document is based on pure vSphere 5.1, > used in trial mode with vCenter server configured as a virtual appliance. > " > and update it covering 5.5 and hopefully 6.0 too... ;-) > > > I'm sorry - which preface? Link? > > http://www.freeipa.org/page/HowTo/vsphere5_integration , I think -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianluca.cecchi at gmail.com Fri Mar 6 18:34:44 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Fri, 6 Mar 2015 19:34:44 +0100 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: <54F9EC96.5080702@redhat.com> References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9D496.1070302@redhat.com> <54F9D84A.6000001@linuxcoding.org> <54F9E21D.3020206@redhat.com> <54F9EC96.5080702@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 7:06 PM, Rich Megginson wrote: > > And so we can then change the preface that at this moment explicitly > contains: > " > Preface > The environment used to write this document is based on pure vSphere 5.1, > used in trial mode with vCenter server configured as a virtual appliance. > " > and update it covering 5.5 and hopefully 6.0 too... ;-) > > > I'm sorry - which preface? Link? > > The message was for Herwono... not for you ... He/she referred " Here I want to make sure if FreeIPA can work with vCenter SSO, because I read it on this page: http://www.freeipa.org/page/HowTo/vsphere5_integration " And at the top of the doc in the link there is the note about only 5.1 tested, while the version here is 5.5u2b. Have a nice weekend, to all the list ;-) Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From root at linuxcoding.org Fri Mar 6 18:42:37 2015 From: root at linuxcoding.org (Herwono W Wijaya) Date: Sat, 07 Mar 2015 01:42:37 +0700 Subject: [Freeipa-users] Problem FreeIPA 4.1.3 for vCenter 5.5u2b SSO In-Reply-To: References: <54F9212A.4010907@linuxcoding.org> <54F95875.10007@redhat.com> <54F98B69.306@linuxcoding.org> <54F9A253.2090403@redhat.com> <54F9A6F1.40701@linuxcoding.org> <54F9A7D1.5000100@redhat.com> <54F9AE47.7050705@linuxcoding.org> <54F9AEE5.4030306@redhat.com> <54F9AF5E.9010001@linuxcoding.org> <54F9BFBB.1070101@linuxcoding.org> <54F9CA69.6040503@redhat.com> <54F9D496.1070302@redhat.com> <54F9D84A.6000001@linuxcoding.org> <54F9E21D.3020206@redhat.com> <54F9EC96.5080702@redhat.com> Message-ID: <54F9F51D.8050205@linuxcoding.org> Tomorrow I will try to capture Univention LDAP traffic with wireshark, and if possible I will try also this FreeIPA with vCenter 6. Since I became one of the private beta testers so I had vCenter 6. On 3/7/15 1:34 AM, Gianluca Cecchi wrote: > On Fri, Mar 6, 2015 at 7:06 PM, Rich Megginson > wrote: > >> >> And so we can then change the preface that at this moment >> explicitly contains: >> " >> Preface >> The environment used to write this document is based on pure >> vSphere 5.1, used in trial mode with vCenter server configured as >> a virtual appliance. >> " >> and update it covering 5.5 and hopefully 6.0 too... ;-) >> > > I'm sorry - which preface? Link? > > > The message was for Herwono... not for you ... > He/she referred > " > Here I want to make sure if FreeIPA can work with vCenter SSO, because > I read it on this page: > http://www.freeipa.org/page/HowTo/vsphere5_integration > " > > And at the top of the doc in the link there is the note about only 5.1 > tested, while the version here is 5.5u2b. > Have a nice weekend, to all the list ;-) > Gianluca > -- Regards, Herwono W Wijaya https://linuxcoding.org | *VMware vExpert 2014, 2015 * -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Mar 6 19:53:28 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 06 Mar 2015 20:53:28 +0100 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> <54F95730.40408@redhat.com> <54F9C602.3080608@redhat.com> <54F9CB33.3040206@redhat.com> Message-ID: <54FA05B8.8050402@redhat.com> On 03/06/2015 05:59 PM, Dan Mossor wrote: > > > On Fri, Mar 6, 2015 at 9:43 AM, Dmitri Pal > wrote: > > On 03/06/2015 10:35 AM, Dan Mossor wrote: >> >> >> On Fri, Mar 6, 2015 at 9:21 AM, Dmitri Pal > > wrote: >> >> >> From your workstation can you use the demo instance >> https://ipa.demo1.freeipa.org/ipa/ui/ or it returns the same error? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> >> Oh, sorry, I didn't realize I was supposed to check that. For the record, >> yes - I can log into the demo instance on Firefox from my workstation. >> For the sake of completeness, I checked with Konquerer also and can log >> in to the demo instance. >> >> Regards, >> Dan > > OK, so it seems that something is really broken on that server. > May be it is easier to start over - up to you. If you want to continue > troubleshooting we are here to help. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > IT WORKS! WOOT! > > In the steps of researching a small issue on another hypervisor, I discovered > that my underlying network, while operational, was not properly configured. The > IPA server and my workstation were supposed to be talking in VLAN 100 and 110, > respectively. The network is temporarily configured to route every packet it > receives to the proper VLAN, no matter where it originates. > > My workstation is indeed on VLAN 110, and is tagging the packets appropriately. > The server, however, due to a bridge misconfiguration on the host, was on VLAN > 1 and not sending tagged packets at all. But as the router is configured to > route all appropriate packets it appeared to be operating normally. > > I blew away the network configuration on the host and rebuilt it again, this > time ensuring that VLAN 1 was not available on that switch port, and that the > packets leaving the host were tagged with VLAN 100. I brought the IPA server > back up and was able to log in. > > So, chalk this one up to misrouted packets. I didn't even think to look there, > the 401 error gave no clue that networking may be the issue. > > Regards, > Dan Mossor Ugh, that one was nasty, I am glad you figured it out. Now, when you know what was the problem, would you maybe have some general Troubleshooting advice to http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI that would help people like you uncover the root cause easier? Thanks, Martin From guertin at middlebury.edu Fri Mar 6 20:04:11 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Fri, 6 Mar 2015 20:04:11 +0000 Subject: [Freeipa-users] Can't add AD user group to IPA group Message-ID: <1425672251562.91790@middlebury.edu> I'm on my second attempt trying to set up an IPA server with a trust relationship to our AD domain. The first attempt had inexplicable problems with winbind, so this time I've set up a RHEL7 server, and things are going better, but I'm stuck when trying to add an AD user group to an IPA group. I have already: - created an IPA group called ad_users. - created an IPA group called ad_users_external. - added ad_users_external as a member of ad_users. But the final step isn't working: ipa group-add-member ad_users_external --external "AD\IPA Users" gives: ipa: ERROR: attribute "ipaExternalMember" not allowed How can I fix this? Also, I discovered that even without adding this AD group, every AD user in our domain can SSH to the IPA server. That's convenient for the users, but not really what I'm looking for. Why aren't logins restricted to users in the ad_users group? David Guertin -------------- next part -------------- An HTML attachment was scrubbed... URL: From CWhite at skytouchtechnology.com Fri Mar 6 20:24:28 2015 From: CWhite at skytouchtechnology.com (Craig White) Date: Fri, 6 Mar 2015 20:24:28 +0000 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: <1425672251562.91790@middlebury.edu> References: <1425672251562.91790@middlebury.edu> Message-ID: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Guertin, David S. Sent: Friday, March 06, 2015 1:04 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] Can't add AD user group to IPA group I'm on my second attempt trying to set up an IPA server with a trust relationship to our AD domain. The first attempt had inexplicable problems with winbind, so this time I've set up a RHEL7 server, and things are going better, but I'm stuck when trying to add an AD user group to an IPA group. I have already: - created an IPA group called ad_users. - created an IPA group called ad_users_external. - added ad_users_external as a member of ad_users. But the final step isn't working: ipa group-add-member ad_users_external --external "AD\IPA Users" gives: ipa: ERROR: attribute "ipaExternalMember" not allowed How can I fix this? Also, I discovered that even without adding this AD group, every AD user in our domain can SSH to the IPA server. That's convenient for the users, but not really what I'm looking for. Why aren't logins restricted to users in the ad_users group? Just taking the last question... Seems the initial/default setup for IPA server is to put in an 'allow_all' rule. Thus you can actively manage HBAC but out of the box, it is essentially turned off by that rule. Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Sat Mar 7 09:37:46 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 7 Mar 2015 10:37:46 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <54F9EF07.70807@redhat.com> References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> Message-ID: Hi, I will balance with IP persistance so I think there won't be any mixing as long as that "used" server is online. 2015-03-06 19:16 GMT+01:00 Dmitri Pal : > On 03/06/2015 11:05 AM, Matt . wrote: >> >> OK, understood. >> >> But when a webservice does execute a command (from scripting) to a SVR >> record and the first is not reacable, would it try to do it again or >> will handle DNS this in front of it ? >> >> I do a kinit against an IPA server using a keytab after I first >> checked if the user was able to auth himself using his ldap >> credentials, if so, this kinit exec is fired and I do some CURL stuff >> to the IPA server. >> >> That's why I wanted a loadbalancer, the loadbalancer sees if a server >> is down and doesn't even try to direct any of the commands to it... >> I'm not sure if the SRV will handle this well when doing these command >> from PHP for an example. Building in extra checks in front could be >> done but it not ideal as a loadbalancer can handle such things much >> better. > > > OK, this makes things much more clear. Thanks for the explanation. > Rob. What is our failover logic for API? > > For CLI we use a negotiation and then we store a cookie so as long as the > whole conversation goes to the same server you should be fine. I do not > think you need to re-encrypt the traffic at load balancer and thus have a > cert there then if you can enforce the use of the same server in this case. > > The issue I anticipate is with Kerberos. I think you should not load balance > the Kerberos traffic, only the API commands starting with the negotiation. > > Rob does that make sense for you? > > >> >> Thanks! >> >> Cheers, >> >> Matt >> >> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>> >>> On 03/06/2015 10:24 AM, Matt . wrote: >>>> >>>> Hi, >>>> >>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>> SRV won't fit here sorry to say. >>>> >>>> I auth users, so their keytab should be the same between two masters I >>>> believe ? >>> >>> >>> Each entity in Kerberos exchange has its own identity and key. >>> If you send a ticket that is destined to service A instead to service B >>> it >>> would not work unless they share the same keys and identity. Sharinf same >>> keys and identities between the servers just would not work with IPA. >>> Keep in mind that IPA clients and server need to work and fail over if >>> you >>> do not have any load balancers and this is the common case. You are >>> trying >>> to add one where it is really not needed creating overhead for yourself. >>> >>> >>> >>>> In that case... I need to add the altnames to the certs, but I'm not >>>> 100% there in step 6 >>>> >>>> Thanks again! >>>> >>>> Cheers, >>>> >>>> Matthijs >>>> >>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>> >>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>> >>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>> curl/json. >>>>> >>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>> It >>>>> will >>>>> handle fail over for you even without any load balancer. That would be >>>>> easiest >>>>> way. >>>>> >>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>> central point where I can tal to I use a loadbalancer. >>>>> >>>>> Well, if you can control clients then the easiest and most universal >>>>> way >>>>> is to >>>>> use DNS SRV records and add failover logic to clients. That solution >>>>> works >>>>> even when servers are geographically distributed/in different networks >>>>> and >>>>> does not have single point of failure (the load balancer). >>>>> >>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>> on the IPA server because this is needed for the http service >>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>> and make it as an ALT name to it's Certificate. >>>>>> >>>>>> As the users are the same on both servers I would asume i can use a >>>>>> keytab for a user against both servers from my clients. >>>>> >>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>> IPA >>>>> server have their own keytabs too. Every service on every server has >>>>> own >>>>> keytab with different key. >>>>> >>>>> You need to talk with Simo or some other Kerberos guru about >>>>> possibility >>>>> of >>>>> sharing keytabs between IPA services. >>>>> >>>>>> Does this make it more clear ? >>>>> >>>>> I'm still not sure if you want to have human users too or just API >>>>> clients. >>>>> >>>>> Petr^2 Spacek >>>>> >>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>> >>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>> ipa >>>>>>>> server ? >>>>>>>> >>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>> >>>>>>>> Any other options ? >>>>>>> >>>>>>> I do not really understand your use case. Could you describe it in >>>>>>> detail, please? >>>>>>> >>>>>>> Petr^2 Spacek >>>>>>> >>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>> >>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>> >>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>> can >>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>> >>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>> possible to use >>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>> >>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>> to ipa >>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>> classical load >>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>> you to mess >>>>>>>>> with certs and keytabs. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Petr^2 Spacek >>>>> >>>>> >>>>> -- >>>>> Petr Spacek @ Red Hat >>> >>> >>> >>> -- >>> 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. > > -- > 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 Sat Mar 7 17:11:48 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 07 Mar 2015 12:11:48 -0500 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: References: <1425672251562.91790@middlebury.edu> Message-ID: <54FB3154.5060203@redhat.com> On 03/06/2015 03:24 PM, Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Guertin, David S. > *Sent:* Friday, March 06, 2015 1:04 PM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] Can't add AD user group to IPA group > > I'm on my second attempt trying to set up an IPA server with a trust > relationship to our AD domain. The first attempt had inexplicable > problems with winbind, so this time I've set up a RHEL7 server, and > things are going better, but I'm stuck when trying to add an AD user > group to an IPA group. > > I have already: > > - created an IPA group called ad_users. > > - created an IPA group called ad_users_external. > Did you create this group with --external? > - added ad_users_external as a member of ad_users. > > But the final step isn't working: > > ipa group-add-member ad_users_external --external "AD\IPA Users" > > gives: > > ipa: ERROR: attribute "ipaExternalMember" not allowed > > How can I fix this? > > Also, I discovered that even without adding this AD group, every AD > user in our domain can SSH to the IPA server. That's convenient for > the users, but not really what I'm looking for. Why aren't logins > restricted to users in the ad_users group? > > Just taking the last question... > > Seems the initial/default setup for IPA server is to put in an > 'allow_all' rule. Thus you can actively manage HBAC but out of the > box, it is essentially turned off by that rule. > > Craig > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jreg2k at gmail.com Sat Mar 7 17:12:56 2015 From: jreg2k at gmail.com (James James) Date: Sat, 7 Mar 2015 18:12:56 +0100 Subject: [Freeipa-users] Web UI customization Message-ID: Hello, I am with a ipa 3.3 server on centos 7. I want to customize the web ui user add page (to include krbprincipalexpiration field with a jquery calendar... ). I have read http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf , https://pvoborni.fedorapeople.org/api/#!/guide/Phases and http://fossies.org/dox/freeipa-4.1.3/classipalib_1_1plugins_1_1user_1_1user__add.html but I can't figure out how to do what I want .... Can somebody give me clues or examples .... Thanks ... -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Sat Mar 7 17:21:03 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 07 Mar 2015 12:21:03 -0500 Subject: [Freeipa-users] Web UI customization In-Reply-To: References: Message-ID: <54FB337F.2030602@redhat.com> On 03/07/2015 12:12 PM, James James wrote: > Hello, > > I am with a ipa 3.3 server on centos 7. > > I want to customize the web ui user add page (to include > krbprincipalexpiration field with a jquery calendar... ). I have read > > http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf , > https://pvoborni.fedorapeople.org/api/#!/guide/Phases > and > > http://fossies.org/dox/freeipa-4.1.3/classipalib_1_1plugins_1_1user_1_1user__add.html > > > but I can't figure out how to do what I want .... > > Can somebody give me clues or examples .... > > Thanks ... > > I suggest you work with Peter Vobornik on this as he has the following ticket on his plate: https://fedorahosted.org/freeipa/ticket/4347 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Sun Mar 8 05:54:22 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 8 Mar 2015 08:54:22 +0300 Subject: [Freeipa-users] how can i configure solaris10 as freeIPA 4.1.2 client Message-ID: Hi list i have working IPA server were AD users can login to IPA server how can i configure solaris 10 as IPA 4.1.2 client.? i saw many tutorials in IPA domain and got confused . Which one i need to follow currently i am trying with X86 version of solaris and later i need to try on SPARC based. Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Sun Mar 8 07:54:06 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 8 Mar 2015 10:54:06 +0300 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." Message-ID: HI i have free IPA 4.1.2 installed. my web ui always giving "Your session has expired. Please re-login." even i tried from different computer.different browsers.. how can i fix this.? -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Sun Mar 8 09:48:40 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 8 Mar 2015 12:48:40 +0300 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: References: Message-ID: Hi i checked the services and below is my output [root at kwtpocpbis01 ipa_memcached]# ps -ef | grep ipa_memcached apache 2079 1 0 11:11 ? 00:00:00 /usr/bin/memcached -d -s /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P /var/run/ipa_memcached/ipa_memcached.pid root 2801 2504 0 12:48 pts/0 00:00:00 grep --color=auto ipa_memcached [root at kwtpocpbis01 ipa_memcached]# ipactl status Directory Service: RUNNING krb5kdc Service: RUNNING kadmin Service: RUNNING named Service: RUNNING ipa_memcached Service: RUNNING httpd Service: RUNNING pki-tomcatd Service: RUNNING smb Service: RUNNING winbind Service: RUNNING ipa-otpd Service: RUNNING ipa-dnskeysyncd Service: RUNNING ipa: INFO: The ipactl command was successful On Sun, Mar 8, 2015 at 10:54 AM, Ben .T.George wrote: > HI > > i have free IPA 4.1.2 installed. > > my web ui always giving "Your session has expired. Please re-login." even > i tried from different computer.different browsers.. > > how can i fix this.? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Sun Mar 8 10:02:51 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 8 Mar 2015 13:02:51 +0300 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: References: Message-ID: this is the error mesage i am getting on httpd/error_log [Sun Mar 08 13:02:02.965470 2015] [auth_kerb:error] [pid 2922] [client 172.16.107 .250:60005] gss_accept_sec_context() failed: An unsupported mechanism was request ed (, Unknown error), referer: https://kwtpocpbis01.solaris.local/ipa/ui/ On Sun, Mar 8, 2015 at 12:48 PM, Ben .T.George wrote: > Hi i checked the services and below is my output > > [root at kwtpocpbis01 ipa_memcached]# ps -ef | grep ipa_memcached > apache 2079 1 0 11:11 ? 00:00:00 /usr/bin/memcached -d -s > /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P > /var/run/ipa_memcached/ipa_memcached.pid > root 2801 2504 0 12:48 pts/0 00:00:00 grep --color=auto > ipa_memcached > > [root at kwtpocpbis01 ipa_memcached]# ipactl status > Directory Service: RUNNING > krb5kdc Service: RUNNING > kadmin Service: RUNNING > named Service: RUNNING > ipa_memcached Service: RUNNING > httpd Service: RUNNING > pki-tomcatd Service: RUNNING > smb Service: RUNNING > winbind Service: RUNNING > ipa-otpd Service: RUNNING > ipa-dnskeysyncd Service: RUNNING > ipa: INFO: The ipactl command was successful > > > On Sun, Mar 8, 2015 at 10:54 AM, Ben .T.George > wrote: > >> HI >> >> i have free IPA 4.1.2 installed. >> >> my web ui always giving "Your session has expired. Please re-login." even >> i tried from different computer.different browsers.. >> >> how can i fix this.? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Sun Mar 8 10:17:23 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 8 Mar 2015 13:17:23 +0300 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: References: Message-ID: I enabled debugging mode on default.conf and this is what i am getting on error_log [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported mechanism was requested (, Unknown error), referer: https://kwtpocpbis01.solaris.local/ipa/ui/ [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI login_password.__call__: [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: Obtaining armor ccache: principal=HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL keytab=/etc/httpd/conf/ipa.keytab ccache=/var/run/ipa_memcached/krbcc_A_admin [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' 'HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL' [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kinit' 'admin at SOLARIS.LOCAL' '-T' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: stdout=Password for admin at SOLARIS.LOCAL: [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: principal=admin at SOLARIS.LOCAL returncode=0, stderr="" [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: Cleanup the armor ccache [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: Starting external process [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: Process finished, return code=0 [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: stdout= [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: stderr= [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: found session data in cache with id=4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: finalize_kerberos_acquisition: login_password ccache_name="FILE:/var/run/ipa_memcached/krbcc_3004" session_id="4803e184cecb42f2e326391dbb09443d" [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: reading ccache data from file "/var/run/ipa_memcached/krbcc_3004" [Sun Mar 08 13:16:29.909319 2015] [:error] [pid 3004] ipa: DEBUG: get_credential_times: principal=krbtgt/SOLARIS.LOCAL at SOLARIS.LOCAL, authtime=03/08/15 13:16:29, starttime=03/08/15 13:16:29, endtime=03/09/15 13:16:29, renew_till=01/01/70 03:00:00 [Sun Mar 08 13:16:29.909415 2015] [:error] [pid 3004] ipa: DEBUG: KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3004 endtime=1425896189 (03/09/15 13:16:29) [Sun Mar 08 13:16:29.909538 2015] [:error] [pid 3004] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1425895889 expiration=1425810989.91 (2015-03-08T13:36:29) [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store session: session_id=4803e184cecb42f2e326391dbb09443d start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 expiration_timestamp=2015-03-08T13:36:29 [Sun Mar 08 13:16:29.910004 2015] [:error] [pid 3004] ipa: DEBUG: release_ipa_ccache: KRB5CCNAME environment variable not set [Sun Mar 08 13:16:29.921259 2015] [:error] [pid 3003] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Sun Mar 08 13:16:29.921351 2015] [:error] [pid 3003] ipa: DEBUG: WSGI jsonserver_session.__call__: [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating empty session data [Sun Mar 08 13:16:29.921875 2015] [:error] [pid 3003] ipa: DEBUG: store session: session_id=4803e184cecb42f2e326391dbb09443d start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 expiration_timestamp=1970-01-01T03:00:00 [Sun Mar 08 13:16:29.922125 2015] [:error] [pid 3003] ipa: DEBUG: jsonserver_session.__call__: session_id=4803e184cecb42f2e326391dbb09443d start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 expiration_timestamp=1970-01-01T03:00:00 [Sun Mar 08 13:16:29.922191 2015] [:error] [pid 3003] ipa: DEBUG: no ccache, need login [Sun Mar 08 13:16:29.922265 2015] [:error] [pid 3003] ipa: DEBUG: jsonserver_session: 401 Unauthorized need login On Sun, Mar 8, 2015 at 1:02 PM, Ben .T.George wrote: > this is the error mesage i am getting on httpd/error_log > > [Sun Mar 08 13:02:02.965470 2015] [auth_kerb:error] [pid 2922] [client > 172.16.107 > .250:60005] > gss_accept_sec_context() failed: An unsupported mechanism was request > > ed (, Unknown error), referer: > https://kwtpocpbis01.solaris.local/ipa/ui/ > > On Sun, Mar 8, 2015 at 12:48 PM, Ben .T.George > wrote: > >> Hi i checked the services and below is my output >> >> [root at kwtpocpbis01 ipa_memcached]# ps -ef | grep ipa_memcached >> apache 2079 1 0 11:11 ? 00:00:00 /usr/bin/memcached -d -s >> /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P >> /var/run/ipa_memcached/ipa_memcached.pid >> root 2801 2504 0 12:48 pts/0 00:00:00 grep --color=auto >> ipa_memcached >> >> [root at kwtpocpbis01 ipa_memcached]# ipactl status >> Directory Service: RUNNING >> krb5kdc Service: RUNNING >> kadmin Service: RUNNING >> named Service: RUNNING >> ipa_memcached Service: RUNNING >> httpd Service: RUNNING >> pki-tomcatd Service: RUNNING >> smb Service: RUNNING >> winbind Service: RUNNING >> ipa-otpd Service: RUNNING >> ipa-dnskeysyncd Service: RUNNING >> ipa: INFO: The ipactl command was successful >> >> >> On Sun, Mar 8, 2015 at 10:54 AM, Ben .T.George >> wrote: >> >>> HI >>> >>> i have free IPA 4.1.2 installed. >>> >>> my web ui always giving "Your session has expired. Please re-login." >>> even i tried from different computer.different browsers.. >>> >>> how can i fix this.? >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Sun Mar 8 10:44:28 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 8 Mar 2015 13:44:28 +0300 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: References: Message-ID: i was inspecting the page and got below response. http://s21.postimg.org/itv5hf0h3/asdasd.jpg http://s3.postimg.org/f6knomt1f/Capture.jpg please anyone help me to solve this issue. i just want to create one local user in IPA On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George wrote: > I enabled debugging mode on default.conf and this is what i am getting on > error_log > > [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client > 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported > mechanism was requested (, Unknown error), referer: > https://kwtpocpbis01.solaris.local/ipa/ui/ > [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI > wsgi_dispatch.__call__: > [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI > login_password.__call__: > [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: > Obtaining armor ccache: > principal=HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL > keytab=/etc/httpd/conf/ipa.keytab > ccache=/var/run/ipa_memcached/krbcc_A_admin > [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: Starting > external process > [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: > args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' > 'HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL' > [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: Process > finished, return code=0 > [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: stdout= > [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: stderr= > [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: Starting > external process > [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: > args='/usr/bin/kinit' 'admin at SOLARIS.LOCAL' '-T' > '/var/run/ipa_memcached/krbcc_A_admin' > [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: Process > finished, return code=0 > [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: > stdout=Password for admin at SOLARIS.LOCAL: > [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] > [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: stderr= > [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: > principal=admin at SOLARIS.LOCAL returncode=0, stderr="" > [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: Cleanup > the armor ccache > [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: Starting > external process > [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: > args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' > [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: Process > finished, return code=0 > [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: stdout= > [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: stderr= > [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found > session cookie_id = 4803e184cecb42f2e326391dbb09443d > [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: found > session data in cache with id=4803e184cecb42f2e326391dbb09443d > [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: > finalize_kerberos_acquisition: login_password > ccache_name="FILE:/var/run/ipa_memcached/krbcc_3004" > session_id="4803e184cecb42f2e326391dbb09443d" > [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: reading > ccache data from file "/var/run/ipa_memcached/krbcc_3004" > [Sun Mar 08 13:16:29.909319 2015] [:error] [pid 3004] ipa: DEBUG: > get_credential_times: principal=krbtgt/SOLARIS.LOCAL at SOLARIS.LOCAL, > authtime=03/08/15 13:16:29, starttime=03/08/15 13:16:29, endtime=03/09/15 > 13:16:29, renew_till=01/01/70 03:00:00 > [Sun Mar 08 13:16:29.909415 2015] [:error] [pid 3004] ipa: DEBUG: > KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3004 endtime=1425896189 > (03/09/15 13:16:29) > [Sun Mar 08 13:16:29.909538 2015] [:error] [pid 3004] ipa: DEBUG: > set_session_expiration_time: duration_type=inactivity_timeout duration=1200 > max_age=1425895889 expiration=1425810989.91 (2015-03-08T13:36:29) > [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store > session: session_id=4803e184cecb42f2e326391dbb09443d > start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 > expiration_timestamp=2015-03-08T13:36:29 > [Sun Mar 08 13:16:29.910004 2015] [:error] [pid 3004] ipa: DEBUG: > release_ipa_ccache: KRB5CCNAME environment variable not set > [Sun Mar 08 13:16:29.921259 2015] [:error] [pid 3003] ipa: DEBUG: WSGI > wsgi_dispatch.__call__: > [Sun Mar 08 13:16:29.921351 2015] [:error] [pid 3003] ipa: DEBUG: WSGI > jsonserver_session.__call__: > [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found > session cookie_id = 4803e184cecb42f2e326391dbb09443d > [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no > session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating > empty session data > [Sun Mar 08 13:16:29.921875 2015] [:error] [pid 3003] ipa: DEBUG: store > session: session_id=4803e184cecb42f2e326391dbb09443d > start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 > expiration_timestamp=1970-01-01T03:00:00 > [Sun Mar 08 13:16:29.922125 2015] [:error] [pid 3003] ipa: DEBUG: > jsonserver_session.__call__: session_id=4803e184cecb42f2e326391dbb09443d > start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 > expiration_timestamp=1970-01-01T03:00:00 > [Sun Mar 08 13:16:29.922191 2015] [:error] [pid 3003] ipa: DEBUG: no > ccache, need login > [Sun Mar 08 13:16:29.922265 2015] [:error] [pid 3003] ipa: DEBUG: > jsonserver_session: 401 Unauthorized need login > > > On Sun, Mar 8, 2015 at 1:02 PM, Ben .T.George > wrote: > >> this is the error mesage i am getting on httpd/error_log >> >> [Sun Mar 08 13:02:02.965470 2015] [auth_kerb:error] [pid 2922] [client >> 172.16.107 >> .250:60005] >> gss_accept_sec_context() failed: An unsupported mechanism was request >> >> ed (, Unknown error), referer: >> https://kwtpocpbis01.solaris.local/ipa/ui/ >> >> On Sun, Mar 8, 2015 at 12:48 PM, Ben .T.George >> wrote: >> >>> Hi i checked the services and below is my output >>> >>> [root at kwtpocpbis01 ipa_memcached]# ps -ef | grep ipa_memcached >>> apache 2079 1 0 11:11 ? 00:00:00 /usr/bin/memcached -d -s >>> /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P >>> /var/run/ipa_memcached/ipa_memcached.pid >>> root 2801 2504 0 12:48 pts/0 00:00:00 grep --color=auto >>> ipa_memcached >>> >>> [root at kwtpocpbis01 ipa_memcached]# ipactl status >>> Directory Service: RUNNING >>> krb5kdc Service: RUNNING >>> kadmin Service: RUNNING >>> named Service: RUNNING >>> ipa_memcached Service: RUNNING >>> httpd Service: RUNNING >>> pki-tomcatd Service: RUNNING >>> smb Service: RUNNING >>> winbind Service: RUNNING >>> ipa-otpd Service: RUNNING >>> ipa-dnskeysyncd Service: RUNNING >>> ipa: INFO: The ipactl command was successful >>> >>> >>> On Sun, Mar 8, 2015 at 10:54 AM, Ben .T.George >>> wrote: >>> >>>> HI >>>> >>>> i have free IPA 4.1.2 installed. >>>> >>>> my web ui always giving "Your session has expired. Please re-login." >>>> even i tried from different computer.different browsers.. >>>> >>>> how can i fix this.? >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Sun Mar 8 11:30:11 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Sun, 8 Mar 2015 12:30:11 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> Message-ID: I'm reviewing some things. When I'm using a loadbalancer, which I prefer in this setup I need to have the same certificates on both servers. Maybe a wildcard for my domain could do instead of having only both fqdn's of the servers including the loadbalancer's fqdn. But the question remains, how? 2015-03-07 10:37 GMT+01:00 Matt . : > Hi, > > I will balance with IP persistance so I think there won't be any > mixing as long as that "used" server is online. > > 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >> On 03/06/2015 11:05 AM, Matt . wrote: >>> >>> OK, understood. >>> >>> But when a webservice does execute a command (from scripting) to a SVR >>> record and the first is not reacable, would it try to do it again or >>> will handle DNS this in front of it ? >>> >>> I do a kinit against an IPA server using a keytab after I first >>> checked if the user was able to auth himself using his ldap >>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>> to the IPA server. >>> >>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>> is down and doesn't even try to direct any of the commands to it... >>> I'm not sure if the SRV will handle this well when doing these command >>> from PHP for an example. Building in extra checks in front could be >>> done but it not ideal as a loadbalancer can handle such things much >>> better. >> >> >> OK, this makes things much more clear. Thanks for the explanation. >> Rob. What is our failover logic for API? >> >> For CLI we use a negotiation and then we store a cookie so as long as the >> whole conversation goes to the same server you should be fine. I do not >> think you need to re-encrypt the traffic at load balancer and thus have a >> cert there then if you can enforce the use of the same server in this case. >> >> The issue I anticipate is with Kerberos. I think you should not load balance >> the Kerberos traffic, only the API commands starting with the negotiation. >> >> Rob does that make sense for you? >> >> >>> >>> Thanks! >>> >>> Cheers, >>> >>> Matt >>> >>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>> >>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>> >>>>> Hi, >>>>> >>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>> SRV won't fit here sorry to say. >>>>> >>>>> I auth users, so their keytab should be the same between two masters I >>>>> believe ? >>>> >>>> >>>> Each entity in Kerberos exchange has its own identity and key. >>>> If you send a ticket that is destined to service A instead to service B >>>> it >>>> would not work unless they share the same keys and identity. Sharinf same >>>> keys and identities between the servers just would not work with IPA. >>>> Keep in mind that IPA clients and server need to work and fail over if >>>> you >>>> do not have any load balancers and this is the common case. You are >>>> trying >>>> to add one where it is really not needed creating overhead for yourself. >>>> >>>> >>>> >>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>> 100% there in step 6 >>>>> >>>>> Thanks again! >>>>> >>>>> Cheers, >>>>> >>>>> Matthijs >>>>> >>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>> >>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>> >>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>> curl/json. >>>>>> >>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>> It >>>>>> will >>>>>> handle fail over for you even without any load balancer. That would be >>>>>> easiest >>>>>> way. >>>>>> >>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>> central point where I can tal to I use a loadbalancer. >>>>>> >>>>>> Well, if you can control clients then the easiest and most universal >>>>>> way >>>>>> is to >>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>> works >>>>>> even when servers are geographically distributed/in different networks >>>>>> and >>>>>> does not have single point of failure (the load balancer). >>>>>> >>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>> on the IPA server because this is needed for the http service >>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>> and make it as an ALT name to it's Certificate. >>>>>>> >>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>> keytab for a user against both servers from my clients. >>>>>> >>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>> IPA >>>>>> server have their own keytabs too. Every service on every server has >>>>>> own >>>>>> keytab with different key. >>>>>> >>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>> possibility >>>>>> of >>>>>> sharing keytabs between IPA services. >>>>>> >>>>>>> Does this make it more clear ? >>>>>> >>>>>> I'm still not sure if you want to have human users too or just API >>>>>> clients. >>>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>> >>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>> ipa >>>>>>>>> server ? >>>>>>>>> >>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>> >>>>>>>>> Any other options ? >>>>>>>> >>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>> detail, please? >>>>>>>> >>>>>>>> Petr^2 Spacek >>>>>>>> >>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>> >>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>> >>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>> can >>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>> >>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>> possible to use >>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>> >>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>> to ipa >>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>> classical load >>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>> you to mess >>>>>>>>>> with certs and keytabs. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Petr^2 Spacek >>>>>> >>>>>> >>>>>> -- >>>>>> Petr Spacek @ Red Hat >>>> >>>> >>>> >>>> -- >>>> 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. >> >> -- >> 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 jhrozek at redhat.com Sun Mar 8 20:40:11 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 8 Mar 2015 21:40:11 +0100 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: References: <1425672251562.91790@middlebury.edu> Message-ID: <20150308204011.GP3477@hendrix.arn.redhat.com> On Fri, Mar 06, 2015 at 08:24:28PM +0000, Craig White wrote: > Seems the initial/default setup for IPA server is to put in an 'allow_all' rule. Thus you can actively manage HBAC but out of the box, it is essentially turned off by that rule. Yes. The default was the opposite very long time ago, you had to explicitly enable access to the box. But it was causing too many user issues. From jhrozek at redhat.com Sun Mar 8 20:42:42 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 8 Mar 2015 21:42:42 +0100 Subject: [Freeipa-users] how can i configure solaris10 as freeIPA 4.1.2 client In-Reply-To: References: Message-ID: <20150308204242.GQ3477@hendrix.arn.redhat.com> On Sun, Mar 08, 2015 at 08:54:22AM +0300, Ben .T.George wrote: > Hi list > > i have working IPA server were AD users can login to IPA server > > how can i configure solaris 10 as IPA 4.1.2 client.? > > i saw many tutorials in IPA domain and got confused . Which one i need to > follow > > currently i am trying with X86 version of solaris and later i need to try > on SPARC based. > > Regards, > Ben I haven't configured a Solaris client in some time, but IIRC this page is authoritative: http://www.freeipa.org/page/ConfiguringUnixClients From rcritten at redhat.com Sun Mar 8 20:51:08 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 08 Mar 2015 16:51:08 -0400 Subject: [Freeipa-users] how can i configure solaris10 as freeIPA 4.1.2 client In-Reply-To: <20150308204242.GQ3477@hendrix.arn.redhat.com> References: <20150308204242.GQ3477@hendrix.arn.redhat.com> Message-ID: <54FCB63C.2090405@redhat.com> Jakub Hrozek wrote: > On Sun, Mar 08, 2015 at 08:54:22AM +0300, Ben .T.George wrote: >> Hi list >> >> i have working IPA server were AD users can login to IPA server >> >> how can i configure solaris 10 as IPA 4.1.2 client.? >> >> i saw many tutorials in IPA domain and got confused . Which one i need to >> follow >> >> currently i am trying with X86 version of solaris and later i need to try >> on SPARC based. >> >> Regards, >> Ben > > I haven't configured a Solaris client in some time, but IIRC this page > is authoritative: > http://www.freeipa.org/page/ConfiguringUnixClients > I'd suggest starting with the freeipa-users mailing list archives. There are a number of threads asking the same question. There are also a couple of closed bugs on bugzilla.redhat.com related to Solaris configuration, contributed by a FreeIPA user. Those are excellent sources of information, including a fairly complete authenticated and secure DUA profile which includes a lot more than just users and groups. The IPA team has moved away from trying to provide direct support /documentation for non-Linux platforms since we don't have the in-house expertise. The documents you'll find on the wiki provide a minimalist configuration that worked for us at one time. rob From jhrozek at redhat.com Sun Mar 8 21:25:46 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 8 Mar 2015 22:25:46 +0100 Subject: [Freeipa-users] how can i configure solaris10 as freeIPA 4.1.2 client In-Reply-To: <54FCB63C.2090405@redhat.com> References: <20150308204242.GQ3477@hendrix.arn.redhat.com> <54FCB63C.2090405@redhat.com> Message-ID: <20150308212546.GS3477@hendrix.arn.redhat.com> On Sun, Mar 08, 2015 at 04:51:08PM -0400, Rob Crittenden wrote: > The IPA team has moved away from trying to provide direct support > /documentation for non-Linux platforms since we don't have the in-house > expertise. The documents you'll find on the wiki provide a minimalist > configuration that worked for us at one time. Thanks; I wasn't aware of that. Should we document that the page might not be accurate and searching freeipa-users might be a better choice on that wiki page, then? From dpal at redhat.com Mon Mar 9 00:44:48 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 08 Mar 2015 20:44:48 -0400 Subject: [Freeipa-users] how can i configure solaris10 as freeIPA 4.1.2 client In-Reply-To: <20150308212546.GS3477@hendrix.arn.redhat.com> References: <20150308204242.GQ3477@hendrix.arn.redhat.com> <54FCB63C.2090405@redhat.com> <20150308212546.GS3477@hendrix.arn.redhat.com> Message-ID: <54FCED00.3060801@redhat.com> On 03/08/2015 05:25 PM, Jakub Hrozek wrote: > On Sun, Mar 08, 2015 at 04:51:08PM -0400, Rob Crittenden wrote: >> The IPA team has moved away from trying to provide direct support >> /documentation for non-Linux platforms since we don't have the in-house >> expertise. The documents you'll find on the wiki provide a minimalist >> configuration that worked for us at one time. > Thanks; I wasn't aware of that. > > Should we document that the page might not be accurate and searching > freeipa-users might be a better choice on that wiki page, then? > We should probably add links to archived threads abd BZ to the wiki page. This would be the minimal effort. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Mar 9 00:48:00 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 08 Mar 2015 20:48:00 -0400 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: References: Message-ID: <54FCEDC0.3050403@redhat.com> On 03/08/2015 03:54 AM, Ben .T.George wrote: > HI > > i have free IPA 4.1.2 installed. > > my web ui always giving "Your session has expired. Please re-login." > even i tried from different computer.different browsers.. > > how can i fix this.? > > There was the issue with the same error message couple days ago and the problem was that IPA server network was not properly set up. Please check archives from the last week, may be it will give you some hints. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ftweedal at redhat.com Mon Mar 9 01:44:41 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 9 Mar 2015 11:44:41 +1000 Subject: [Freeipa-users] verified certificates both sides of a TLS channel In-Reply-To: <54F97420.6020601@redhat.com> References: <54F97420.6020601@redhat.com> Message-ID: <20150309014440.GN7251@dhcp-40-8.bne.redhat.com> On Fri, Mar 06, 2015 at 10:32:16AM +0100, Martin Kosek wrote: > On 03/06/2015 09:34 AM, Andrew Holway wrote: > >Hi, > > > >Were using rabbitmq to shunt bits of data around various systems to provide > >better security we would like all of our acmq connections to be authenticated > >and encrypted. > > > >I'm looking for appropriate documentation or some friendly guidance of how > >server to server SSL authentication is done with freeipa and if indeed this is > >the best way to ensure privacy in such scenarios. > > These are the best documentation sources I could find: > > Creating certs for FreeIPA hosts: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/host-certificates.html > > Creating certs for FreeIPA hosts: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/service-certificates.html > Service certificates issued as per above are usable for TLS client certificate authentication. If communications are between two host/service principals, then TLS client authentication is possible as long as the server and client software support it. It would appear that RabbitMQ supports TLS client certificate authentication: http://www.rabbitmq.com/ssl.html TLS is the best way to ensure privacy for these connections, and it also achieves authentication. Whether it is the *best* way to authenticate clients depends on what other options there are, how easy client and server are to configure the methods for, and whether it also accomplishes authorization (certificate authentication does not, at least not directly). > With these certificates, you would need to manually configure SSL-based > authentication with mod_ssl/mod_nss. Partially related user howto is > http://www.freeipa.org/page/Apache_SNI_With_Kerberos > > I wonder if RabbitMQ has GSSAPI support, that would be more easy to > configure with FreeIPA than SSL certs. > There seems to be some unofficial Kerberos (not GSSAPI) support: http://comments.gmane.org/gmane.comp.networking.rabbitmq.general/23249 Maybe there is good support for GSSAPI but I did not see it in my quick search. > Btw FreeIPA 4.2 plans to have much better support for different cert > profiles or sub-CAs that you may later use for purposes like this one. > This is highly desirable, and it is coming. FreeIPA currently issues all certificates directly from a single CA, and any certificate issued by the CA will be considered valid (as long as it is not expired, revoked, etc). At this time, application- or TLS termination-layer logic is needed to make authorisation decisions. > Ticket: > https://fedorahosted.org/freeipa/ticket/57 > > CCing Fraser from Dogtag team for reference. > > Martin From mkosek at redhat.com Mon Mar 9 07:57:58 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Mar 2015 08:57:58 +0100 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: References: Message-ID: <54FD5286.3010409@redhat.com> Thanks for all the data. So it looks like your browser properly forward the session cookie, but it is not recognized on the server even though it was stored before. Especially these lines are strange: [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store session: session_id=4803e184cecb42f2e326391dbb09443d start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 expiration_timestamp=2015-03-08T13:36:29 ... [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found session cookie_id = 4803e184cecb42f2e326391dbb09443d [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating empty session data We know that ipa_memcached is running. Can you please also check if there are no SELinux errors in /var/log/audit/audit.log preveting Apache from looking up the session data? Thanks, Martin On 03/08/2015 11:44 AM, Ben .T.George wrote: > i was inspecting the page and got below response. > > http://s21.postimg.org/itv5hf0h3/asdasd.jpg > > http://s3.postimg.org/f6knomt1f/Capture.jpg > > please anyone help me to solve this issue. i just want to create one local > user in IPA > > On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George wrote: > >> I enabled debugging mode on default.conf and this is what i am getting on >> error_log >> >> [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client >> 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported >> mechanism was requested (, Unknown error), referer: >> https://kwtpocpbis01.solaris.local/ipa/ui/ >> [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI >> wsgi_dispatch.__call__: >> [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI >> login_password.__call__: >> [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: >> Obtaining armor ccache: >> principal=HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL >> keytab=/etc/httpd/conf/ipa.keytab >> ccache=/var/run/ipa_memcached/krbcc_A_admin >> [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: Starting >> external process >> [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: >> args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' >> 'HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL' >> [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: Process >> finished, return code=0 >> [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: stdout= >> [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: stderr= >> [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: Starting >> external process >> [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: >> args='/usr/bin/kinit' 'admin at SOLARIS.LOCAL' '-T' >> '/var/run/ipa_memcached/krbcc_A_admin' >> [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: Process >> finished, return code=0 >> [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: >> stdout=Password for admin at SOLARIS.LOCAL: >> [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] >> [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: stderr= >> [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: >> principal=admin at SOLARIS.LOCAL returncode=0, stderr="" >> [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: Cleanup >> the armor ccache >> [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: Starting >> external process >> [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: >> args='/usr/bin/kdestroy' '-A' '-c' '/var/run/ipa_memcached/krbcc_A_admin' >> [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: Process >> finished, return code=0 >> [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: stdout= >> [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: stderr= >> [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found >> session cookie_id = 4803e184cecb42f2e326391dbb09443d >> [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: found >> session data in cache with id=4803e184cecb42f2e326391dbb09443d >> [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: >> finalize_kerberos_acquisition: login_password >> ccache_name="FILE:/var/run/ipa_memcached/krbcc_3004" >> session_id="4803e184cecb42f2e326391dbb09443d" >> [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: reading >> ccache data from file "/var/run/ipa_memcached/krbcc_3004" >> [Sun Mar 08 13:16:29.909319 2015] [:error] [pid 3004] ipa: DEBUG: >> get_credential_times: principal=krbtgt/SOLARIS.LOCAL at SOLARIS.LOCAL, >> authtime=03/08/15 13:16:29, starttime=03/08/15 13:16:29, endtime=03/09/15 >> 13:16:29, renew_till=01/01/70 03:00:00 >> [Sun Mar 08 13:16:29.909415 2015] [:error] [pid 3004] ipa: DEBUG: >> KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3004 endtime=1425896189 >> (03/09/15 13:16:29) >> [Sun Mar 08 13:16:29.909538 2015] [:error] [pid 3004] ipa: DEBUG: >> set_session_expiration_time: duration_type=inactivity_timeout duration=1200 >> max_age=1425895889 expiration=1425810989.91 (2015-03-08T13:36:29) >> [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store >> session: session_id=4803e184cecb42f2e326391dbb09443d >> start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 >> expiration_timestamp=2015-03-08T13:36:29 >> [Sun Mar 08 13:16:29.910004 2015] [:error] [pid 3004] ipa: DEBUG: >> release_ipa_ccache: KRB5CCNAME environment variable not set >> [Sun Mar 08 13:16:29.921259 2015] [:error] [pid 3003] ipa: DEBUG: WSGI >> wsgi_dispatch.__call__: >> [Sun Mar 08 13:16:29.921351 2015] [:error] [pid 3003] ipa: DEBUG: WSGI >> jsonserver_session.__call__: >> [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found >> session cookie_id = 4803e184cecb42f2e326391dbb09443d >> [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no >> session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating >> empty session data >> [Sun Mar 08 13:16:29.921875 2015] [:error] [pid 3003] ipa: DEBUG: store >> session: session_id=4803e184cecb42f2e326391dbb09443d >> start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 >> expiration_timestamp=1970-01-01T03:00:00 >> [Sun Mar 08 13:16:29.922125 2015] [:error] [pid 3003] ipa: DEBUG: >> jsonserver_session.__call__: session_id=4803e184cecb42f2e326391dbb09443d >> start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 >> expiration_timestamp=1970-01-01T03:00:00 >> [Sun Mar 08 13:16:29.922191 2015] [:error] [pid 3003] ipa: DEBUG: no >> ccache, need login >> [Sun Mar 08 13:16:29.922265 2015] [:error] [pid 3003] ipa: DEBUG: >> jsonserver_session: 401 Unauthorized need login >> >> >> On Sun, Mar 8, 2015 at 1:02 PM, Ben .T.George >> wrote: >> >>> this is the error mesage i am getting on httpd/error_log >>> >>> [Sun Mar 08 13:02:02.965470 2015] [auth_kerb:error] [pid 2922] [client >>> 172.16.107 >>> .250:60005] >>> gss_accept_sec_context() failed: An unsupported mechanism was request >>> >>> ed (, Unknown error), referer: >>> https://kwtpocpbis01.solaris.local/ipa/ui/ >>> >>> On Sun, Mar 8, 2015 at 12:48 PM, Ben .T.George >>> wrote: >>> >>>> Hi i checked the services and below is my output >>>> >>>> [root at kwtpocpbis01 ipa_memcached]# ps -ef | grep ipa_memcached >>>> apache 2079 1 0 11:11 ? 00:00:00 /usr/bin/memcached -d -s >>>> /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P >>>> /var/run/ipa_memcached/ipa_memcached.pid >>>> root 2801 2504 0 12:48 pts/0 00:00:00 grep --color=auto >>>> ipa_memcached >>>> >>>> [root at kwtpocpbis01 ipa_memcached]# ipactl status >>>> Directory Service: RUNNING >>>> krb5kdc Service: RUNNING >>>> kadmin Service: RUNNING >>>> named Service: RUNNING >>>> ipa_memcached Service: RUNNING >>>> httpd Service: RUNNING >>>> pki-tomcatd Service: RUNNING >>>> smb Service: RUNNING >>>> winbind Service: RUNNING >>>> ipa-otpd Service: RUNNING >>>> ipa-dnskeysyncd Service: RUNNING >>>> ipa: INFO: The ipactl command was successful >>>> >>>> >>>> On Sun, Mar 8, 2015 at 10:54 AM, Ben .T.George >>>> wrote: >>>> >>>>> HI >>>>> >>>>> i have free IPA 4.1.2 installed. >>>>> >>>>> my web ui always giving "Your session has expired. Please re-login." >>>>> even i tried from different computer.different browsers.. >>>>> >>>>> how can i fix this.? >>>>> >>>> >>>> >>> >> > > > From bentech4you at gmail.com Mon Mar 9 08:10:59 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Mon, 9 Mar 2015 11:10:59 +0300 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: <54FD5286.3010409@redhat.com> References: <54FD5286.3010409@redhat.com> Message-ID: Hi Martin, thanks for your replay. yesterday i did lot of this to fix this issue. the issue has been solved by kdestroy and re-initiate the ticket. after that restarted ipa service, it got worked Regards, ben On Mon, Mar 9, 2015 at 10:57 AM, Martin Kosek wrote: > Thanks for all the data. So it looks like your browser properly forward the > session cookie, but it is not recognized on the server even though it was > stored before. > > Especially these lines are strange: > > [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store > session: session_id=4803e184cecb42f2e326391dbb09443d > start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 > expiration_timestamp=2015-03-08T13:36:29 > ... > [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found > session cookie_id = 4803e184cecb42f2e326391dbb09443d > [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no > session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating > empty session data > > We know that ipa_memcached is running. Can you please also check if there > are > no SELinux errors in /var/log/audit/audit.log preveting Apache from > looking up > the session data? > > Thanks, > Martin > > On 03/08/2015 11:44 AM, Ben .T.George wrote: > > i was inspecting the page and got below response. > > > > http://s21.postimg.org/itv5hf0h3/asdasd.jpg > > > > http://s3.postimg.org/f6knomt1f/Capture.jpg > > > > please anyone help me to solve this issue. i just want to create one > local > > user in IPA > > > > On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George > wrote: > > > >> I enabled debugging mode on default.conf and this is what i am getting > on > >> error_log > >> > >> [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client > >> 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported > >> mechanism was requested (, Unknown error), referer: > >> https://kwtpocpbis01.solaris.local/ipa/ui/ > >> [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI > >> wsgi_dispatch.__call__: > >> [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI > >> login_password.__call__: > >> [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: > >> Obtaining armor ccache: > >> principal=HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL > >> keytab=/etc/httpd/conf/ipa.keytab > >> ccache=/var/run/ipa_memcached/krbcc_A_admin > >> [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: > Starting > >> external process > >> [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: > >> args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' > >> 'HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL' > >> [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: > Process > >> finished, return code=0 > >> [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: > stdout= > >> [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: > stderr= > >> [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: > Starting > >> external process > >> [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: > >> args='/usr/bin/kinit' 'admin at SOLARIS.LOCAL' '-T' > >> '/var/run/ipa_memcached/krbcc_A_admin' > >> [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: > Process > >> finished, return code=0 > >> [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: > >> stdout=Password for admin at SOLARIS.LOCAL: > >> [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] > >> [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: > stderr= > >> [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: > >> principal=admin at SOLARIS.LOCAL returncode=0, stderr="" > >> [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: > Cleanup > >> the armor ccache > >> [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: > Starting > >> external process > >> [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: > >> args='/usr/bin/kdestroy' '-A' '-c' > '/var/run/ipa_memcached/krbcc_A_admin' > >> [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: > Process > >> finished, return code=0 > >> [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: > stdout= > >> [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: > stderr= > >> [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found > >> session cookie_id = 4803e184cecb42f2e326391dbb09443d > >> [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: found > >> session data in cache with id=4803e184cecb42f2e326391dbb09443d > >> [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: > >> finalize_kerberos_acquisition: login_password > >> ccache_name="FILE:/var/run/ipa_memcached/krbcc_3004" > >> session_id="4803e184cecb42f2e326391dbb09443d" > >> [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: > reading > >> ccache data from file "/var/run/ipa_memcached/krbcc_3004" > >> [Sun Mar 08 13:16:29.909319 2015] [:error] [pid 3004] ipa: DEBUG: > >> get_credential_times: principal=krbtgt/SOLARIS.LOCAL at SOLARIS.LOCAL, > >> authtime=03/08/15 13:16:29, starttime=03/08/15 13:16:29, > endtime=03/09/15 > >> 13:16:29, renew_till=01/01/70 03:00:00 > >> [Sun Mar 08 13:16:29.909415 2015] [:error] [pid 3004] ipa: DEBUG: > >> KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3004 endtime=1425896189 > >> (03/09/15 13:16:29) > >> [Sun Mar 08 13:16:29.909538 2015] [:error] [pid 3004] ipa: DEBUG: > >> set_session_expiration_time: duration_type=inactivity_timeout > duration=1200 > >> max_age=1425895889 expiration=1425810989.91 (2015-03-08T13:36:29) > >> [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store > >> session: session_id=4803e184cecb42f2e326391dbb09443d > >> start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 > >> expiration_timestamp=2015-03-08T13:36:29 > >> [Sun Mar 08 13:16:29.910004 2015] [:error] [pid 3004] ipa: DEBUG: > >> release_ipa_ccache: KRB5CCNAME environment variable not set > >> [Sun Mar 08 13:16:29.921259 2015] [:error] [pid 3003] ipa: DEBUG: WSGI > >> wsgi_dispatch.__call__: > >> [Sun Mar 08 13:16:29.921351 2015] [:error] [pid 3003] ipa: DEBUG: WSGI > >> jsonserver_session.__call__: > >> [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found > >> session cookie_id = 4803e184cecb42f2e326391dbb09443d > >> [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no > >> session data in cache with id=4803e184cecb42f2e326391dbb09443d, > generating > >> empty session data > >> [Sun Mar 08 13:16:29.921875 2015] [:error] [pid 3003] ipa: DEBUG: store > >> session: session_id=4803e184cecb42f2e326391dbb09443d > >> start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 > >> expiration_timestamp=1970-01-01T03:00:00 > >> [Sun Mar 08 13:16:29.922125 2015] [:error] [pid 3003] ipa: DEBUG: > >> jsonserver_session.__call__: session_id=4803e184cecb42f2e326391dbb09443d > >> start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 > >> expiration_timestamp=1970-01-01T03:00:00 > >> [Sun Mar 08 13:16:29.922191 2015] [:error] [pid 3003] ipa: DEBUG: no > >> ccache, need login > >> [Sun Mar 08 13:16:29.922265 2015] [:error] [pid 3003] ipa: DEBUG: > >> jsonserver_session: 401 Unauthorized need login > >> > >> > >> On Sun, Mar 8, 2015 at 1:02 PM, Ben .T.George > >> wrote: > >> > >>> this is the error mesage i am getting on httpd/error_log > >>> > >>> [Sun Mar 08 13:02:02.965470 2015] [auth_kerb:error] [pid 2922] [client > >>> 172.16.107 > >>> .250:60005] > >>> gss_accept_sec_context() failed: An unsupported mechanism was request > >>> > >>> ed (, Unknown error), referer: > >>> https://kwtpocpbis01.solaris.local/ipa/ui/ > >>> > >>> On Sun, Mar 8, 2015 at 12:48 PM, Ben .T.George > >>> wrote: > >>> > >>>> Hi i checked the services and below is my output > >>>> > >>>> [root at kwtpocpbis01 ipa_memcached]# ps -ef | grep ipa_memcached > >>>> apache 2079 1 0 11:11 ? 00:00:00 /usr/bin/memcached -d > -s > >>>> /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P > >>>> /var/run/ipa_memcached/ipa_memcached.pid > >>>> root 2801 2504 0 12:48 pts/0 00:00:00 grep --color=auto > >>>> ipa_memcached > >>>> > >>>> [root at kwtpocpbis01 ipa_memcached]# ipactl status > >>>> Directory Service: RUNNING > >>>> krb5kdc Service: RUNNING > >>>> kadmin Service: RUNNING > >>>> named Service: RUNNING > >>>> ipa_memcached Service: RUNNING > >>>> httpd Service: RUNNING > >>>> pki-tomcatd Service: RUNNING > >>>> smb Service: RUNNING > >>>> winbind Service: RUNNING > >>>> ipa-otpd Service: RUNNING > >>>> ipa-dnskeysyncd Service: RUNNING > >>>> ipa: INFO: The ipactl command was successful > >>>> > >>>> > >>>> On Sun, Mar 8, 2015 at 10:54 AM, Ben .T.George > > >>>> wrote: > >>>> > >>>>> HI > >>>>> > >>>>> i have free IPA 4.1.2 installed. > >>>>> > >>>>> my web ui always giving "Your session has expired. Please re-login." > >>>>> even i tried from different computer.different browsers.. > >>>>> > >>>>> how can i fix this.? > >>>>> > >>>> > >>>> > >>> > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Mar 9 11:21:38 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 09 Mar 2015 12:21:38 +0100 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: References: <54FD5286.3010409@redhat.com> Message-ID: <54FD8242.3040001@redhat.com> Ok, thanks for information. I would still love to know the real root cause, but we will now find it now I assume. Of this issue re-appears, let us know :-) Thanks, Martin On 03/09/2015 09:10 AM, Ben .T.George wrote: > Hi Martin, > > thanks for your replay. > > yesterday i did lot of this to fix this issue. > > the issue has been solved by kdestroy and re-initiate the ticket. > > after that restarted ipa service, it got worked > > Regards, > ben > > On Mon, Mar 9, 2015 at 10:57 AM, Martin Kosek wrote: > >> Thanks for all the data. So it looks like your browser properly forward the >> session cookie, but it is not recognized on the server even though it was >> stored before. >> >> Especially these lines are strange: >> >> [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store >> session: session_id=4803e184cecb42f2e326391dbb09443d >> start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 >> expiration_timestamp=2015-03-08T13:36:29 >> ... >> [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found >> session cookie_id = 4803e184cecb42f2e326391dbb09443d >> [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no >> session data in cache with id=4803e184cecb42f2e326391dbb09443d, generating >> empty session data >> >> We know that ipa_memcached is running. Can you please also check if there >> are >> no SELinux errors in /var/log/audit/audit.log preveting Apache from >> looking up >> the session data? >> >> Thanks, >> Martin >> >> On 03/08/2015 11:44 AM, Ben .T.George wrote: >>> i was inspecting the page and got below response. >>> >>> http://s21.postimg.org/itv5hf0h3/asdasd.jpg >>> >>> http://s3.postimg.org/f6knomt1f/Capture.jpg >>> >>> please anyone help me to solve this issue. i just want to create one >> local >>> user in IPA >>> >>> On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George >> wrote: >>> >>>> I enabled debugging mode on default.conf and this is what i am getting >> on >>>> error_log >>>> >>>> [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] [client >>>> 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported >>>> mechanism was requested (, Unknown error), referer: >>>> https://kwtpocpbis01.solaris.local/ipa/ui/ >>>> [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: WSGI >>>> wsgi_dispatch.__call__: >>>> [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI >>>> login_password.__call__: >>>> [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: >>>> Obtaining armor ccache: >>>> principal=HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL >>>> keytab=/etc/httpd/conf/ipa.keytab >>>> ccache=/var/run/ipa_memcached/krbcc_A_admin >>>> [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: >> Starting >>>> external process >>>> [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: >>>> args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' >>>> 'HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL' >>>> [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: >> Process >>>> finished, return code=0 >>>> [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: >> stdout= >>>> [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: >> stderr= >>>> [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: >> Starting >>>> external process >>>> [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: >>>> args='/usr/bin/kinit' 'admin at SOLARIS.LOCAL' '-T' >>>> '/var/run/ipa_memcached/krbcc_A_admin' >>>> [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: >> Process >>>> finished, return code=0 >>>> [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: >>>> stdout=Password for admin at SOLARIS.LOCAL: >>>> [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] >>>> [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: >> stderr= >>>> [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: kinit: >>>> principal=admin at SOLARIS.LOCAL returncode=0, stderr="" >>>> [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: >> Cleanup >>>> the armor ccache >>>> [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: >> Starting >>>> external process >>>> [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: >>>> args='/usr/bin/kdestroy' '-A' '-c' >> '/var/run/ipa_memcached/krbcc_A_admin' >>>> [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: >> Process >>>> finished, return code=0 >>>> [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: >> stdout= >>>> [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: >> stderr= >>>> [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: found >>>> session cookie_id = 4803e184cecb42f2e326391dbb09443d >>>> [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: found >>>> session data in cache with id=4803e184cecb42f2e326391dbb09443d >>>> [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: >>>> finalize_kerberos_acquisition: login_password >>>> ccache_name="FILE:/var/run/ipa_memcached/krbcc_3004" >>>> session_id="4803e184cecb42f2e326391dbb09443d" >>>> [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: >> reading >>>> ccache data from file "/var/run/ipa_memcached/krbcc_3004" >>>> [Sun Mar 08 13:16:29.909319 2015] [:error] [pid 3004] ipa: DEBUG: >>>> get_credential_times: principal=krbtgt/SOLARIS.LOCAL at SOLARIS.LOCAL, >>>> authtime=03/08/15 13:16:29, starttime=03/08/15 13:16:29, >> endtime=03/09/15 >>>> 13:16:29, renew_till=01/01/70 03:00:00 >>>> [Sun Mar 08 13:16:29.909415 2015] [:error] [pid 3004] ipa: DEBUG: >>>> KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3004 endtime=1425896189 >>>> (03/09/15 13:16:29) >>>> [Sun Mar 08 13:16:29.909538 2015] [:error] [pid 3004] ipa: DEBUG: >>>> set_session_expiration_time: duration_type=inactivity_timeout >> duration=1200 >>>> max_age=1425895889 expiration=1425810989.91 (2015-03-08T13:36:29) >>>> [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store >>>> session: session_id=4803e184cecb42f2e326391dbb09443d >>>> start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 >>>> expiration_timestamp=2015-03-08T13:36:29 >>>> [Sun Mar 08 13:16:29.910004 2015] [:error] [pid 3004] ipa: DEBUG: >>>> release_ipa_ccache: KRB5CCNAME environment variable not set >>>> [Sun Mar 08 13:16:29.921259 2015] [:error] [pid 3003] ipa: DEBUG: WSGI >>>> wsgi_dispatch.__call__: >>>> [Sun Mar 08 13:16:29.921351 2015] [:error] [pid 3003] ipa: DEBUG: WSGI >>>> jsonserver_session.__call__: >>>> [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found >>>> session cookie_id = 4803e184cecb42f2e326391dbb09443d >>>> [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no >>>> session data in cache with id=4803e184cecb42f2e326391dbb09443d, >> generating >>>> empty session data >>>> [Sun Mar 08 13:16:29.921875 2015] [:error] [pid 3003] ipa: DEBUG: store >>>> session: session_id=4803e184cecb42f2e326391dbb09443d >>>> start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 >>>> expiration_timestamp=1970-01-01T03:00:00 >>>> [Sun Mar 08 13:16:29.922125 2015] [:error] [pid 3003] ipa: DEBUG: >>>> jsonserver_session.__call__: session_id=4803e184cecb42f2e326391dbb09443d >>>> start_timestamp=2015-03-08T13:16:29 access_timestamp=2015-03-08T13:16:29 >>>> expiration_timestamp=1970-01-01T03:00:00 >>>> [Sun Mar 08 13:16:29.922191 2015] [:error] [pid 3003] ipa: DEBUG: no >>>> ccache, need login >>>> [Sun Mar 08 13:16:29.922265 2015] [:error] [pid 3003] ipa: DEBUG: >>>> jsonserver_session: 401 Unauthorized need login >>>> >>>> >>>> On Sun, Mar 8, 2015 at 1:02 PM, Ben .T.George >>>> wrote: >>>> >>>>> this is the error mesage i am getting on httpd/error_log >>>>> >>>>> [Sun Mar 08 13:02:02.965470 2015] [auth_kerb:error] [pid 2922] [client >>>>> 172.16.107 >>>>> .250:60005] >>>>> gss_accept_sec_context() failed: An unsupported mechanism was request >>>>> >>>>> ed (, Unknown error), referer: >>>>> https://kwtpocpbis01.solaris.local/ipa/ui/ >>>>> >>>>> On Sun, Mar 8, 2015 at 12:48 PM, Ben .T.George >>>>> wrote: >>>>> >>>>>> Hi i checked the services and below is my output >>>>>> >>>>>> [root at kwtpocpbis01 ipa_memcached]# ps -ef | grep ipa_memcached >>>>>> apache 2079 1 0 11:11 ? 00:00:00 /usr/bin/memcached -d >> -s >>>>>> /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P >>>>>> /var/run/ipa_memcached/ipa_memcached.pid >>>>>> root 2801 2504 0 12:48 pts/0 00:00:00 grep --color=auto >>>>>> ipa_memcached >>>>>> >>>>>> [root at kwtpocpbis01 ipa_memcached]# ipactl status >>>>>> Directory Service: RUNNING >>>>>> krb5kdc Service: RUNNING >>>>>> kadmin Service: RUNNING >>>>>> named Service: RUNNING >>>>>> ipa_memcached Service: RUNNING >>>>>> httpd Service: RUNNING >>>>>> pki-tomcatd Service: RUNNING >>>>>> smb Service: RUNNING >>>>>> winbind Service: RUNNING >>>>>> ipa-otpd Service: RUNNING >>>>>> ipa-dnskeysyncd Service: RUNNING >>>>>> ipa: INFO: The ipactl command was successful >>>>>> >>>>>> >>>>>> On Sun, Mar 8, 2015 at 10:54 AM, Ben .T.George >> >>>>>> wrote: >>>>>> >>>>>>> HI >>>>>>> >>>>>>> i have free IPA 4.1.2 installed. >>>>>>> >>>>>>> my web ui always giving "Your session has expired. Please re-login." >>>>>>> even i tried from different computer.different browsers.. >>>>>>> >>>>>>> how can i fix this.? >>>>>>> >>>>>> >>>>>> >>>>> >>>> >>> >>> >>> >> >> > From bentech4you at gmail.com Mon Mar 9 11:46:13 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Mon, 9 Mar 2015 14:46:13 +0300 Subject: [Freeipa-users] IPA web ui always giving "Your session has expired. Please re-login." In-Reply-To: <54FD8242.3040001@redhat.com> References: <54FD5286.3010409@redhat.com> <54FD8242.3040001@redhat.com> Message-ID: HI thanks sure this is the only place i can ask questions :) but i don't know from where i am getting that basic authentication window like .htaccess based. i think when i tried from chome only i got this window On Mon, Mar 9, 2015 at 2:21 PM, Martin Kosek wrote: > Ok, thanks for information. I would still love to know the real root > cause, but > we will now find it now I assume. > > Of this issue re-appears, let us know :-) > > Thanks, > Martin > > On 03/09/2015 09:10 AM, Ben .T.George wrote: > > Hi Martin, > > > > thanks for your replay. > > > > yesterday i did lot of this to fix this issue. > > > > the issue has been solved by kdestroy and re-initiate the ticket. > > > > after that restarted ipa service, it got worked > > > > Regards, > > ben > > > > On Mon, Mar 9, 2015 at 10:57 AM, Martin Kosek wrote: > > > >> Thanks for all the data. So it looks like your browser properly forward > the > >> session cookie, but it is not recognized on the server even though it > was > >> stored before. > >> > >> Especially these lines are strange: > >> > >> [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: store > >> session: session_id=4803e184cecb42f2e326391dbb09443d > >> start_timestamp=2015-03-08T13:15:12 access_timestamp=2015-03-08T13:16:29 > >> expiration_timestamp=2015-03-08T13:36:29 > >> ... > >> [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: found > >> session cookie_id = 4803e184cecb42f2e326391dbb09443d > >> [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no > >> session data in cache with id=4803e184cecb42f2e326391dbb09443d, > generating > >> empty session data > >> > >> We know that ipa_memcached is running. Can you please also check if > there > >> are > >> no SELinux errors in /var/log/audit/audit.log preveting Apache from > >> looking up > >> the session data? > >> > >> Thanks, > >> Martin > >> > >> On 03/08/2015 11:44 AM, Ben .T.George wrote: > >>> i was inspecting the page and got below response. > >>> > >>> http://s21.postimg.org/itv5hf0h3/asdasd.jpg > >>> > >>> http://s3.postimg.org/f6knomt1f/Capture.jpg > >>> > >>> please anyone help me to solve this issue. i just want to create one > >> local > >>> user in IPA > >>> > >>> On Sun, Mar 8, 2015 at 1:17 PM, Ben .T.George > >> wrote: > >>> > >>>> I enabled debugging mode on default.conf and this is what i am getting > >> on > >>>> error_log > >>>> > >>>> [Sun Mar 08 13:16:18.204363 2015] [auth_kerb:error] [pid 3065] > [client > >>>> 172.16.107.250:60088] gss_accept_sec_context() failed: An unsupported > >>>> mechanism was requested (, Unknown error), referer: > >>>> https://kwtpocpbis01.solaris.local/ipa/ui/ > >>>> [Sun Mar 08 13:16:29.849339 2015] [:error] [pid 3004] ipa: DEBUG: > WSGI > >>>> wsgi_dispatch.__call__: > >>>> [Sun Mar 08 13:16:29.849458 2015] [:error] [pid 3004] ipa: DEBUG: WSGI > >>>> login_password.__call__: > >>>> [Sun Mar 08 13:16:29.849683 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> Obtaining armor ccache: > >>>> principal=HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL > >>>> keytab=/etc/httpd/conf/ipa.keytab > >>>> ccache=/var/run/ipa_memcached/krbcc_A_admin > >>>> [Sun Mar 08 13:16:29.849830 2015] [:error] [pid 3004] ipa: DEBUG: > >> Starting > >>>> external process > >>>> [Sun Mar 08 13:16:29.849923 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> args='/usr/bin/kinit' '-kt' '/etc/httpd/conf/ipa.keytab' > >>>> 'HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL' > >>>> [Sun Mar 08 13:16:29.868747 2015] [:error] [pid 3004] ipa: DEBUG: > >> Process > >>>> finished, return code=0 > >>>> [Sun Mar 08 13:16:29.868858 2015] [:error] [pid 3004] ipa: DEBUG: > >> stdout= > >>>> [Sun Mar 08 13:16:29.868955 2015] [:error] [pid 3004] ipa: DEBUG: > >> stderr= > >>>> [Sun Mar 08 13:16:29.869120 2015] [:error] [pid 3004] ipa: DEBUG: > >> Starting > >>>> external process > >>>> [Sun Mar 08 13:16:29.869204 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> args='/usr/bin/kinit' 'admin at SOLARIS.LOCAL' '-T' > >>>> '/var/run/ipa_memcached/krbcc_A_admin' > >>>> [Sun Mar 08 13:16:29.902181 2015] [:error] [pid 3004] ipa: DEBUG: > >> Process > >>>> finished, return code=0 > >>>> [Sun Mar 08 13:16:29.902269 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> stdout=Password for admin at SOLARIS.LOCAL: > >>>> [Sun Mar 08 13:16:29.902278 2015] [:error] [pid 3004] > >>>> [Sun Mar 08 13:16:29.902328 2015] [:error] [pid 3004] ipa: DEBUG: > >> stderr= > >>>> [Sun Mar 08 13:16:29.902427 2015] [:error] [pid 3004] ipa: DEBUG: > kinit: > >>>> principal=admin at SOLARIS.LOCAL returncode=0, stderr="" > >>>> [Sun Mar 08 13:16:29.902483 2015] [:error] [pid 3004] ipa: DEBUG: > >> Cleanup > >>>> the armor ccache > >>>> [Sun Mar 08 13:16:29.902560 2015] [:error] [pid 3004] ipa: DEBUG: > >> Starting > >>>> external process > >>>> [Sun Mar 08 13:16:29.902621 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> args='/usr/bin/kdestroy' '-A' '-c' > >> '/var/run/ipa_memcached/krbcc_A_admin' > >>>> [Sun Mar 08 13:16:29.908045 2015] [:error] [pid 3004] ipa: DEBUG: > >> Process > >>>> finished, return code=0 > >>>> [Sun Mar 08 13:16:29.908121 2015] [:error] [pid 3004] ipa: DEBUG: > >> stdout= > >>>> [Sun Mar 08 13:16:29.908173 2015] [:error] [pid 3004] ipa: DEBUG: > >> stderr= > >>>> [Sun Mar 08 13:16:29.908348 2015] [:error] [pid 3004] ipa: DEBUG: > found > >>>> session cookie_id = 4803e184cecb42f2e326391dbb09443d > >>>> [Sun Mar 08 13:16:29.908647 2015] [:error] [pid 3004] ipa: DEBUG: > found > >>>> session data in cache with id=4803e184cecb42f2e326391dbb09443d > >>>> [Sun Mar 08 13:16:29.908728 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> finalize_kerberos_acquisition: login_password > >>>> ccache_name="FILE:/var/run/ipa_memcached/krbcc_3004" > >>>> session_id="4803e184cecb42f2e326391dbb09443d" > >>>> [Sun Mar 08 13:16:29.908824 2015] [:error] [pid 3004] ipa: DEBUG: > >> reading > >>>> ccache data from file "/var/run/ipa_memcached/krbcc_3004" > >>>> [Sun Mar 08 13:16:29.909319 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> get_credential_times: principal=krbtgt/SOLARIS.LOCAL at SOLARIS.LOCAL, > >>>> authtime=03/08/15 13:16:29, starttime=03/08/15 13:16:29, > >> endtime=03/09/15 > >>>> 13:16:29, renew_till=01/01/70 03:00:00 > >>>> [Sun Mar 08 13:16:29.909415 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_3004 endtime=1425896189 > >>>> (03/09/15 13:16:29) > >>>> [Sun Mar 08 13:16:29.909538 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> set_session_expiration_time: duration_type=inactivity_timeout > >> duration=1200 > >>>> max_age=1425895889 expiration=1425810989.91 (2015-03-08T13:36:29) > >>>> [Sun Mar 08 13:16:29.909637 2015] [:error] [pid 3004] ipa: DEBUG: > store > >>>> session: session_id=4803e184cecb42f2e326391dbb09443d > >>>> start_timestamp=2015-03-08T13:15:12 > access_timestamp=2015-03-08T13:16:29 > >>>> expiration_timestamp=2015-03-08T13:36:29 > >>>> [Sun Mar 08 13:16:29.910004 2015] [:error] [pid 3004] ipa: DEBUG: > >>>> release_ipa_ccache: KRB5CCNAME environment variable not set > >>>> [Sun Mar 08 13:16:29.921259 2015] [:error] [pid 3003] ipa: DEBUG: WSGI > >>>> wsgi_dispatch.__call__: > >>>> [Sun Mar 08 13:16:29.921351 2015] [:error] [pid 3003] ipa: DEBUG: WSGI > >>>> jsonserver_session.__call__: > >>>> [Sun Mar 08 13:16:29.921519 2015] [:error] [pid 3003] ipa: DEBUG: > found > >>>> session cookie_id = 4803e184cecb42f2e326391dbb09443d > >>>> [Sun Mar 08 13:16:29.921731 2015] [:error] [pid 3003] ipa: DEBUG: no > >>>> session data in cache with id=4803e184cecb42f2e326391dbb09443d, > >> generating > >>>> empty session data > >>>> [Sun Mar 08 13:16:29.921875 2015] [:error] [pid 3003] ipa: DEBUG: > store > >>>> session: session_id=4803e184cecb42f2e326391dbb09443d > >>>> start_timestamp=2015-03-08T13:16:29 > access_timestamp=2015-03-08T13:16:29 > >>>> expiration_timestamp=1970-01-01T03:00:00 > >>>> [Sun Mar 08 13:16:29.922125 2015] [:error] [pid 3003] ipa: DEBUG: > >>>> jsonserver_session.__call__: > session_id=4803e184cecb42f2e326391dbb09443d > >>>> start_timestamp=2015-03-08T13:16:29 > access_timestamp=2015-03-08T13:16:29 > >>>> expiration_timestamp=1970-01-01T03:00:00 > >>>> [Sun Mar 08 13:16:29.922191 2015] [:error] [pid 3003] ipa: DEBUG: no > >>>> ccache, need login > >>>> [Sun Mar 08 13:16:29.922265 2015] [:error] [pid 3003] ipa: DEBUG: > >>>> jsonserver_session: 401 Unauthorized need login > >>>> > >>>> > >>>> On Sun, Mar 8, 2015 at 1:02 PM, Ben .T.George > >>>> wrote: > >>>> > >>>>> this is the error mesage i am getting on httpd/error_log > >>>>> > >>>>> [Sun Mar 08 13:02:02.965470 2015] [auth_kerb:error] [pid 2922] > [client > >>>>> 172.16.107 > >>>>> .250:60005] > >>>>> gss_accept_sec_context() failed: An unsupported mechanism was request > >>>>> > >>>>> ed (, Unknown error), referer: > >>>>> https://kwtpocpbis01.solaris.local/ipa/ui/ > >>>>> > >>>>> On Sun, Mar 8, 2015 at 12:48 PM, Ben .T.George < > bentech4you at gmail.com> > >>>>> wrote: > >>>>> > >>>>>> Hi i checked the services and below is my output > >>>>>> > >>>>>> [root at kwtpocpbis01 ipa_memcached]# ps -ef | grep ipa_memcached > >>>>>> apache 2079 1 0 11:11 ? 00:00:00 /usr/bin/memcached > -d > >> -s > >>>>>> /var/run/ipa_memcached/ipa_memcached -u apache -m 64 -c 1024 -P > >>>>>> /var/run/ipa_memcached/ipa_memcached.pid > >>>>>> root 2801 2504 0 12:48 pts/0 00:00:00 grep --color=auto > >>>>>> ipa_memcached > >>>>>> > >>>>>> [root at kwtpocpbis01 ipa_memcached]# ipactl status > >>>>>> Directory Service: RUNNING > >>>>>> krb5kdc Service: RUNNING > >>>>>> kadmin Service: RUNNING > >>>>>> named Service: RUNNING > >>>>>> ipa_memcached Service: RUNNING > >>>>>> httpd Service: RUNNING > >>>>>> pki-tomcatd Service: RUNNING > >>>>>> smb Service: RUNNING > >>>>>> winbind Service: RUNNING > >>>>>> ipa-otpd Service: RUNNING > >>>>>> ipa-dnskeysyncd Service: RUNNING > >>>>>> ipa: INFO: The ipactl command was successful > >>>>>> > >>>>>> > >>>>>> On Sun, Mar 8, 2015 at 10:54 AM, Ben .T.George < > bentech4you at gmail.com > >>> > >>>>>> wrote: > >>>>>> > >>>>>>> HI > >>>>>>> > >>>>>>> i have free IPA 4.1.2 installed. > >>>>>>> > >>>>>>> my web ui always giving "Your session has expired. Please > re-login." > >>>>>>> even i tried from different computer.different browsers.. > >>>>>>> > >>>>>>> how can i fix this.? > >>>>>>> > >>>>>> > >>>>>> > >>>>> > >>>> > >>> > >>> > >>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From traiano at gmail.com Mon Mar 9 16:44:33 2015 From: traiano at gmail.com (Traiano Welcome) Date: Mon, 9 Mar 2015 19:44:33 +0300 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers Message-ID: Hi List I have AD trusts configured and working between an IPA server and a "master" primary domain controller (dc-1) in a forest in one data center. This allows me to connect with SSH to linux servers in the same data-center, authenticating with my AD credentials. I'm trying to test a scenario where I have an IPA server set up in another data center, and trust is established with an AD domain controller (dc-2) in that data-center. This domain controller takes dc-1 as it's authoritative source. Ideally, the IPA server will interact with the domain controller nearest to it (i.e dc-2), however, from tcpdump, I note the following: - IPA server communicates with dc-2 first - dc-2 returns a list of domain controllers in all the datacenters, including dc-1 the IPA server then begins querying ldap and kerberos ports on dc-1, the domain controller furthest from it. - Authentication on clients fail My question is: Is it possible to get IPA to query and interact only with the domain controller it initially established trust with? Thanks in advance, Traiano From abokovoy at redhat.com Mon Mar 9 17:04:00 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 Mar 2015 19:04:00 +0200 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: References: Message-ID: <20150309170400.GC25455@redhat.com> On Mon, 09 Mar 2015, Traiano Welcome wrote: >Hi List > > >I have AD trusts configured and working between an IPA server and a >"master" primary domain controller (dc-1) in a forest in one data >center. This allows me to connect with SSH to linux servers in the >same data-center, authenticating with my AD credentials. > >I'm trying to test a scenario where I have an IPA server set up in >another data center, and trust is established with an AD domain >controller (dc-2) in that data-center. >This domain controller takes dc-1 as it's authoritative source. >Ideally, the IPA server will interact with the domain controller >nearest to it (i.e dc-2), however, from tcpdump, I note the following: > >- IPA server communicates with dc-2 first >- dc-2 returns a list of domain controllers in all the datacenters, >including dc-1 >the IPA server then begins querying ldap and kerberos ports on dc-1, >the domain controller furthest from it. >- Authentication on clients fail > >My question is: Is it possible to get IPA to query and interact only >with the domain controller it initially established trust with? Let's first separate multiple issues. 1. Terminology Cross-forest trust is established between domain controllers in forest root domains. In case of IPA we need that access only once, when trust is created. You don't need to establish trust again with dc-2 once you have established it with dc-1. When trust is established, AD DCs will look up IPA masters via SRV records in DNS (_ldap._tcp.). We don't provide site-specific SRV records as IPA does not handle sites in this area yet. However, this is not your problem. 2. User and group lookups are done by SSSD against global catalog service (_gc._tcp.) and AD DS (_ldap._tcp.), along with Kerberos KDC (AD DCs). These DCs are found via SRV records in DNS and SSSD since 1.9.5 uses site-specific SRV records for AD domain controllers lookups in case of IPA-AD trust. You are interested in (2) being site-aware. However, you didn't say what is your distribution and software versions so it is quite hard to give any recommendation. -- / Alexander Bokovoy From bslusky at smartling.com Mon Mar 9 18:13:01 2015 From: bslusky at smartling.com (Ben Slusky) Date: Mon, 9 Mar 2015 14:13:01 -0400 Subject: [Freeipa-users] Trying to migrate, can't set hashed passwords Message-ID: Greetings FreeIPA users, I'm setting up FreeIPA service in our production environment to replace several different authentication methods for various systems. I'm trying to migrate the first wave of users now My plan was to copy their passwords from an old LDAP directory (one of the aforementioned several authentication methods) and then send them to the migration page to finish the job. bslusky at ipa1.aws:~$ head techteam-passwords.ldif dn: uid=user1001,cn=users,cn=accounts,dc=smartling,dc=int changeType: modify replace: userPassword userPassword:: e1NTSE[...] - dn: uid=user1002,cn=users,cn=accounts,dc=smartling,dc=int changeType: modify replace: userPassword userPassword:: e1NIQX[...] Unfortunately it isn't working: bslusky at ipa1.aws:~$ ldapmodify -x -D cn=directory\ manager -W -f techteam-passwords.ldif Enter LDAP Password: modifying entry "uid=user1001,cn=users,cn=accounts,dc=smartling,dc=int" ldap_modify: Operations error (1) I found some possible causes of this error, and fixed them: bslusky at ipa1.aws:~$ ipa config-show |grep migration Enable migration mode: TRUE bslusky at ipa1.aws:~$ ldapsearch -x -D cn=directory\ manager -W -b cn=config |grep allow-hashed Enter LDAP Password: nsslapd-allow-hashed-passwords: on Still no soap. Any suggestions? TIA, - -Ben -- *Ben Slusky*Smartling, Inc. Senior Operations Engineer bslusky at smartling.com | smartling.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From matt.wells at mosaic451.com Mon Mar 9 18:18:41 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Mon, 9 Mar 2015 11:18:41 -0700 Subject: [Freeipa-users] Errors while adding DNS Zone Message-ID: I'm getting some errors on a DNS Zone that I'm attempting to create. My systems reside within a sub-domain of example.com. (xyz.example.com) Of course example.com is the internet address, but I want to host the internal example.com so we're able to point to internal intranets and so on. So to the good stuff Regardless of what flags I give, what NS records I change, the NS never actually set. I know it's something silly that I'm overlooking but would really love other eyes. I go to create the zone on server2. [root at server2 html]# ipa dnszone-add example.com Zone name: example.com. Active zone: TRUE Authoritative nameserver: server2.xyz.example.com. Administrator e-mail address: hostmaster SOA serial: 1425924224 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant xyz.example.com krb5-self * A; grant xyz.example.com krb5-self * AAAA; grant xyz.example.com krb5-self * SSHFP; Dynamic update: FALSE Allow query: any; Allow transfer: none; [root at server2 html]# rndc reload server reload successful ------------ Logs on server1 show this Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server2.xyz.example.com' has no address records (A or AAAA) Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server1.xyz.example.com' has no address records (A or AAAA) Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: not loaded due to errors. Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: update_zone (syncrepl) failed for 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server2.xyz.example.com' has no address records (A or AAAA) Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server1.xyz.example.com' has no address records (A or AAAA) Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: not loaded due to errors. Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: update_zone (syncrepl) failed for 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server2.xyz.example.com' has no address records (A or AAAA) Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server1.xyz.example.com' has no address records (A or AAAA) Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: not loaded due to errors. Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: unable to reload invalid zone; reload triggered by change in 'idnsname=_kerberos,idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com':bad zone Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server2.xyz.example.com' has no address records (A or AAAA) Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: NS 'server1.xyz.example.com' has no address records (A or AAAA) Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone example.com/IN: not loaded due to errors. Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: update_zone (syncrepl) failed for 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be outdated, run `rndc reload`: bad zone From traiano at gmail.com Mon Mar 9 18:29:21 2015 From: traiano at gmail.com (Traiano Welcome) Date: Mon, 9 Mar 2015 21:29:21 +0300 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: <20150309170400.GC25455@redhat.com> References: <20150309170400.GC25455@redhat.com> Message-ID: Hi Alexander Thanks for the response: On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy wrote: > On Mon, 09 Mar 2015, Traiano Welcome wrote: >> >> Hi List >> >> >> I have AD trusts configured and working between an IPA server and a >> "master" primary domain controller (dc-1) in a forest in one data >> center. This allows me to connect with SSH to linux servers in the >> same data-center, authenticating with my AD credentials. >> >> I'm trying to test a scenario where I have an IPA server set up in >> another data center, and trust is established with an AD domain >> controller (dc-2) in that data-center. >> This domain controller takes dc-1 as it's authoritative source. >> Ideally, the IPA server will interact with the domain controller >> nearest to it (i.e dc-2), however, from tcpdump, I note the following: >> >> - IPA server communicates with dc-2 first >> - dc-2 returns a list of domain controllers in all the datacenters, >> including dc-1 >> the IPA server then begins querying ldap and kerberos ports on dc-1, >> the domain controller furthest from it. >> - Authentication on clients fail >> >> My question is: Is it possible to get IPA to query and interact only >> with the domain controller it initially established trust with? > > Let's first separate multiple issues. > > 1. Terminology > Cross-forest trust is established between domain controllers in forest > root > domains. In case of IPA we need that access only once, when trust is > created. You don't need to establish trust again with dc-2 once you > have established it with dc-1. > > When trust is established, AD DCs will look up IPA masters via SRV > records in DNS (_ldap._tcp.). We don't provide > site-specific SRV records as IPA does not handle sites in this area > yet. > Thanks for the clarification. > However, this is not your problem. > > 2. User and group lookups are done by SSSD against global catalog > service (_gc._tcp.) and AD DS (_ldap._tcp.), > along with Kerberos KDC (AD DCs). > > These DCs are found via SRV records in DNS and SSSD since 1.9.5 > uses site-specific SRV records for AD domain controllers lookups in > case of IPA-AD trust. > > You are interested in (2) being site-aware. However, you didn't say what > is your distribution and software versions so it is quite hard to give > any recommendation. My objective is basically distribution of IPA servers across multiple data centers linked by a WAN: - There is a central 'head office' with an AD domain-controller, this is the primary source of identity for the domain. - A number of other data-centers each have their own local AD domain controller linked to the head-office domain controller - The datacenters are in different timezones. - An IPA server in each data-center with trust established with the local domain controller - Each IPA server is configured with it's own realm, but provides access to the global AD domain via AD Trusts The idea was to prevent IPA authentication related traffic going across the WAN (latency, different time-zones etc) to a central ad domain controller at head office. So this setup seemed reasonable. I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, the working setup was based on this howto: http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description ... which works fine if the IPA server has a trust relationship directly with the primary domain controller at head office (which it is collocated with). I can live without site-awareness per se if I can achieve IPA centralised authentication across datacenters in different timezones, with AD as the primary source of identity. An alternative setup that I've considered testing: - IPA server at the head office with trust established to the primary AD DC. - A replica of the primary in each DC (different timezones), on the same realm However, I doubt replicas can work across timezones, and with high WAN latencies. > > -- > / Alexander Bokovoy Thanks, Traiano From abokovoy at redhat.com Mon Mar 9 18:45:49 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 Mar 2015 20:45:49 +0200 Subject: [Freeipa-users] Trying to migrate, can't set hashed passwords In-Reply-To: References: Message-ID: <20150309184549.GE25455@redhat.com> On Mon, 09 Mar 2015, Ben Slusky wrote: >Greetings FreeIPA users, > >I'm setting up FreeIPA service in our production environment to replace >several different authentication methods for various systems. I'm trying to >migrate the first wave of users now My plan was to copy their passwords >from an old LDAP directory (one of the aforementioned several >authentication methods) and then send them to the migration page to finish >the job. Even in migration mode, you can only set pre-hashed passwords when creating the records, not when modifying them. > >bslusky at ipa1.aws:~$ head techteam-passwords.ldif >dn: uid=user1001,cn=users,cn=accounts,dc=smartling,dc=int >changeType: modify >replace: userPassword >userPassword:: e1NTSE[...] >- > >dn: uid=user1002,cn=users,cn=accounts,dc=smartling,dc=int >changeType: modify >replace: userPassword >userPassword:: e1NIQX[...] > >Unfortunately it isn't working: > >bslusky at ipa1.aws:~$ ldapmodify -x -D cn=directory\ manager -W -f >techteam-passwords.ldif >Enter LDAP Password: >modifying entry "uid=user1001,cn=users,cn=accounts,dc=smartling,dc=int" >ldap_modify: Operations error (1) > >I found some possible causes of this error, and fixed them: > >bslusky at ipa1.aws:~$ ipa config-show |grep migration > Enable migration mode: TRUE > >bslusky at ipa1.aws:~$ ldapsearch -x -D cn=directory\ manager -W -b cn=config >|grep allow-hashed >Enter LDAP Password: >nsslapd-allow-hashed-passwords: on > >Still no soap. Any suggestions? Works as designed. We only allow unhashed passwords in migration mode when entry is added, not modified. -- / Alexander Bokovoy From abokovoy at redhat.com Mon Mar 9 18:49:22 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 9 Mar 2015 20:49:22 +0200 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: References: <20150309170400.GC25455@redhat.com> Message-ID: <20150309184922.GF25455@redhat.com> On Mon, 09 Mar 2015, Traiano Welcome wrote: >Hi Alexander > > Thanks for the response: > >On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy wrote: >> On Mon, 09 Mar 2015, Traiano Welcome wrote: >>> >>> Hi List >>> >>> >>> I have AD trusts configured and working between an IPA server and a >>> "master" primary domain controller (dc-1) in a forest in one data >>> center. This allows me to connect with SSH to linux servers in the >>> same data-center, authenticating with my AD credentials. >>> >>> I'm trying to test a scenario where I have an IPA server set up in >>> another data center, and trust is established with an AD domain >>> controller (dc-2) in that data-center. >>> This domain controller takes dc-1 as it's authoritative source. >>> Ideally, the IPA server will interact with the domain controller >>> nearest to it (i.e dc-2), however, from tcpdump, I note the following: >>> >>> - IPA server communicates with dc-2 first >>> - dc-2 returns a list of domain controllers in all the datacenters, >>> including dc-1 >>> the IPA server then begins querying ldap and kerberos ports on dc-1, >>> the domain controller furthest from it. >>> - Authentication on clients fail >>> >>> My question is: Is it possible to get IPA to query and interact only >>> with the domain controller it initially established trust with? >> >> Let's first separate multiple issues. >> >> 1. Terminology >> Cross-forest trust is established between domain controllers in forest >> root >> domains. In case of IPA we need that access only once, when trust is >> created. You don't need to establish trust again with dc-2 once you >> have established it with dc-1. >> >> When trust is established, AD DCs will look up IPA masters via SRV >> records in DNS (_ldap._tcp.). We don't provide >> site-specific SRV records as IPA does not handle sites in this area >> yet. >> > > >Thanks for the clarification. > > >> However, this is not your problem. >> >> 2. User and group lookups are done by SSSD against global catalog >> service (_gc._tcp.) and AD DS (_ldap._tcp.), >> along with Kerberos KDC (AD DCs). >> >> These DCs are found via SRV records in DNS and SSSD since 1.9.5 >> uses site-specific SRV records for AD domain controllers lookups in >> case of IPA-AD trust. >> >> You are interested in (2) being site-aware. However, you didn't say what >> is your distribution and software versions so it is quite hard to give >> any recommendation. > >My objective is basically distribution of IPA servers across multiple >data centers linked by a WAN: > >- There is a central 'head office' with an AD domain-controller, this >is the primary source of identity for the domain. >- A number of other data-centers each have their own local AD domain >controller linked to the head-office domain controller >- The datacenters are in different timezones. >- An IPA server in each data-center with trust established with the >local domain controller >- Each IPA server is configured with it's own realm, but provides >access to the global AD domain via AD Trusts > >The idea was to prevent IPA authentication related traffic going >across the WAN (latency, different time-zones etc) to a central ad >domain controller at head office. So this setup seemed reasonable. Do you have sites defined in AD? If so, can you enable debug_level=10 in /etc/sssd/sssd.conf on IPA master in the other datacenter and attempt to login as AD user. We'll see in SSSD logs how it discovers what AD DC to talk to. Add following to /etc/sssd/sssd.conf: [domain/..] .. debug_level = 10 [nss] debug_level = 10 and restart sssd. >I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, >the working setup was based on this howto: > >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description > >... which works fine if the IPA server has a trust relationship >directly with the primary domain controller at head office (which it >is collocated with). > >I can live without site-awareness per se if I can achieve IPA >centralised authentication across datacenters in different timezones, >with AD as the primary source of identity. An alternative setup that >I've considered testing: > >- IPA server at the head office with trust established to the primary AD DC. >- A replica of the primary in each DC (different timezones), on the same realm Currently each master has to be prepared with ipa-adtrust-install if any of IPA clients connected to this master need to be accessible to AD users. -- / Alexander Bokovoy From dpal at redhat.com Mon Mar 9 18:58:14 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Mar 2015 14:58:14 -0400 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: References: <20150309170400.GC25455@redhat.com> Message-ID: <54FDED46.9020208@redhat.com> On 03/09/2015 02:29 PM, Traiano Welcome wrote: > Hi Alexander > > Thanks for the response: > > On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy wrote: >> On Mon, 09 Mar 2015, Traiano Welcome wrote: >>> Hi List >>> >>> >>> I have AD trusts configured and working between an IPA server and a >>> "master" primary domain controller (dc-1) in a forest in one data >>> center. This allows me to connect with SSH to linux servers in the >>> same data-center, authenticating with my AD credentials. >>> >>> I'm trying to test a scenario where I have an IPA server set up in >>> another data center, and trust is established with an AD domain >>> controller (dc-2) in that data-center. >>> This domain controller takes dc-1 as it's authoritative source. >>> Ideally, the IPA server will interact with the domain controller >>> nearest to it (i.e dc-2), however, from tcpdump, I note the following: >>> >>> - IPA server communicates with dc-2 first >>> - dc-2 returns a list of domain controllers in all the datacenters, >>> including dc-1 >>> the IPA server then begins querying ldap and kerberos ports on dc-1, >>> the domain controller furthest from it. >>> - Authentication on clients fail >>> >>> My question is: Is it possible to get IPA to query and interact only >>> with the domain controller it initially established trust with? >> Let's first separate multiple issues. >> >> 1. Terminology >> Cross-forest trust is established between domain controllers in forest >> root >> domains. In case of IPA we need that access only once, when trust is >> created. You don't need to establish trust again with dc-2 once you >> have established it with dc-1. >> >> When trust is established, AD DCs will look up IPA masters via SRV >> records in DNS (_ldap._tcp.). We don't provide >> site-specific SRV records as IPA does not handle sites in this area >> yet. >> > > Thanks for the clarification. > > >> However, this is not your problem. >> >> 2. User and group lookups are done by SSSD against global catalog >> service (_gc._tcp.) and AD DS (_ldap._tcp.), >> along with Kerberos KDC (AD DCs). >> >> These DCs are found via SRV records in DNS and SSSD since 1.9.5 >> uses site-specific SRV records for AD domain controllers lookups in >> case of IPA-AD trust. >> >> You are interested in (2) being site-aware. However, you didn't say what >> is your distribution and software versions so it is quite hard to give >> any recommendation. > My objective is basically distribution of IPA servers across multiple > data centers linked by a WAN: > > - There is a central 'head office' with an AD domain-controller, this > is the primary source of identity for the domain. > - A number of other data-centers each have their own local AD domain > controller linked to the head-office domain controller > - The datacenters are in different timezones. > - An IPA server in each data-center with trust established with the > local domain controller > - Each IPA server is configured with it's own realm, but provides > access to the global AD domain via AD Trusts > > The idea was to prevent IPA authentication related traffic going > across the WAN (latency, different time-zones etc) to a central ad > domain controller at head office. So this setup seemed reasonable. > > I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, > the working setup was based on this howto: > > http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description > > ... which works fine if the IPA server has a trust relationship > directly with the primary domain controller at head office (which it > is collocated with). > > I can live without site-awareness per se if I can achieve IPA > centralised authentication across datacenters in different timezones, > with AD as the primary source of identity. An alternative setup that > I've considered testing: > > - IPA server at the head office with trust established to the primary AD DC. > - A replica of the primary in each DC (different timezones), on the same realm > > However, I doubt replicas can work across timezones, and with high WAN > latencies. > As Alexander said the trust on the fores level. There is no pairing between IPA replicas and AD DCs to a specific data center. What you need to concentrate is making sure that SSSD on a client picks AD in the local data center and IPA in the same data center (for the additional lookup operations). I do not know whether one can explicitly set this in sssd.conf. This is something to ask SSSD list. The alternative would be to make DNS return the right server. For AD DC the AD DNS will be returning the server to authenticate against and there should be a way to configure AD DNS this way. I do not think it is possible to force specific DNS entry out of IPA - it does not support sites yet. But may be there is a way to override it on SSSD. In case of other (legacy Linux or other platforms) clients that talk to IPA you can configure them with the explicit fail over list. They do not talk to AD directly. You might also consider configuring SSSD on the IPA server to use AD in the same location as a primary server. HTH >> -- >> / Alexander Bokovoy > Thanks, > Traiano > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jhrozek at redhat.com Mon Mar 9 19:40:05 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 9 Mar 2015 20:40:05 +0100 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: <54FDED46.9020208@redhat.com> References: <20150309170400.GC25455@redhat.com> <54FDED46.9020208@redhat.com> Message-ID: <20150309194005.GY29063@hendrix.arn.redhat.com> On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: > On 03/09/2015 02:29 PM, Traiano Welcome wrote: > >Hi Alexander > > > > Thanks for the response: > > > >On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy wrote: > >>On Mon, 09 Mar 2015, Traiano Welcome wrote: > >>>Hi List > >>> > >>> > >>>I have AD trusts configured and working between an IPA server and a > >>>"master" primary domain controller (dc-1) in a forest in one data > >>>center. This allows me to connect with SSH to linux servers in the > >>>same data-center, authenticating with my AD credentials. > >>> > >>>I'm trying to test a scenario where I have an IPA server set up in > >>>another data center, and trust is established with an AD domain > >>>controller (dc-2) in that data-center. > >>>This domain controller takes dc-1 as it's authoritative source. > >>>Ideally, the IPA server will interact with the domain controller > >>>nearest to it (i.e dc-2), however, from tcpdump, I note the following: > >>> > >>>- IPA server communicates with dc-2 first > >>>- dc-2 returns a list of domain controllers in all the datacenters, > >>>including dc-1 > >>>the IPA server then begins querying ldap and kerberos ports on dc-1, > >>>the domain controller furthest from it. > >>>- Authentication on clients fail > >>> > >>>My question is: Is it possible to get IPA to query and interact only > >>>with the domain controller it initially established trust with? > >>Let's first separate multiple issues. > >> > >>1. Terminology > >> Cross-forest trust is established between domain controllers in forest > >>root > >> domains. In case of IPA we need that access only once, when trust is > >> created. You don't need to establish trust again with dc-2 once you > >> have established it with dc-1. > >> > >> When trust is established, AD DCs will look up IPA masters via SRV > >> records in DNS (_ldap._tcp.). We don't provide > >> site-specific SRV records as IPA does not handle sites in this area > >> yet. > >> > > > >Thanks for the clarification. > > > > > >> However, this is not your problem. > >> > >>2. User and group lookups are done by SSSD against global catalog > >> service (_gc._tcp.) and AD DS (_ldap._tcp.), > >> along with Kerberos KDC (AD DCs). > >> > >> These DCs are found via SRV records in DNS and SSSD since 1.9.5 > >> uses site-specific SRV records for AD domain controllers lookups in > >> case of IPA-AD trust. > >> > >>You are interested in (2) being site-aware. However, you didn't say what > >>is your distribution and software versions so it is quite hard to give > >>any recommendation. > >My objective is basically distribution of IPA servers across multiple > >data centers linked by a WAN: > > > >- There is a central 'head office' with an AD domain-controller, this > >is the primary source of identity for the domain. > >- A number of other data-centers each have their own local AD domain > >controller linked to the head-office domain controller > >- The datacenters are in different timezones. > >- An IPA server in each data-center with trust established with the > >local domain controller > >- Each IPA server is configured with it's own realm, but provides > >access to the global AD domain via AD Trusts > > > >The idea was to prevent IPA authentication related traffic going > >across the WAN (latency, different time-zones etc) to a central ad > >domain controller at head office. So this setup seemed reasonable. > > > >I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, > >the working setup was based on this howto: > > > >http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description > > > >... which works fine if the IPA server has a trust relationship > >directly with the primary domain controller at head office (which it > >is collocated with). > > > >I can live without site-awareness per se if I can achieve IPA > >centralised authentication across datacenters in different timezones, > >with AD as the primary source of identity. An alternative setup that > >I've considered testing: > > > >- IPA server at the head office with trust established to the primary AD DC. > >- A replica of the primary in each DC (different timezones), on the same realm > > > >However, I doubt replicas can work across timezones, and with high WAN > > latencies. > > > > > As Alexander said the trust on the fores level. > There is no pairing between IPA replicas and AD DCs to a specific data > center. > > What you need to concentrate is making sure that SSSD on a client picks AD > in the local data center and IPA in the same data center (for the additional > lookup operations). > I do not know whether one can explicitly set this in sssd.conf. This is > something to ask SSSD list. The alternative would be to make DNS return the > right server. You can set the site and the DNS domain for the direct integration, but not for the server mode. The server mode is designed to operate with mostly defaults -- the reason not being that much that we don't want to support configuration, but the current failover code can't handle two totally separate domains in a single back end. This is a known pain point me and Pavel Brezina were talking about for a long time. So far there hasn't been a driver that would justify refactoring the failover layer to achive this functionality. > For AD DC the AD DNS will be returning the server to authenticate against > and there should be a way to configure AD DNS this way. > I do not think it is possible to force specific DNS entry out of IPA - it > does not support sites yet. But may be there is a way to override it on > SSSD. > > In case of other (legacy Linux or other platforms) clients that talk to IPA > you can configure them with the explicit fail over list. They do not talk to > AD directly. > You might also consider configuring SSSD on the IPA server to use AD in the > same location as a primary server. SSSD on the IPA server /does/ support DNS sites, but only the DNS autodiscovery. Unfortunately you can't specify a custom site.. From jbaird at follett.com Mon Mar 9 21:05:37 2015 From: jbaird at follett.com (Baird, Josh) Date: Mon, 9 Mar 2015 21:05:37 +0000 Subject: [Freeipa-users] Error establishing trust with AD domain Message-ID: Hi, I have successfully established a trust in my lab environment running IPA 4.1 (RHEL7.1) and a Windows 2008 R2 domain with Windows 2003 domain/forest functional levels. I'm now trying to establish a trust with my production AD domain (same functional level). The only difference is that my production domain (ad.domain.lan) is a child-domain of a forest named domain.lan. There is no forest in my lab envrionment. I'm getting the following error when running 'ipa trust-add': # ipa trust-add --type ad ad.domain.lan --range-type=ipa-ad-trust --admin jbadmin --password Active Directory domain administrator's password: ipa: ERROR: Domain 'ad.domain.lan' is not a root domain for forest 'domain.lan' Any ideas? Thanks, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbaird at follett.com Mon Mar 9 21:28:50 2015 From: jbaird at follett.com (Baird, Josh) Date: Mon, 9 Mar 2015 21:28:50 +0000 Subject: [Freeipa-users] Error establishing trust with AD domain In-Reply-To: References: Message-ID: Ok - I'll answer my own question. I needed to establish the trust with the forest-root domain (domain.com), not the child domain. I have verified using 'ipa trustdomain-find' that I can see the child domain (ad.domain.com) now. Sorry for the noise! Thanks, Josh From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Baird, Josh Sent: Monday, March 09, 2015 5:06 PM To: freeipa-users at redhat.com Subject: [Freeipa-users] Error establishing trust with AD domain Hi, I have successfully established a trust in my lab environment running IPA 4.1 (RHEL7.1) and a Windows 2008 R2 domain with Windows 2003 domain/forest functional levels. I'm now trying to establish a trust with my production AD domain (same functional level). The only difference is that my production domain (ad.domain.lan) is a child-domain of a forest named domain.lan. There is no forest in my lab envrionment. I'm getting the following error when running 'ipa trust-add': # ipa trust-add --type ad ad.domain.lan --range-type=ipa-ad-trust --admin jbadmin --password Active Directory domain administrator's password: ipa: ERROR: Domain 'ad.domain.lan' is not a root domain for forest 'domain.lan' Any ideas? Thanks, Josh -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Mar 9 21:35:55 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 9 Mar 2015 21:35:55 +0000 Subject: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. In-Reply-To: References: Message-ID: <1425936805454.63030@vuw.ac.nz> Any idea what is going on here please? ========== [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck Checking forwarders, please wait ... WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers Please fix forwarder configuration to enable DNSSEC support. (For BIND 9 add directive "dnssec-enable yes;" to "options {}") WARNING: DNSSEC validation will be disabled Directory Manager (existing master) password: Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file Using reverse zone(s) 32.100.10.in-addr.arpa. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/35]: creating directory server user [2/35]: creating directory server instance [3/35]: adding default schema [4/35]: enabling memberof plugin [5/35]: enabling winsync plugin [6/35]: configuring replication version plugin [7/35]: enabling IPA enrollment plugin [8/35]: enabling ldapi [9/35]: configuring uniqueness plugin [10/35]: configuring uuid plugin [11/35]: configuring modrdn plugin [12/35]: configuring DNS plugin [13/35]: enabling entryUSN plugin [14/35]: configuring lockout plugin [15/35]: creating indices [16/35]: enabling referential integrity plugin [17/35]: configuring ssl for ds instance [18/35]: configuring certmap.conf [19/35]: configure autobind for root [20/35]: configure new location for managed entries [21/35]: configure dirsrv ccache [22/35]: enable SASL mapping fallback [23/35]: restarting directory server [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 128 seconds elapsed [vuwunicoipam002.ods.vuw.ac.nz] 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. Failed to start replication [root at vuwunicoipam004 ipa-certs]# ======== No firewalls are active and the network is a simple vyos virtual router. ===== [root at vuwunicoipam002 etc]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at vuwunicoipam002 etc]# ===== ===== Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at vuwunicoipam004 ipa-certs]# ===== regards Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Mon Mar 9 22:02:30 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Mon, 09 Mar 2015 16:02:30 -0600 Subject: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. In-Reply-To: <1425936805454.63030@vuw.ac.nz> References: <1425936805454.63030@vuw.ac.nz> Message-ID: <54FE1876.5060509@redhat.com> On 03/09/2015 03:35 PM, Steven Jones wrote: > > Any idea what is going on here please? > > > ========== > > [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck > Checking forwarders, please wait ... > WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers > Please fix forwarder configuration to enable DNSSEC support. > (For BIND 9 add directive "dnssec-enable yes;" to "options {}") > WARNING: DNSSEC validation will be disabled I don't know if this is a problem, so I will leave it to our DNS gurus to answer. > Directory Manager (existing master) password: > > Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file > Using reverse zone(s) 32.100.10.in-addr.arpa. > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv): Estimated time 1 minute > [1/35]: creating directory server user > [2/35]: creating directory server instance > [3/35]: adding default schema > [4/35]: enabling memberof plugin > [5/35]: enabling winsync plugin > [6/35]: configuring replication version plugin > [7/35]: enabling IPA enrollment plugin > [8/35]: enabling ldapi > [9/35]: configuring uniqueness plugin > [10/35]: configuring uuid plugin > [11/35]: configuring modrdn plugin > [12/35]: configuring DNS plugin > [13/35]: enabling entryUSN plugin > [14/35]: configuring lockout plugin > [15/35]: creating indices > [16/35]: enabling referential integrity plugin > [17/35]: configuring ssl for ds instance > [18/35]: configuring certmap.conf > [19/35]: configure autobind for root > [20/35]: configure new location for managed entries > [21/35]: configure dirsrv ccache > [22/35]: enable SASL mapping fallback > [23/35]: restarting directory server > [24/35]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 128 seconds elapsed > [vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] If the client got back a referral, it means the replica was being re-initialized at this time. Sounds like either the client is not checking to see if the initialization is complete, or the server is reporting back erroneously that initialization is complete. > > [error] RuntimeError: Failed to start replication > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Failed to start replication > [root at vuwunicoipam004 ipa-certs]# > ======== > > No firewalls are active and the network is a simple vyos virtual router. > > > ===== > > [root at vuwunicoipam002 etc]# iptables -L -n > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > [root at vuwunicoipam002 etc]# > ===== > > ===== > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > [root at vuwunicoipam004 ipa-certs]# > ===== > > > > > regards > > Steven > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Mon Mar 9 23:58:42 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 9 Mar 2015 23:58:42 +0000 Subject: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. In-Reply-To: <54FE1876.5060509@redhat.com> References: <1425936805454.63030@vuw.ac.nz>,<54FE1876.5060509@redhat.com> Message-ID: <1425945372163.97047@vuw.ac.nz> ====== 2015-03-09T21:15:31Z DEBUG flushing ldap://vuwunicoipam002.ods.vuw.ac.nz:389 from SchemaCache 2015-03-09T21:15:31Z DEBUG retrieving schema for SchemaCache url=ldap://vuwunicoipam002.ods.vuw.ac.nz:389 conn= 2015-03-09T21:15:31Z DEBUG flushing ldaps://vuwunicoipam004.ods.vuw.ac.nz:636 from SchemaCache 2015-03-09T21:15:31Z DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam004.ods.vuw.ac.nz:636 conn= 2015-03-09T21:17: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 969, in setup_replication raise RuntimeError("Failed to start replication") RuntimeError: Failed to start replication 2015-03-09T21:17:42Z DEBUG [error] RuntimeError: Failed to start replication 2015-03-09T21:17:42Z 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 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 969, in setup_replication raise RuntimeError("Failed to start replication") 2015-03-09T21:17:42Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: Failed to start replication ========== replica log. ? regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Rich Megginson Sent: Tuesday, 10 March 2015 11:02 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. On 03/09/2015 03:35 PM, Steven Jones wrote: Any idea what is going on here please? ========== [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck Checking forwarders, please wait ... WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers Please fix forwarder configuration to enable DNSSEC support. (For BIND 9 add directive "dnssec-enable yes;" to "options {}") WARNING: DNSSEC validation will be disabled I don't know if this is a problem, so I will leave it to our DNS gurus to answer. Directory Manager (existing master) password: Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file Using reverse zone(s) 32.100.10.in-addr.arpa. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/35]: creating directory server user [2/35]: creating directory server instance [3/35]: adding default schema [4/35]: enabling memberof plugin [5/35]: enabling winsync plugin [6/35]: configuring replication version plugin [7/35]: enabling IPA enrollment plugin [8/35]: enabling ldapi [9/35]: configuring uniqueness plugin [10/35]: configuring uuid plugin [11/35]: configuring modrdn plugin [12/35]: configuring DNS plugin [13/35]: enabling entryUSN plugin [14/35]: configuring lockout plugin [15/35]: creating indices [16/35]: enabling referential integrity plugin [17/35]: configuring ssl for ds instance [18/35]: configuring certmap.conf [19/35]: configure autobind for root [20/35]: configure new location for managed entries [21/35]: configure dirsrv ccache [22/35]: enable SASL mapping fallback [23/35]: restarting directory server [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 128 seconds elapsed [vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] If the client got back a referral, it means the replica was being re-initialized at this time. Sounds like either the client is not checking to see if the initialization is complete, or the server is reporting back erroneously that initialization is complete. [error] RuntimeError: Failed to start replication Your system may be partly configured. Run /usr/sbin/ipa-server-install --uninstall to clean up. Failed to start replication [root at vuwunicoipam004 ipa-certs]# ======== No firewalls are active and the network is a simple vyos virtual router. ===== [root at vuwunicoipam002 etc]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at vuwunicoipam002 etc]# ===== ===== Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at vuwunicoipam004 ipa-certs]# ===== regards Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From reesb at hushmail.com Tue Mar 10 00:22:21 2015 From: reesb at hushmail.com (reesb at hushmail.com) Date: Tue, 10 Mar 2015 08:22:21 +0800 Subject: [Freeipa-users] Adding FreeIPA as a vsphere identity source In-Reply-To: <54F95AF6.7010604@redhat.com> References: <20150304084354.97EB2C043D@smtp.hushmail.com> <54F6FB5D.1050606@redhat.com> <20150305011322.B02F2C043C@smtp.hushmail.com> <20150305013712.23AB3C043C@smtp.hushmail.com> <54F80BB6.7090405@redhat.com> <20150305081603.64785C043C@smtp.hushmail.com> <54F8255E.4000401@redhat.com> <20150306012439.1D96BC043C@smtp.hushmail.com> <54F9553E.4050703@redhat.com> <20150306073557.GS25455@redhat.com> <54F95AF6.7010604@redhat.com> Message-ID: <20150310002221.E0A3D20341@smtp.hushmail.com> I've update the ACI's but am still getting the same error as before. I am guessing this is probably related to the same issue in the other concurrent vsphere 5.5 email thread that is going. I'll just keep my eye on that to see the resolution. On 3/6/2015 at 3:45 PM, "Martin Kosek" wrote: > >On 03/06/2015 08:35 AM, Alexander Bokovoy wrote: >> On Fri, 06 Mar 2015, Martin Kosek wrote: >>> On 03/06/2015 02:24 AM, reesb at hushmail.com wrote: >>>> Just to confirm I should restart the server after i've run the >ldapmodify? >>> >>> Right. It would be safer thing to do, if you modified the Schema >>> Compatibility config. At least to make sure it re-creates the >entries from >>> scratch. >>> >>>> Also I've used ldap modify to remove the 'uniqueMember' object >class from >>>> the compat schema and added the 'sn=%{sn}' attribute and I >still am having >>>> no luck. I get the same 'identity source may be malfunctioning >error' from >>>> vpshere. >>> >>> The key here is to see the Directory Server access log, to see >what kind of >>> LDAP searches is vSphere doing and then seeing the actual >entries in FreeIPA >>> with ldapsearch (or any GUI, I use Apache Directory Studio). >With this >>> knowledge, you should just need to update either the Schema >Compatibility >>> plugin configuration or vSphere configuration. >> Note also that in 4.1 we have ACIs that only give access to >certain >> attributes within compat tree and not all of them. Adding a new >> attribute requires to add an ACI to allow serving it. >> >> If this is an issue, you'd see the difference when accessing as >> cn=Directory Manager or as any other authenticated bind. > >Very good point Alexander! I unfortunately did my tests either as >admin or DM. >I updated the HOWTO with the new step that fixed it for me. > >http://www.freeipa.org/page/HowTo/vsphere5_integration#Permission_U >pdate > >So reesb, after the update above, you should get it working. > >Martin From dpal at redhat.com Tue Mar 10 00:22:30 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Mar 2015 20:22:30 -0400 Subject: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. In-Reply-To: <1425936805454.63030@vuw.ac.nz> References: <1425936805454.63030@vuw.ac.nz> Message-ID: <54FE3946.4090805@redhat.com> On 03/09/2015 05:35 PM, Steven Jones wrote: > > Any idea what is going on here please? > > > ========== > > [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck Why are you skipping a connection check? The check will find issues like this ahead of time. I suspect there is something wrong with either DNS entries for LDAP server records or LDAP or Kerberos port is not open between new replica and master. At least I would try with connection check on and see if it gives some hints. > Checking forwarders, please wait ... > WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers > Please fix forwarder configuration to enable DNSSEC support. > (For BIND 9 add directive "dnssec-enable yes;" to "options {}") > WARNING: DNSSEC validation will be disabled > Directory Manager (existing master) password: > > Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file > Using reverse zone(s) 32.100.10.in-addr.arpa. > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv): Estimated time 1 minute > [1/35]: creating directory server user > [2/35]: creating directory server instance > [3/35]: adding default schema > [4/35]: enabling memberof plugin > [5/35]: enabling winsync plugin > [6/35]: configuring replication version plugin > [7/35]: enabling IPA enrollment plugin > [8/35]: enabling ldapi > [9/35]: configuring uniqueness plugin > [10/35]: configuring uuid plugin > [11/35]: configuring modrdn plugin > [12/35]: configuring DNS plugin > [13/35]: enabling entryUSN plugin > [14/35]: configuring lockout plugin > [15/35]: creating indices > [16/35]: enabling referential integrity plugin > [17/35]: configuring ssl for ds instance > [18/35]: configuring certmap.conf > [19/35]: configure autobind for root > [20/35]: configure new location for managed entries > [21/35]: configure dirsrv ccache > [22/35]: enable SASL mapping fallback > [23/35]: restarting directory server > [24/35]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 128 seconds elapsed > [vuwunicoipam002.ods.vuw.ac.nz] 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. > > Failed to start replication > [root at vuwunicoipam004 ipa-certs]# > ======== > > No firewalls are active and the network is a simple vyos virtual router. > > > ===== > > [root at vuwunicoipam002 etc]# iptables -L -n > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > [root at vuwunicoipam002 etc]# > ===== > > ===== > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > [root at vuwunicoipam004 ipa-certs]# > ===== > > > > > regards > > Steven > > > -- 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 Mar 10 00:27:05 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 09 Mar 2015 20:27:05 -0400 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: <20150309194005.GY29063@hendrix.arn.redhat.com> References: <20150309170400.GC25455@redhat.com> <54FDED46.9020208@redhat.com> <20150309194005.GY29063@hendrix.arn.redhat.com> Message-ID: <54FE3A59.2080206@redhat.com> On 03/09/2015 03:40 PM, Jakub Hrozek wrote: > On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: >> On 03/09/2015 02:29 PM, Traiano Welcome wrote: >>> Hi Alexander >>> >>> Thanks for the response: >>> >>> On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy wrote: >>>> On Mon, 09 Mar 2015, Traiano Welcome wrote: >>>>> Hi List >>>>> >>>>> >>>>> I have AD trusts configured and working between an IPA server and a >>>>> "master" primary domain controller (dc-1) in a forest in one data >>>>> center. This allows me to connect with SSH to linux servers in the >>>>> same data-center, authenticating with my AD credentials. >>>>> >>>>> I'm trying to test a scenario where I have an IPA server set up in >>>>> another data center, and trust is established with an AD domain >>>>> controller (dc-2) in that data-center. >>>>> This domain controller takes dc-1 as it's authoritative source. >>>>> Ideally, the IPA server will interact with the domain controller >>>>> nearest to it (i.e dc-2), however, from tcpdump, I note the following: >>>>> >>>>> - IPA server communicates with dc-2 first >>>>> - dc-2 returns a list of domain controllers in all the datacenters, >>>>> including dc-1 >>>>> the IPA server then begins querying ldap and kerberos ports on dc-1, >>>>> the domain controller furthest from it. >>>>> - Authentication on clients fail >>>>> >>>>> My question is: Is it possible to get IPA to query and interact only >>>>> with the domain controller it initially established trust with? >>>> Let's first separate multiple issues. >>>> >>>> 1. Terminology >>>> Cross-forest trust is established between domain controllers in forest >>>> root >>>> domains. In case of IPA we need that access only once, when trust is >>>> created. You don't need to establish trust again with dc-2 once you >>>> have established it with dc-1. >>>> >>>> When trust is established, AD DCs will look up IPA masters via SRV >>>> records in DNS (_ldap._tcp.). We don't provide >>>> site-specific SRV records as IPA does not handle sites in this area >>>> yet. >>>> >>> Thanks for the clarification. >>> >>> >>>> However, this is not your problem. >>>> >>>> 2. User and group lookups are done by SSSD against global catalog >>>> service (_gc._tcp.) and AD DS (_ldap._tcp.), >>>> along with Kerberos KDC (AD DCs). >>>> >>>> These DCs are found via SRV records in DNS and SSSD since 1.9.5 >>>> uses site-specific SRV records for AD domain controllers lookups in >>>> case of IPA-AD trust. >>>> >>>> You are interested in (2) being site-aware. However, you didn't say what >>>> is your distribution and software versions so it is quite hard to give >>>> any recommendation. >>> My objective is basically distribution of IPA servers across multiple >>> data centers linked by a WAN: >>> >>> - There is a central 'head office' with an AD domain-controller, this >>> is the primary source of identity for the domain. >>> - A number of other data-centers each have their own local AD domain >>> controller linked to the head-office domain controller >>> - The datacenters are in different timezones. >>> - An IPA server in each data-center with trust established with the >>> local domain controller >>> - Each IPA server is configured with it's own realm, but provides >>> access to the global AD domain via AD Trusts >>> >>> The idea was to prevent IPA authentication related traffic going >>> across the WAN (latency, different time-zones etc) to a central ad >>> domain controller at head office. So this setup seemed reasonable. >>> >>> I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, >>> the working setup was based on this howto: >>> >>> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description >>> >>> ... which works fine if the IPA server has a trust relationship >>> directly with the primary domain controller at head office (which it >>> is collocated with). >>> >>> I can live without site-awareness per se if I can achieve IPA >>> centralised authentication across datacenters in different timezones, >>> with AD as the primary source of identity. An alternative setup that >>> I've considered testing: >>> >>> - IPA server at the head office with trust established to the primary AD DC. >>> - A replica of the primary in each DC (different timezones), on the same realm >>> >>> However, I doubt replicas can work across timezones, and with high WAN >>> latencies. >>> >> >> As Alexander said the trust on the fores level. >> There is no pairing between IPA replicas and AD DCs to a specific data >> center. >> >> What you need to concentrate is making sure that SSSD on a client picks AD >> in the local data center and IPA in the same data center (for the additional >> lookup operations). >> I do not know whether one can explicitly set this in sssd.conf. This is >> something to ask SSSD list. The alternative would be to make DNS return the >> right server. > You can set the site and the DNS domain for the direct integration, but not > for the server mode. The server mode is designed to operate with mostly > defaults -- the reason not being that much that we don't want to support > configuration, but the current failover code can't handle two totally > separate domains in a single back end. > > This is a known pain point me and Pavel Brezina were talking about for a > long time. So far there hasn't been a driver that would justify > refactoring the failover layer to achive this functionality. > >> For AD DC the AD DNS will be returning the server to authenticate against >> and there should be a way to configure AD DNS this way. >> I do not think it is possible to force specific DNS entry out of IPA - it >> does not support sites yet. But may be there is a way to override it on >> SSSD. >> >> In case of other (legacy Linux or other platforms) clients that talk to IPA >> you can configure them with the explicit fail over list. They do not talk to >> AD directly. >> You might also consider configuring SSSD on the IPA server to use AD in the >> same location as a primary server. > SSSD on the IPA server /does/ support DNS sites, but only the DNS > autodiscovery. Unfortunately you can't specify a custom site.. > It looks like time to file a ticket(s) to support this kind of functionality (affinity to AD controllers within the same site). -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From Steven.Jones at vuw.ac.nz Tue Mar 10 00:36:37 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 10 Mar 2015 00:36:37 +0000 Subject: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. In-Reply-To: <54FE3946.4090805@redhat.com> References: <1425936805454.63030@vuw.ac.nz>,<54FE3946.4090805@redhat.com> Message-ID: <1425947647382.60679@vuw.ac.nz> It usually fails, hence I skip it. Since I have no firewall either side and I know I have a simple network since I built there is nothing possible blocking in-between. I will double check the DNS zone file. I had to rename the server to ipam004 as the replica attempt sulked if i re-used an old hostname, ipam001. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Tuesday, 10 March 2015 1:22 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. On 03/09/2015 05:35 PM, Steven Jones wrote: Any idea what is going on here please? ========== [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck Why are you skipping a connection check? The check will find issues like this ahead of time. I suspect there is something wrong with either DNS entries for LDAP server records or LDAP or Kerberos port is not open between new replica and master. At least I would try with connection check on and see if it gives some hints. Checking forwarders, please wait ... WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers Please fix forwarder configuration to enable DNSSEC support. (For BIND 9 add directive "dnssec-enable yes;" to "options {}") WARNING: DNSSEC validation will be disabled Directory Manager (existing master) password: Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file Using reverse zone(s) 32.100.10.in-addr.arpa. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/35]: creating directory server user [2/35]: creating directory server instance [3/35]: adding default schema [4/35]: enabling memberof plugin [5/35]: enabling winsync plugin [6/35]: configuring replication version plugin [7/35]: enabling IPA enrollment plugin [8/35]: enabling ldapi [9/35]: configuring uniqueness plugin [10/35]: configuring uuid plugin [11/35]: configuring modrdn plugin [12/35]: configuring DNS plugin [13/35]: enabling entryUSN plugin [14/35]: configuring lockout plugin [15/35]: creating indices [16/35]: enabling referential integrity plugin [17/35]: configuring ssl for ds instance [18/35]: configuring certmap.conf [19/35]: configure autobind for root [20/35]: configure new location for managed entries [21/35]: configure dirsrv ccache [22/35]: enable SASL mapping fallback [23/35]: restarting directory server [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 128 seconds elapsed [vuwunicoipam002.ods.vuw.ac.nz] 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. Failed to start replication [root at vuwunicoipam004 ipa-certs]# ======== No firewalls are active and the network is a simple vyos virtual router. ===== [root at vuwunicoipam002 etc]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at vuwunicoipam002 etc]# ===== ===== Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at vuwunicoipam004 ipa-certs]# ===== regards Steven -- 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 Mar 10 00:47:56 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 10 Mar 2015 00:47:56 +0000 Subject: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. In-Reply-To: <1425947647382.60679@vuw.ac.nz> References: <1425936805454.63030@vuw.ac.nz>, <54FE3946.4090805@redhat.com>, <1425947647382.60679@vuw.ac.nz> Message-ID: <1425948326445.18944@vuw.ac.nz> ========= Check connection from replica to remote master 'vuwunicoipam002.ods.vuw.ac.nz': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos Kpasswd: TCP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK The following list of ports use UDP protocol and would need to be checked manually: Kerberos KDC: UDP (88): SKIPPED Kerberos Kpasswd: UDP (464): SKIPPED Connection from replica to master is OK. Start listening on required ports for remote master check Get credentials to log in to remote master admin at ODS.VUW.AC.NZ password: Check SSH connection to remote master Execute check on remote master Check connection from master to remote replica 'vuwunicoipam004.ods.vuw.ac.nz': Directory Service: Unsecure port (389): OK Directory Service: Secure port (636): OK Kerberos KDC: TCP (88): OK Kerberos KDC: UDP (88): OK Kerberos Kpasswd: TCP (464): OK Kerberos Kpasswd: UDP (464): OK HTTP Server: Unsecure port (80): OK HTTP Server: Secure port (443): OK Connection from master to replica is OK. ipa : DEBUG Process finished, return code=0 Connection check OK ========== regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Steven Jones Sent: Tuesday, 10 March 2015 1:36 p.m. To: freeipa-users at redhat.com; dpal at redhat.com Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. It usually fails, hence I skip it. Since I have no firewall either side and I know I have a simple network since I built there is nothing possible blocking in-between. I will double check the DNS zone file. I had to rename the server to ipam004 as the replica attempt sulked if i re-used an old hostname, ipam001. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Tuesday, 10 March 2015 1:22 p.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. On 03/09/2015 05:35 PM, Steven Jones wrote: Any idea what is going on here please? ========== [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck Why are you skipping a connection check? The check will find issues like this ahead of time. I suspect there is something wrong with either DNS entries for LDAP server records or LDAP or Kerberos port is not open between new replica and master. At least I would try with connection check on and see if it gives some hints. Checking forwarders, please wait ... WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers Please fix forwarder configuration to enable DNSSEC support. (For BIND 9 add directive "dnssec-enable yes;" to "options {}") WARNING: DNSSEC validation will be disabled Directory Manager (existing master) password: Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file Using reverse zone(s) 32.100.10.in-addr.arpa. Configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/35]: creating directory server user [2/35]: creating directory server instance [3/35]: adding default schema [4/35]: enabling memberof plugin [5/35]: enabling winsync plugin [6/35]: configuring replication version plugin [7/35]: enabling IPA enrollment plugin [8/35]: enabling ldapi [9/35]: configuring uniqueness plugin [10/35]: configuring uuid plugin [11/35]: configuring modrdn plugin [12/35]: configuring DNS plugin [13/35]: enabling entryUSN plugin [14/35]: configuring lockout plugin [15/35]: creating indices [16/35]: enabling referential integrity plugin [17/35]: configuring ssl for ds instance [18/35]: configuring certmap.conf [19/35]: configure autobind for root [20/35]: configure new location for managed entries [21/35]: configure dirsrv ccache [22/35]: enable SASL mapping fallback [23/35]: restarting directory server [24/35]: setting up initial replication Starting replication, please wait until this has completed. Update in progress, 128 seconds elapsed [vuwunicoipam002.ods.vuw.ac.nz] 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. Failed to start replication [root at vuwunicoipam004 ipa-certs]# ======== No firewalls are active and the network is a simple vyos virtual router. ===== [root at vuwunicoipam002 etc]# iptables -L -n Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at vuwunicoipam002 etc]# ===== ===== Chain INPUT (policy ACCEPT) target prot opt source destination Chain FORWARD (policy ACCEPT) target prot opt source destination Chain OUTPUT (policy ACCEPT) target prot opt source destination [root at vuwunicoipam004 ipa-certs]# ===== regards Steven -- 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 Tue Mar 10 08:28:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 10 Mar 2015 09:28:27 +0100 Subject: [Freeipa-users] Errors while adding DNS Zone In-Reply-To: References: Message-ID: <54FEAB2B.9090303@redhat.com> On 09/03/15 19:18, Matt Wells wrote: > I'm getting some errors on a DNS Zone that I'm attempting to create. > My systems reside within a sub-domain of example.com. > (xyz.example.com) > Of course example.com is the internet address, but I want to host the > internal example.com so we're able to point to internal intranets and > so on. > > So to the good stuff > Regardless of what flags I give, what NS records I change, the NS > never actually set. I know it's something silly that I'm overlooking > but would really love other eyes. > > I go to create the zone on server2. > [root at server2 html]# ipa dnszone-add example.com > Zone name: example.com. > Active zone: TRUE > Authoritative nameserver: server2.xyz.example.com. > Administrator e-mail address: hostmaster > SOA serial: 1425924224 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant xyz.example.com krb5-self * A; grant > xyz.example.com krb5-self * AAAA; grant xyz.example.com krb5-self * > SSHFP; > Dynamic update: FALSE > Allow query: any; > Allow transfer: none; > [root at server2 html]# rndc reload > server reload successful > > ------------ > Logs on server1 show this > > Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server2.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server1.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: not loaded due to errors. > Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: > update_zone (syncrepl) failed for > 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be > outdated, run `rndc reload`: bad zone > Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server2.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server1.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: not loaded due to errors. > Mar 09 18:03:48 server1.xyz.example.com named-pkcs11[23279]: > update_zone (syncrepl) failed for > 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be > outdated, run `rndc reload`: bad zone > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server2.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server1.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: not loaded due to errors. > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: unable to reload invalid zone; reload triggered by > change in 'idnsname=_kerberos,idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com':bad > zone > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server2.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server1.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: not loaded due to errors. > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: > update_zone (syncrepl) failed for > 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be > outdated, run `rndc reload`: bad zone > Hello, do you have proper NS delegation in example.com. zone? ipa dnsrecord-add example.com. xyz.example.com. --ns-rec=server2.xyz.example.com Martin -- Martin Basti From pspacek at redhat.com Tue Mar 10 08:35:46 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Mar 2015 09:35:46 +0100 Subject: [Freeipa-users] Errors while adding DNS Zone In-Reply-To: References: Message-ID: <54FEACE2.4020201@redhat.com> Hello! First of all, what version of FreeIPA do you use? FreeIPA 4.1.what? On 9.3.2015 19:18, Matt Wells wrote: > I'm getting some errors on a DNS Zone that I'm attempting to create. > My systems reside within a sub-domain of example.com. > (xyz.example.com) > Of course example.com is the internet address, but I want to host the > internal example.com so we're able to point to internal intranets and > so on. > > So to the good stuff > Regardless of what flags I give, what NS records I change, the NS > never actually set. I know it's something silly that I'm overlooking > but would really love other eyes. > > I go to create the zone on server2. > [root at server2 html]# ipa dnszone-add example.com > Zone name: example.com. > Active zone: TRUE > Authoritative nameserver: server2.xyz.example.com. One important note: Field 'Authoritative nameserver' shows only the SOA MNAME value and is not related at all to NS records in the zone. Use $ ipa dnsrecord-show example.com. @ to see NS records in zone apex. > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server2.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: NS 'server1.xyz.example.com' has no address records (A > or AAAA) > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone > example.com/IN: not loaded due to errors. > Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: > update_zone (syncrepl) failed for > 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be > outdated, run `rndc reload`: bad zone At this point we need to know more information: a) You have to add glue records for names listed in example.com NS records. It is not obvious if you did that or not: $ ipa dnsrecord-add example.com server1.xyz --a-rec=192.0.2.1 $ ipa dnsrecord-add example.com server2.xyz --a-rec=192.0.2.2 b) If xyz.example.com is a sub-zone you have to add NS records/delegation for it (even if it is hosted on the same server!): $ ipa dnsrecord-add example.com xyz --ns-rec=server1.xyz.example.com. $ ipa dnsrecord-add example.com xyz --ns-rec=server2.xyz.example.com. Do not forget to change names in NS records if the sub-zone is hosted on different servers. I hope this helps. Have a nice day! -- Petr^2 Spacek From sbose at redhat.com Tue Mar 10 08:47:18 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 10 Mar 2015 09:47:18 +0100 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: <54FE3A59.2080206@redhat.com> References: <20150309170400.GC25455@redhat.com> <54FDED46.9020208@redhat.com> <20150309194005.GY29063@hendrix.arn.redhat.com> <54FE3A59.2080206@redhat.com> Message-ID: <20150310084718.GC7307@p.redhat.com> On Mon, Mar 09, 2015 at 08:27:05PM -0400, Dmitri Pal wrote: > On 03/09/2015 03:40 PM, Jakub Hrozek wrote: > >On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: > >>On 03/09/2015 02:29 PM, Traiano Welcome wrote: > >>>Hi Alexander > >>> > >>> Thanks for the response: > >>> > >>>On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy wrote: > >>>>On Mon, 09 Mar 2015, Traiano Welcome wrote: > >>>>>Hi List > >>>>> > >>>>> > >>>>>I have AD trusts configured and working between an IPA server and a > >>>>>"master" primary domain controller (dc-1) in a forest in one data > >>>>>center. This allows me to connect with SSH to linux servers in the > >>>>>same data-center, authenticating with my AD credentials. > >>>>> > >>>>>I'm trying to test a scenario where I have an IPA server set up in > >>>>>another data center, and trust is established with an AD domain > >>>>>controller (dc-2) in that data-center. > >>>>>This domain controller takes dc-1 as it's authoritative source. > >>>>>Ideally, the IPA server will interact with the domain controller > >>>>>nearest to it (i.e dc-2), however, from tcpdump, I note the following: > >>>>> > >>>>>- IPA server communicates with dc-2 first > >>>>>- dc-2 returns a list of domain controllers in all the datacenters, > >>>>>including dc-1 > >>>>>the IPA server then begins querying ldap and kerberos ports on dc-1, > >>>>>the domain controller furthest from it. > >>>>>- Authentication on clients fail > >>>>> > >>>>>My question is: Is it possible to get IPA to query and interact only > >>>>>with the domain controller it initially established trust with? > >>>>Let's first separate multiple issues. > >>>> > >>>>1. Terminology > >>>> Cross-forest trust is established between domain controllers in forest > >>>>root > >>>> domains. In case of IPA we need that access only once, when trust is > >>>> created. You don't need to establish trust again with dc-2 once you > >>>> have established it with dc-1. > >>>> > >>>> When trust is established, AD DCs will look up IPA masters via SRV > >>>> records in DNS (_ldap._tcp.). We don't provide > >>>> site-specific SRV records as IPA does not handle sites in this area > >>>> yet. > >>>> > >>>Thanks for the clarification. > >>> > >>> > >>>> However, this is not your problem. > >>>> > >>>>2. User and group lookups are done by SSSD against global catalog > >>>> service (_gc._tcp.) and AD DS (_ldap._tcp.), > >>>> along with Kerberos KDC (AD DCs). > >>>> > >>>> These DCs are found via SRV records in DNS and SSSD since 1.9.5 > >>>> uses site-specific SRV records for AD domain controllers lookups in > >>>> case of IPA-AD trust. > >>>> > >>>>You are interested in (2) being site-aware. However, you didn't say what > >>>>is your distribution and software versions so it is quite hard to give > >>>>any recommendation. > >>>My objective is basically distribution of IPA servers across multiple > >>>data centers linked by a WAN: > >>> > >>>- There is a central 'head office' with an AD domain-controller, this > >>>is the primary source of identity for the domain. > >>>- A number of other data-centers each have their own local AD domain > >>>controller linked to the head-office domain controller > >>>- The datacenters are in different timezones. > >>>- An IPA server in each data-center with trust established with the > >>>local domain controller > >>>- Each IPA server is configured with it's own realm, but provides > >>>access to the global AD domain via AD Trusts > >>> > >>>The idea was to prevent IPA authentication related traffic going > >>>across the WAN (latency, different time-zones etc) to a central ad > >>>domain controller at head office. So this setup seemed reasonable. > >>> > >>>I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, > >>>the working setup was based on this howto: > >>> > >>>http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description > >>> > >>>... which works fine if the IPA server has a trust relationship > >>>directly with the primary domain controller at head office (which it > >>>is collocated with). > >>> > >>>I can live without site-awareness per se if I can achieve IPA > >>>centralised authentication across datacenters in different timezones, > >>>with AD as the primary source of identity. An alternative setup that > >>>I've considered testing: > >>> > >>>- IPA server at the head office with trust established to the primary AD DC. > >>>- A replica of the primary in each DC (different timezones), on the same realm > >>> > >>>However, I doubt replicas can work across timezones, and with high WAN > >>> latencies. > >>> > >> > >>As Alexander said the trust on the fores level. > >>There is no pairing between IPA replicas and AD DCs to a specific data > >>center. > >> > >>What you need to concentrate is making sure that SSSD on a client picks AD > >>in the local data center and IPA in the same data center (for the additional > >>lookup operations). > >>I do not know whether one can explicitly set this in sssd.conf. This is > >>something to ask SSSD list. The alternative would be to make DNS return the > >>right server. > >You can set the site and the DNS domain for the direct integration, but not > >for the server mode. The server mode is designed to operate with mostly > >defaults -- the reason not being that much that we don't want to support > >configuration, but the current failover code can't handle two totally > >separate domains in a single back end. > > > >This is a known pain point me and Pavel Brezina were talking about for a > >long time. So far there hasn't been a driver that would justify > >refactoring the failover layer to achive this functionality. > > > >>For AD DC the AD DNS will be returning the server to authenticate against > >>and there should be a way to configure AD DNS this way. > >>I do not think it is possible to force specific DNS entry out of IPA - it > >>does not support sites yet. But may be there is a way to override it on > >>SSSD. > >> > >>In case of other (legacy Linux or other platforms) clients that talk to IPA > >>you can configure them with the explicit fail over list. They do not talk to > >>AD directly. > >>You might also consider configuring SSSD on the IPA server to use AD in the > >>same location as a primary server. > >SSSD on the IPA server /does/ support DNS sites, but only the DNS > >autodiscovery. Unfortunately you can't specify a custom site.. > > > It looks like time to file a ticket(s) to support this kind of functionality > (affinity to AD controllers within the same site). I think we already have a solution in the context of https://fedorahosted.org/sssd/ticket/2486 where a new option 'ad_site' was added. What is missing is to make it possible to use this option with sub-domains. Currently all configuration options are only for the primary domain, the IPA domain in this case. As Jakub said before the AD sub-domain configuration use mostly suitable default values. We have to decide if we want only special sub-domain option accessible or if we want to allow access to all (there was a recent discussion on sssd-devel about another option). Depending on this we have to figure out how to make it available with the current configuration scheme. bye, Sumit > > -- > 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 traiano at gmail.com Tue Mar 10 08:58:07 2015 From: traiano at gmail.com (Traiano Welcome) Date: Tue, 10 Mar 2015 11:58:07 +0300 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: <20150309184922.GF25455@redhat.com> References: <20150309170400.GC25455@redhat.com> <20150309184922.GF25455@redhat.com> Message-ID: On Mon, Mar 9, 2015 at 9:49 PM, Alexander Bokovoy wrote: > On Mon, 09 Mar 2015, Traiano Welcome wrote: >> >> Hi Alexander >> >> Thanks for the response: >> >> On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy >> wrote: >>> >>> On Mon, 09 Mar 2015, Traiano Welcome wrote: >>>> >>>> >>>> Hi List >>>> >>>> >>>> I have AD trusts configured and working between an IPA server and a >>>> "master" primary domain controller (dc-1) in a forest in one data >>>> center. This allows me to connect with SSH to linux servers in the >>>> same data-center, authenticating with my AD credentials. >>>> >>>> I'm trying to test a scenario where I have an IPA server set up in >>>> another data center, and trust is established with an AD domain >>>> controller (dc-2) in that data-center. >>>> This domain controller takes dc-1 as it's authoritative source. >>>> Ideally, the IPA server will interact with the domain controller >>>> nearest to it (i.e dc-2), however, from tcpdump, I note the following: >>>> >>>> - IPA server communicates with dc-2 first >>>> - dc-2 returns a list of domain controllers in all the datacenters, >>>> including dc-1 >>>> the IPA server then begins querying ldap and kerberos ports on dc-1, >>>> the domain controller furthest from it. >>>> - Authentication on clients fail >>>> >>>> My question is: Is it possible to get IPA to query and interact only >>>> with the domain controller it initially established trust with? >>> >>> >>> Let's first separate multiple issues. >>> >>> 1. Terminology >>> Cross-forest trust is established between domain controllers in forest >>> root >>> domains. In case of IPA we need that access only once, when trust is >>> created. You don't need to establish trust again with dc-2 once you >>> have established it with dc-1. >>> >>> When trust is established, AD DCs will look up IPA masters via SRV >>> records in DNS (_ldap._tcp.). We don't provide >>> site-specific SRV records as IPA does not handle sites in this area >>> yet. >>> >> >> >> Thanks for the clarification. >> >> >>> However, this is not your problem. >>> >>> 2. User and group lookups are done by SSSD against global catalog >>> service (_gc._tcp.) and AD DS (_ldap._tcp.), >>> along with Kerberos KDC (AD DCs). >>> >>> These DCs are found via SRV records in DNS and SSSD since 1.9.5 >>> uses site-specific SRV records for AD domain controllers lookups in >>> case of IPA-AD trust. >>> >>> You are interested in (2) being site-aware. However, you didn't say what >>> is your distribution and software versions so it is quite hard to give >>> any recommendation. >> >> >> My objective is basically distribution of IPA servers across multiple >> data centers linked by a WAN: >> >> - There is a central 'head office' with an AD domain-controller, this >> is the primary source of identity for the domain. >> - A number of other data-centers each have their own local AD domain >> controller linked to the head-office domain controller >> - The datacenters are in different timezones. >> - An IPA server in each data-center with trust established with the >> local domain controller >> - Each IPA server is configured with it's own realm, but provides >> access to the global AD domain via AD Trusts >> >> The idea was to prevent IPA authentication related traffic going >> across the WAN (latency, different time-zones etc) to a central ad >> domain controller at head office. So this setup seemed reasonable. > > Do you have sites defined in AD? Yes. It seems AD is configured to be site aware and to respond to IPA with the site-specific ad domain controller. > > If so, can you enable debug_level=10 in /etc/sssd/sssd.conf on IPA master > in the other datacenter and attempt to login as AD user. We'll see in > SSSD logs how it discovers what AD DC to talk to. > > Add following to /etc/sssd/sssd.conf: > [domain/..] > .. > debug_level = 10 > > [nss] > debug_level = 10 > > and restart sssd. Done. Looking at the logs, discovery seems to be working correctly now, and it seems to be using the site-specific dc AD hands to it (see attached log sssd_idmlol.local.log_sanitized.txt ): --- (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_srv_plugin_send] (0x0400): About to find domain controllers (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_get_dc_servers_send] (0x0400): Looking up domain controllers in domain yyy.com . . . (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_discover_srv_done] (0x0400): Got answer. Processing... (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_discover_srv_done] (0x0400): Got 5 servers (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_get_dc_servers_done] (0x0400): Found 5 domain controllers in domain yyy.com (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_srv_plugin_dcs_done] (0x0400): About to locate suitable site . . . (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [be_get_account_info] (0x0100): Got request for [4098][1][name=traiano] (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [be_req_set_domain] (0x0400): Changing request domain from [idmdc2.com] to [yyy.com] (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [request_watch_destructor] (0x0400): Deleting request watch (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_connect_host_resolv_done] (0x0400): Connecting to ldap://loldc001.yyy.com:389 . . (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://loldc001.yyy.com:389/??base] with fd [24]. (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_connect_host_done] (0x0400): Successful connection to ldap://loldc001.yyy.com:389 (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(DnsDomain=yyy.com)(NtVer=\14\00\00\00))][]. . . (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_get_client_site_done] (0x0400): Found site: LOL-DC2 (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_srv_plugin_site_done] (0x0400): About to discover primary and backup servers (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_discover_servers_send] (0x0400): Looking up primary servers (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_discover_srv_next_domain] (0x0400): SRV resolution of service 'ldap'. Will use DNS discovery domain 'LOL-DC2._sites.yyy.com' . . (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_discover_srv_done] (0x0400): Got 5 servers (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_srv_plugin_servers_done] (0x0400): Got 1 primary and 5 backup servers (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_add_server_to_list] (0x0400): Inserted primary server 'loldc004.yyy.com:389' to service 'yyy.com' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_add_server_to_list] (0x0400): Inserted backup server 'site_x_dc001.yyy.com:389' to service 'yyy.com' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_add_server_to_list] (0x0400): Inserted backup server 'site_x_dc002.yyy.com:389' to service 'yyy.com' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_add_server_to_list] (0x0400): Inserted backup server 'site_z_dc002.yyy.com:389' to service 'yyy.com' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_add_server_to_list] (0x0400): Inserted backup server 'loldc002.yyy.com:389' to service 'yyy.com' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [fo_add_server_to_list] (0x0400): Inserted backup server 'loldc001.yyy.com:389' to service 'yyy.com' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'yyy.com' as 'resolved' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [get_server_status] (0x1000): Status of server 'loldc004.yyy.com' is 'name not resolved' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_is_address] (0x4000): [loldc004.yyy.com] does not look like an IP address (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'loldc004.yyy.com' in files (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [set_server_common_status] (0x0100): Marking server 'loldc004.yyy.com' as 'resolving name' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve AAAA record of 'loldc004.yyy.com' in files (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_next] (0x0200): No more address families to retry (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_step] (0x2000): Querying DNS (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_dns_query] (0x0100): Trying to resolve A record of 'loldc004.yyy.com' in DNS (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [schedule_request_timeout] (0x2000): Scheduling a timeout of 6 seconds (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [schedule_timeout_watcher] (0x2000): Scheduling DNS timeout watcher (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [unschedule_timeout_watcher] (0x4000): Unscheduling DNS timeout watcher (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [resolv_gethostbyname_dns_parse] (0x1000): Parsing an A reply (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [request_watch_destructor] (0x0400): Deleting request watch (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [set_server_common_status] (0x0100): Marking server 'loldc004.yyy.com' as 'name resolved' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [be_resolve_server_process] (0x0200): Found address for server loldc004.yyy.com: [172.16.200.122] TTL 3600 (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_resolve_callback] (0x0100): Constructed uri 'ldap://loldc004.yyy.com' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [ad_resolve_callback] (0x0100): Constructed GC uri 'ldap://loldc004.yyy.com' (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sss_ldap_init_send] (0x4000): Using file descriptor [24] for LDAP connection. (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://loldc004.yyy.com:389/??base] with fd [24]. (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] --- However, I'm still not able to authenticate via the ssh->sssd path (I cn get kerberos tickets for ad users via cli though), so I think that incorrect dc discovery is not really the issue here. Instead, it seem the ldap query against the discovered AD domain controller is failing with some kid of policy related error: Here's a snippet what we're seeing in the IPA master sssd logs during an a client connection attempt: --- . . . (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: host/lolospr-idm-mstr.idmdc2.com (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (KDC policy rejects request)] . . --- Further down I also see this message which seems to indicate an issue the IPA server has talking to the ldap port on the AD dc: --- (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'loldc004.yyy.com' as 'not working' (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [fo_set_port_status] (0x0400): Marking port 389 of duplicate server 'loldc004.yyy.com' as 'not working' (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ad_user_data_cmp] (0x1000): Comparing LDAP with LDAP (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f8f2e9f0fb0], connected[1], ops[(nil)], ldap[0x7f8f2e98f3f0], destructor_lock[0], release_memory[0] (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [be_mark_offline] (0x2000): Going offline! (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ipa_get_ad_acct_ad_part_done] (0x0040): AD lookup failed: 11 (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ipa_account_info_error_text] (0x0020): Bug: dp_error is OK on failed request (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #2 (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ipa_get_ad_acct_ad_part_done] (0x0040): AD lookup failed: 11 (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [ipa_account_info_error_text] (0x0020): Bug: dp_error is OK on failed request (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,11,Account info lookup failed (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection --- However, looking at tcpdump I see the communication between IPA server and port 389 on the ad domain controller working fine (verbose tcpump attached): --- 10:25:37.024424 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [S], seq 3511982115, win 14600, options [mss 1460,sackOK,TS val 54616734 ecr 0,nop,wscale 7], length 0 10:25:37.024744 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [S.], seq 785389569, ack 3511982116, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 117103354 ecr 54616734], length 0 10:25:37.024811 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 1, win 115, options [nop,nop,TS val 54616735 ecr 117103354], length 0 10:25:37.025363 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [P.], seq 1:261, ack 1, win 115, options [nop,nop,TS val 54616735 ecr 117103354], length 260 10:25:37.025746 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [.], seq 1:1449, ack 261, win 514, options [nop,nop,TS val 117103355 ecr 54616735], length 1448 10:25:37.025793 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 1449, win 137, options [nop,nop,TS val 54616736 ecr 117103355], length 0 10:25:37.025808 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [P.], seq 1449:2631, ack 261, win 514, options [nop,nop,TS val 117103355 ecr 54616735], length 1182 10:25:37.025826 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 2631, win 160, options [nop,nop,TS val 54616736 ecr 117103355], length 0 10:25:39.087598 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [P.], seq 261:268, ack 2631, win 160, options [nop,nop,TS val 54618797 ecr 117103355], length 7 10:25:39.087673 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [F.], seq 268, ack 2631, win 160, options [nop,nop,TS val 54618798 ecr 117103355], length 0 10:25:39.087912 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [.], ack 269, win 514, options [nop,nop,TS val 117103561 ecr 54618797], length 0 10:25:39.087944 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [R.], seq 2631, ack 269, win 0, length 0 --- ... Given this, I'm not sure how to interpret the "port not working" message. > > >> I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, >> the working setup was based on this howto: >> >> http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description >> >> ... which works fine if the IPA server has a trust relationship >> directly with the primary domain controller at head office (which it >> is collocated with). >> >> I can live without site-awareness per se if I can achieve IPA >> centralised authentication across datacenters in different timezones, >> with AD as the primary source of identity. An alternative setup that >> I've considered testing: >> >> - IPA server at the head office with trust established to the primary AD >> DC. >> - A replica of the primary in each DC (different timezones), on the same >> realm > > Currently each master has to be prepared with ipa-adtrust-install if any > of IPA clients connected to this master need to be accessible to AD > users. > > -- > / Alexander Bokovoy -------------- next part -------------- [root at lolospr-idm-mstr sssd]# tcpdump -i ens192 port 389 and host loldc004.yyy.com tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on ens192, link-type EN10MB (Ethernet), capture size 65535 bytes 10:25:37.024424 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [S], seq 3511982115, win 14600, options [mss 1460,sackOK,TS val 54616734 ecr 0,nop,wscale 7], length 0 10:25:37.024744 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [S.], seq 785389569, ack 3511982116, win 8192, options [mss 1460,nop,wscale 8,sackOK,TS val 117103354 ecr 54616734], length 0 10:25:37.024811 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 1, win 115, options [nop,nop,TS val 54616735 ecr 117103354], length 0 10:25:37.025363 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [P.], seq 1:261, ack 1, win 115, options [nop,nop,TS val 54616735 ecr 117103354], length 260 10:25:37.025746 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [.], seq 1:1449, ack 261, win 514, options [nop,nop,TS val 117103355 ecr 54616735], length 1448 10:25:37.025793 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 1449, win 137, options [nop,nop,TS val 54616736 ecr 117103355], length 0 10:25:37.025808 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [P.], seq 1449:2631, ack 261, win 514, options [nop,nop,TS val 117103355 ecr 54616735], length 1182 10:25:37.025826 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [.], ack 2631, win 160, options [nop,nop,TS val 54616736 ecr 117103355], length 0 10:25:39.087598 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [P.], seq 261:268, ack 2631, win 160, options [nop,nop,TS val 54618797 ecr 117103355], length 7 10:25:39.087673 IP lolospr-idm-mstr.idmdc2.com.37537 > loldc004.yyy.com.ldap: Flags [F.], seq 268, ack 2631, win 160, options [nop,nop,TS val 54618798 ecr 117103355], length 0 10:25:39.087912 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [.], ack 269, win 514, options [nop,nop,TS val 117103561 ecr 54618797], length 0 10:25:39.087944 IP loldc004.yyy.com.ldap > lolospr-idm-mstr.idmdc2.com.37537: Flags [R.], seq 2631, ack 269, win 0, length 0 -------------- next part -------------- A non-text attachment was scrubbed... Name: verbose_dump_389.log Type: application/octet-stream Size: 18809 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_idmlol.local.log_sanitized Type: application/octet-stream Size: 51712 bytes Desc: not available URL: From abokovoy at redhat.com Tue Mar 10 09:08:17 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Mar 2015 11:08:17 +0200 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: References: <20150309170400.GC25455@redhat.com> <20150309184922.GF25455@redhat.com> Message-ID: <20150310090817.GJ25455@redhat.com> On Tue, 10 Mar 2015, Traiano Welcome wrote: >However, I'm still not able to authenticate via the ssh->sssd path (I >cn get kerberos tickets for ad users via cli though), so I think that >incorrect dc discovery is not really the issue here. Instead, it seem >the ldap query against the discovered AD domain controller is failing >with some kid of policy related error: > >Here's a snippet what we're seeing in the IPA master sssd logs during >an a client connection attempt: > >--- >. >. >. >(Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >(0x0100): Executing sasl bind mech: gssapi, user: >host/lolospr-idm-mstr.idmdc2.com >(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >(0x0020): ldap_sasl_bind failed (-2)[Local error] >(Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >(0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI >Error: Unspecified GSS failure. Minor code may provide more >information (KDC policy rejects request)] When AD says "KDC policy rejects request" it means that trust is not working well -- AD DC was unable to complete trust validation when it was established. See another emails around the trust last week or so, they have details on how to debug this. -- / Alexander Bokovoy From jhrozek at redhat.com Tue Mar 10 09:25:28 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 10 Mar 2015 10:25:28 +0100 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: <20150310084718.GC7307@p.redhat.com> References: <20150309170400.GC25455@redhat.com> <54FDED46.9020208@redhat.com> <20150309194005.GY29063@hendrix.arn.redhat.com> <54FE3A59.2080206@redhat.com> <20150310084718.GC7307@p.redhat.com> Message-ID: <20150310092528.GC22044@hendrix.arn.redhat.com> On Tue, Mar 10, 2015 at 09:47:18AM +0100, Sumit Bose wrote: > On Mon, Mar 09, 2015 at 08:27:05PM -0400, Dmitri Pal wrote: > > On 03/09/2015 03:40 PM, Jakub Hrozek wrote: > > >On Mon, Mar 09, 2015 at 02:58:14PM -0400, Dmitri Pal wrote: > > >>On 03/09/2015 02:29 PM, Traiano Welcome wrote: > > >>>Hi Alexander > > >>> > > >>> Thanks for the response: > > >>> > > >>>On Mon, Mar 9, 2015 at 8:04 PM, Alexander Bokovoy wrote: > > >>>>On Mon, 09 Mar 2015, Traiano Welcome wrote: > > >>>>>Hi List > > >>>>> > > >>>>> > > >>>>>I have AD trusts configured and working between an IPA server and a > > >>>>>"master" primary domain controller (dc-1) in a forest in one data > > >>>>>center. This allows me to connect with SSH to linux servers in the > > >>>>>same data-center, authenticating with my AD credentials. > > >>>>> > > >>>>>I'm trying to test a scenario where I have an IPA server set up in > > >>>>>another data center, and trust is established with an AD domain > > >>>>>controller (dc-2) in that data-center. > > >>>>>This domain controller takes dc-1 as it's authoritative source. > > >>>>>Ideally, the IPA server will interact with the domain controller > > >>>>>nearest to it (i.e dc-2), however, from tcpdump, I note the following: > > >>>>> > > >>>>>- IPA server communicates with dc-2 first > > >>>>>- dc-2 returns a list of domain controllers in all the datacenters, > > >>>>>including dc-1 > > >>>>>the IPA server then begins querying ldap and kerberos ports on dc-1, > > >>>>>the domain controller furthest from it. > > >>>>>- Authentication on clients fail > > >>>>> > > >>>>>My question is: Is it possible to get IPA to query and interact only > > >>>>>with the domain controller it initially established trust with? > > >>>>Let's first separate multiple issues. > > >>>> > > >>>>1. Terminology > > >>>> Cross-forest trust is established between domain controllers in forest > > >>>>root > > >>>> domains. In case of IPA we need that access only once, when trust is > > >>>> created. You don't need to establish trust again with dc-2 once you > > >>>> have established it with dc-1. > > >>>> > > >>>> When trust is established, AD DCs will look up IPA masters via SRV > > >>>> records in DNS (_ldap._tcp.). We don't provide > > >>>> site-specific SRV records as IPA does not handle sites in this area > > >>>> yet. > > >>>> > > >>>Thanks for the clarification. > > >>> > > >>> > > >>>> However, this is not your problem. > > >>>> > > >>>>2. User and group lookups are done by SSSD against global catalog > > >>>> service (_gc._tcp.) and AD DS (_ldap._tcp.), > > >>>> along with Kerberos KDC (AD DCs). > > >>>> > > >>>> These DCs are found via SRV records in DNS and SSSD since 1.9.5 > > >>>> uses site-specific SRV records for AD domain controllers lookups in > > >>>> case of IPA-AD trust. > > >>>> > > >>>>You are interested in (2) being site-aware. However, you didn't say what > > >>>>is your distribution and software versions so it is quite hard to give > > >>>>any recommendation. > > >>>My objective is basically distribution of IPA servers across multiple > > >>>data centers linked by a WAN: > > >>> > > >>>- There is a central 'head office' with an AD domain-controller, this > > >>>is the primary source of identity for the domain. > > >>>- A number of other data-centers each have their own local AD domain > > >>>controller linked to the head-office domain controller > > >>>- The datacenters are in different timezones. > > >>>- An IPA server in each data-center with trust established with the > > >>>local domain controller > > >>>- Each IPA server is configured with it's own realm, but provides > > >>>access to the global AD domain via AD Trusts > > >>> > > >>>The idea was to prevent IPA authentication related traffic going > > >>>across the WAN (latency, different time-zones etc) to a central ad > > >>>domain controller at head office. So this setup seemed reasonable. > > >>> > > >>>I'm using IPA v3.3 distributed with the CentOS 7 DVD. For reference, > > >>>the working setup was based on this howto: > > >>> > > >>>http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Description > > >>> > > >>>... which works fine if the IPA server has a trust relationship > > >>>directly with the primary domain controller at head office (which it > > >>>is collocated with). > > >>> > > >>>I can live without site-awareness per se if I can achieve IPA > > >>>centralised authentication across datacenters in different timezones, > > >>>with AD as the primary source of identity. An alternative setup that > > >>>I've considered testing: > > >>> > > >>>- IPA server at the head office with trust established to the primary AD DC. > > >>>- A replica of the primary in each DC (different timezones), on the same realm > > >>> > > >>>However, I doubt replicas can work across timezones, and with high WAN > > >>> latencies. > > >>> > > >> > > >>As Alexander said the trust on the fores level. > > >>There is no pairing between IPA replicas and AD DCs to a specific data > > >>center. > > >> > > >>What you need to concentrate is making sure that SSSD on a client picks AD > > >>in the local data center and IPA in the same data center (for the additional > > >>lookup operations). > > >>I do not know whether one can explicitly set this in sssd.conf. This is > > >>something to ask SSSD list. The alternative would be to make DNS return the > > >>right server. > > >You can set the site and the DNS domain for the direct integration, but not > > >for the server mode. The server mode is designed to operate with mostly > > >defaults -- the reason not being that much that we don't want to support > > >configuration, but the current failover code can't handle two totally > > >separate domains in a single back end. > > > > > >This is a known pain point me and Pavel Brezina were talking about for a > > >long time. So far there hasn't been a driver that would justify > > >refactoring the failover layer to achive this functionality. > > > > > >>For AD DC the AD DNS will be returning the server to authenticate against > > >>and there should be a way to configure AD DNS this way. > > >>I do not think it is possible to force specific DNS entry out of IPA - it > > >>does not support sites yet. But may be there is a way to override it on > > >>SSSD. > > >> > > >>In case of other (legacy Linux or other platforms) clients that talk to IPA > > >>you can configure them with the explicit fail over list. They do not talk to > > >>AD directly. > > >>You might also consider configuring SSSD on the IPA server to use AD in the > > >>same location as a primary server. > > >SSSD on the IPA server /does/ support DNS sites, but only the DNS > > >autodiscovery. Unfortunately you can't specify a custom site.. > > > > > It looks like time to file a ticket(s) to support this kind of functionality > > (affinity to AD controllers within the same site). > > I think we already have a solution in the context of > https://fedorahosted.org/sssd/ticket/2486 where a new option 'ad_site' > was added. What is missing is to make it possible to use this option > with sub-domains. Currently all configuration options are only for the > primary domain, the IPA domain in this case. As Jakub said before the AD > sub-domain configuration use mostly suitable default values. We have to > decide if we want only special sub-domain option accessible or if we want > to allow access to all (there was a recent discussion on sssd-devel > about another option). Depending on this we have to figure out how to > make it available with the current configuration scheme. > > bye, > Sumit OK, I filed https://fedorahosted.org/sssd/ticket/2599 to track this. From alpha at krisindigitalage.com Tue Mar 10 10:15:06 2015 From: alpha at krisindigitalage.com (K SHK) Date: Tue, 10 Mar 2015 10:15:06 +0000 Subject: [Freeipa-users] freeIPA SSL authentication Message-ID: hi, My hortonworks hadoop cluster is keberized with FreeIPA and works splendid :) I want to clarify if SSL authentication with out a login/password will work against FreeIPA... ie. client connects to apache webserver over SSL, and sets in username via http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername and the webserver will get the valid ticket from freeIPA... any idea what type of certificate and apache modules will be needed to accomplish this? regards, -K -------------- next part -------------- An HTML attachment was scrubbed... URL: From guertin at middlebury.edu Tue Mar 10 11:11:24 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 10 Mar 2015 11:11:24 +0000 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: <54FB3154.5060203@redhat.com> References: <1425672251562.91790@middlebury.edu> <54FB3154.5060203@redhat.com> Message-ID: <7642c2e9894c4173b1b2d460cf190a82@greyhound.middlebury.edu> >>I have already: >>- created an IPA group called ad_users. >>- created an IPA group called ad_users_external. > Did you create this group with --external? Doh! Nope, somehow I missed that. I've done that and that part is working now. But the other part of the question remains, i.e. I'm still seeing all of our AD users (that have UNIX attributes enabled) instead of just the ones in the AD group that I've added. David Guertin From guertin at middlebury.edu Tue Mar 10 11:14:21 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 10 Mar 2015 11:14:21 +0000 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: <20150308204011.GP3477@hendrix.arn.redhat.com> References: <1425672251562.91790@middlebury.edu> <20150308204011.GP3477@hendrix.arn.redhat.com> Message-ID: > > Seems the initial/default setup for IPA server is to put in an 'allow_all' > rule. Thus you can actively manage HBAC but out of the box, it is essentially > turned off by that rule. > > Yes. The default was the opposite very long time ago, you had to explicitly > enable access to the box. But it was causing too many user issues. OK, I have reinstalled the IPA server with the --no_hbac_allow flag (i.e. : ipa-server-install --no_hbac_allow), but the behavior remains the same. I can still see all AD users instead of just those in the particular group I've added. Is there something else that needs be done to override the allow_all setting? David Guertin From pspacek at redhat.com Tue Mar 10 11:27:33 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 10 Mar 2015 12:27:33 +0100 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: References: <1425672251562.91790@middlebury.edu> <20150308204011.GP3477@hendrix.arn.redhat.com> Message-ID: <54FED525.9080002@redhat.com> On 10.3.2015 12:14, Guertin, David S. wrote: >>> Seems the initial/default setup for IPA server is to put in an 'allow_all' >> rule. Thus you can actively manage HBAC but out of the box, it is essentially >> turned off by that rule. >> >> Yes. The default was the opposite very long time ago, you had to explicitly >> enable access to the box. But it was causing too many user issues. > > OK, I have reinstalled the IPA server with the --no_hbac_allow flag (i.e. : ipa-server-install --no_hbac_allow), but the behavior remains the same. I can still see all AD users instead of just those in the particular group I've added. > > Is there something else that needs be done to override the allow_all setting? You should be able to 'see' them via getent passwd but they should not be allowed to login when HBAC_ALLOW_ALL is disabled. -- Petr^2 Spacek From abokovoy at redhat.com Tue Mar 10 11:28:25 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Mar 2015 13:28:25 +0200 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: References: <1425672251562.91790@middlebury.edu> <20150308204011.GP3477@hendrix.arn.redhat.com> Message-ID: <20150310112825.GK25455@redhat.com> On Tue, 10 Mar 2015, Guertin, David S. wrote: >> > Seems the initial/default setup for IPA server is to put in an 'allow_all' >> rule. Thus you can actively manage HBAC but out of the box, it is essentially >> turned off by that rule. >> >> Yes. The default was the opposite very long time ago, you had to explicitly >> enable access to the box. But it was causing too many user issues. > >OK, I have reinstalled the IPA server with the --no_hbac_allow flag >(i.e. : ipa-server-install --no_hbac_allow), but the behavior remains >the same. I can still see all AD users instead of just those in the >particular group I've added. > >Is there something else that needs be done to override the allow_all setting? Can you be more specific? If you have allow_all HBAC rule enabled, it is just that -- any existing user will be authorized to access any service on any host given they authenticate successfully. If you disabled allow_all rule, then some other rule may allow such access but without more details about your configuration it is impossible to say what are you doing. On top of this you add confusion by saying "I can still see all AD users" -- what do you mean by this? Any substantiated shell output would definitely help here to understand your issues. -- / Alexander Bokovoy From jhrozek at redhat.com Tue Mar 10 11:30:52 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 10 Mar 2015 12:30:52 +0100 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: References: <1425672251562.91790@middlebury.edu> <20150308204011.GP3477@hendrix.arn.redhat.com> Message-ID: <20150310113052.GH22044@hendrix.arn.redhat.com> On Tue, Mar 10, 2015 at 11:14:21AM +0000, Guertin, David S. wrote: > > > Seems the initial/default setup for IPA server is to put in an 'allow_all' > > rule. Thus you can actively manage HBAC but out of the box, it is essentially > > turned off by that rule. > > > > Yes. The default was the opposite very long time ago, you had to explicitly > > enable access to the box. But it was causing too many user issues. > > OK, I have reinstalled the IPA server with the --no_hbac_allow flag (i.e. : ipa-server-install --no_hbac_allow), but the behavior remains the same. I can still see all AD users instead of just those in the particular group I've added. > > Is there something else that needs be done to override the allow_all setting? Can you also login with them? The HBAC rules don't prevent retrieving identity information, only access to the system. From guertin at middlebury.edu Tue Mar 10 11:42:23 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 10 Mar 2015 11:42:23 +0000 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: <54FED525.9080002@redhat.com> References: <1425672251562.91790@middlebury.edu> <20150308204011.GP3477@hendrix.arn.redhat.com> <54FED525.9080002@redhat.com> Message-ID: <6e1738b9b5ad4336b35f6f6f07b39505@greyhound.middlebury.edu> > You should be able to 'see' them via getent passwd but they should not be > allowed to login when HBAC_ALLOW_ALL is disabled. Ah, OK, thanks, that's what is happening. I can see them with getent passwd and id, and I can su to them, but I can't log in as them. On the other hand, I also can't log in as a user that SHOULD have permission (as a member of the appropriate AD group), but I'm still troubleshooting that one. David Guertin From abokovoy at redhat.com Tue Mar 10 11:47:33 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Mar 2015 13:47:33 +0200 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: <6e1738b9b5ad4336b35f6f6f07b39505@greyhound.middlebury.edu> References: <1425672251562.91790@middlebury.edu> <20150308204011.GP3477@hendrix.arn.redhat.com> <54FED525.9080002@redhat.com> <6e1738b9b5ad4336b35f6f6f07b39505@greyhound.middlebury.edu> Message-ID: <20150310114733.GL25455@redhat.com> On Tue, 10 Mar 2015, Guertin, David S. wrote: >> You should be able to 'see' them via getent passwd but they should not be >> allowed to login when HBAC_ALLOW_ALL is disabled. > >Ah, OK, thanks, that's what is happening. I can see them with getent >passwd and id, and I can su to them, but I can't log in as them. Seeing identity is as designed. 'su' from root is ignoring any of HBAC rules because your PAM stack for 'su' includes a rule that allows exactly that (root can impersonate anyone). >On the other hand, I also can't log in as a user that SHOULD have >permission (as a member of the appropriate AD group), but I'm still >troubleshooting that one. For troubleshooting this you need to enable debug_level=10 in sssd.conf in domain and pam sections. Restart sssd and try to login. -- / Alexander Bokovoy From ranger at opennms.org Tue Mar 10 13:14:44 2015 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 10 Mar 2015 09:14:44 -0400 Subject: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1) Message-ID: <54FEEE44.8000207@opennms.org> I'm attempting to migrate FreeIPA from an RHEL6 server to a CentOS7 server. When I run ipa-replica-install to set up the CentOS7 server, I get the following error: > ipa : CRITICAL The master CA directory server does not have > necessary schema. Please copy the following script to all CA masters > and run it on them: /usr/share/ipa/copy-schema-to-ca.py > If you are certain that this is a false positive, use --skip-schema-check. > IPA schema missing on master CA directory server Is it safe to run this script on the RHEL6 server? Is it a false positive I should ignore? What is the best way to transition? Thanks, Ben -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From abokovoy at redhat.com Tue Mar 10 13:31:50 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Mar 2015 15:31:50 +0200 Subject: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1) In-Reply-To: <54FEEE44.8000207@opennms.org> References: <54FEEE44.8000207@opennms.org> Message-ID: <20150310133150.GM25455@redhat.com> On Tue, 10 Mar 2015, Benjamin Reed wrote: >I'm attempting to migrate FreeIPA from an RHEL6 server to a CentOS7 server. > >When I run ipa-replica-install to set up the CentOS7 server, I get the >following error: > >> ipa : CRITICAL The master CA directory server does not have >> necessary schema. Please copy the following script to all CA masters >> and run it on them: /usr/share/ipa/copy-schema-to-ca.py >> If you are certain that this is a false positive, use --skip-schema-check. >> IPA schema missing on master CA directory server > >Is it safe to run this script on the RHEL6 server? Is it a false >positive I should ignore? What is the best way to transition? Are you following these instructions? https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html -- / Alexander Bokovoy From matt.wells at mosaic451.com Tue Mar 10 13:38:40 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Tue, 10 Mar 2015 06:38:40 -0700 Subject: [Freeipa-users] Errors while adding DNS Zone In-Reply-To: <54FEACE2.4020201@redhat.com> References: <54FEACE2.4020201@redhat.com> Message-ID: @Martin Basti that was it. Thanks so much for the assistance. @Petr Spacek also thanks for the reply also. I failed to provide some rather important information that you mentioned. Thanks all for your the help. On Tue, Mar 10, 2015 at 1:35 AM, Petr Spacek wrote: > Hello! > > First of all, what version of FreeIPA do you use? FreeIPA 4.1.what? > > On 9.3.2015 19:18, Matt Wells wrote: >> I'm getting some errors on a DNS Zone that I'm attempting to create. >> My systems reside within a sub-domain of example.com. >> (xyz.example.com) >> Of course example.com is the internet address, but I want to host the >> internal example.com so we're able to point to internal intranets and >> so on. >> >> So to the good stuff >> Regardless of what flags I give, what NS records I change, the NS >> never actually set. I know it's something silly that I'm overlooking >> but would really love other eyes. >> >> I go to create the zone on server2. >> [root at server2 html]# ipa dnszone-add example.com >> Zone name: example.com. >> Active zone: TRUE >> Authoritative nameserver: server2.xyz.example.com. > > One important note: Field 'Authoritative nameserver' shows only the SOA MNAME > value and is not related at all to NS records in the zone. > > Use > $ ipa dnsrecord-show example.com. @ > to see NS records in zone apex. > >> Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone >> example.com/IN: NS 'server2.xyz.example.com' has no address records (A >> or AAAA) >> Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone >> example.com/IN: NS 'server1.xyz.example.com' has no address records (A >> or AAAA) >> Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: zone >> example.com/IN: not loaded due to errors. >> Mar 09 18:03:51 server1.xyz.example.com named-pkcs11[23279]: >> update_zone (syncrepl) failed for >> 'idnsname=example.com.,cn=dns,dc=xyz,dc=example,dc=com'. Zones can be >> outdated, run `rndc reload`: bad zone > > At this point we need to know more information: > > a) You have to add glue records for names listed in example.com NS records. It > is not obvious if you did that or not: > $ ipa dnsrecord-add example.com server1.xyz --a-rec=192.0.2.1 > $ ipa dnsrecord-add example.com server2.xyz --a-rec=192.0.2.2 > > b) If xyz.example.com is a sub-zone you have to add NS records/delegation for > it (even if it is hosted on the same server!): > $ ipa dnsrecord-add example.com xyz --ns-rec=server1.xyz.example.com. > $ ipa dnsrecord-add example.com xyz --ns-rec=server2.xyz.example.com. > > Do not forget to change names in NS records if the sub-zone is hosted on > different servers. > > I hope this helps. Have a nice day! > > -- > Petr^2 Spacek > > -- > 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 ranger at opennms.org Tue Mar 10 13:46:02 2015 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 10 Mar 2015 09:46:02 -0400 Subject: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1) In-Reply-To: <20150310133150.GM25455@redhat.com> References: <54FEEE44.8000207@opennms.org> <20150310133150.GM25455@redhat.com> Message-ID: <54FEF59A.7040109@opennms.org> On 3/10/15 9:31 AM, Alexander Bokovoy wrote: > Are you following these instructions? > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html Aha! No. There are so many false positives in google I had no idea that document existed. Pretty much everything I've found that links to "how to migrate" takes me to this: http://www.freeipa.org/page/Howto/Migration#Migrating_to_different_platform_or_OS ...which in turn pointed to this: http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Setting_up_IPA_Replicas.html I didn't see anything about RHEL6->RHEL7 or FreeIPA 3.0->3.3 http://www.freeipa.org/page/Documentation unless I missed it. The 3.3 section on there is pretty much just a collection of things about new features. (And a presentation deck that points to that first link above...) Anyways, thank you for the link. That makes it much clearer. I do have one problem now. I currently have the following systems: connect: RHEL6, FreeIPA master auth.internal: CentOS6, FreeIPA replica auth: CentOS7, migration target Following the instructions you linked, I ran the copy-schema-to-ca.py script on connect, and it completed successfully. I then tried to run it on auth.internal (the CentOS6 replica) and it fails with this error: > python copy-schema-to-ca.py > Traceback (most recent call last): > File "copy-schema-to-ca.py", line 85, in > main() > File "copy-schema-to-ca.py", line 79, in main > add_ca_schema() > File "copy-schema-to-ca.py", line 42, in add_ca_schema > pki_pent = pwd.getpwnam(PKI_USER) > KeyError: 'getpwnam(): name not found: pkiuser' ...am I supposed to run this script the replica as well? Or is something broken on my replica? Thanks, Ben -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From abokovoy at redhat.com Tue Mar 10 14:06:26 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Mar 2015 16:06:26 +0200 Subject: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1) In-Reply-To: <54FEF59A.7040109@opennms.org> References: <54FEEE44.8000207@opennms.org> <20150310133150.GM25455@redhat.com> <54FEF59A.7040109@opennms.org> Message-ID: <20150310140626.GN25455@redhat.com> On Tue, 10 Mar 2015, Benjamin Reed wrote: >On 3/10/15 9:31 AM, Alexander Bokovoy wrote: >> Are you following these instructions? >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html > > >Aha! No. There are so many false positives in google I had no idea >that document existed. Pretty much everything I've found that links to >"how to migrate" takes me to this: > >http://www.freeipa.org/page/Howto/Migration#Migrating_to_different_platform_or_OS > >...which in turn pointed to this: > >http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Setting_up_IPA_Replicas.html > >I didn't see anything about RHEL6->RHEL7 or FreeIPA 3.0->3.3 >http://www.freeipa.org/page/Documentation unless I missed it. The 3.3 >section on there is pretty much just a collection of things about new >features. (And a presentation deck that points to that first link above...) We have http://www.freeipa.org/page/Documentation#User_Guides and going through user guide would be our recommended action. There is a whole chapter 6 in RHEL7 docs for upgrades and migration. >Anyways, thank you for the link. That makes it much clearer. > >I do have one problem now. I currently have the following systems: > >connect: RHEL6, FreeIPA master >auth.internal: CentOS6, FreeIPA replica >auth: CentOS7, migration target > >Following the instructions you linked, I ran the copy-schema-to-ca.py >script on connect, and it completed successfully. I then tried to run >it on auth.internal (the CentOS6 replica) and it fails with this error: > >> python copy-schema-to-ca.py >> Traceback (most recent call last): >> File "copy-schema-to-ca.py", line 85, in >> main() >> File "copy-schema-to-ca.py", line 79, in main >> add_ca_schema() >> File "copy-schema-to-ca.py", line 42, in add_ca_schema >> pki_pent = pwd.getpwnam(PKI_USER) >> KeyError: 'getpwnam(): name not found: pkiuser' > >...am I supposed to run this script the replica as well? Or is >something broken on my replica? Looks like you don't have CA installed on auth.internal so you don't need to update CA schema there. -- / Alexander Bokovoy From rcritten at redhat.com Tue Mar 10 14:13:21 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Mar 2015 10:13:21 -0400 Subject: [Freeipa-users] how can i configure solaris10 as freeIPA 4.1.2 client In-Reply-To: <54FCED00.3060801@redhat.com> References: <20150308204242.GQ3477@hendrix.arn.redhat.com> <54FCB63C.2090405@redhat.com> <20150308212546.GS3477@hendrix.arn.redhat.com> <54FCED00.3060801@redhat.com> Message-ID: <54FEFC01.90906@redhat.com> Dmitri Pal wrote: > On 03/08/2015 05:25 PM, Jakub Hrozek wrote: >> On Sun, Mar 08, 2015 at 04:51:08PM -0400, Rob Crittenden wrote: >>> The IPA team has moved away from trying to provide direct support >>> /documentation for non-Linux platforms since we don't have the in-house >>> expertise. The documents you'll find on the wiki provide a minimalist >>> configuration that worked for us at one time. >> Thanks; I wasn't aware of that. >> >> Should we document that the page might not be accurate and searching >> freeipa-users might be a better choice on that wiki page, then? >> > We should probably add links to archived threads abd BZ to the wiki page. > This would be the minimal effort. > I'll take care of this, it just make take me a few days to get around to it. rob From rcritten at redhat.com Tue Mar 10 14:22:09 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Mar 2015 10:22:09 -0400 Subject: [Freeipa-users] freeIPA SSL authentication In-Reply-To: References: Message-ID: <54FEFE11.6060500@redhat.com> K SHK wrote: > hi, > > My hortonworks hadoop cluster is keberized with FreeIPA and works > splendid :) > > I want to clarify if SSL authentication with out a login/password will > work against FreeIPA... > > ie. client connects to apache webserver over SSL, and sets in username via > > http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername > > and the webserver will get the valid ticket from freeIPA... > > any idea what type of certificate and apache modules will be needed to > accomplish this? IPA doesn't support user SSL certificates at the moment, so that's the first hurdle. It is being worked on for 4.2. You'd need to include the PKINIT EKU in the client cert, something that should be configurable when the work is done. The second problem is that the IPA PKINIT configuration is rather incomplete at the moment. I'm not sure if it is sufficient in it's current state, even with properly formatted certificates. And even further, I"m not familiar enough with PKINIT to know whether a web-based SSL authentication is enough to get a ticket. rob From traiano at gmail.com Tue Mar 10 14:26:26 2015 From: traiano at gmail.com (Traiano Welcome) Date: Tue, 10 Mar 2015 17:26:26 +0300 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: <20150310090817.GJ25455@redhat.com> References: <20150309170400.GC25455@redhat.com> <20150309184922.GF25455@redhat.com> <20150310090817.GJ25455@redhat.com> Message-ID: Hi Alexander On Tue, Mar 10, 2015 at 12:08 PM, Alexander Bokovoy wrote: > On Tue, 10 Mar 2015, Traiano Welcome wrote: >> >> However, I'm still not able to authenticate via the ssh->sssd path (I >> cn get kerberos tickets for ad users via cli though), so I think that >> incorrect dc discovery is not really the issue here. Instead, it seem >> the ldap query against the discovered AD domain controller is failing >> with some kid of policy related error: >> >> Here's a snippet what we're seeing in the IPA master sssd logs during >> an a client connection attempt: >> >> --- >> . >> . >> . >> (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >> (0x0100): Executing sasl bind mech: gssapi, user: >> host/lolospr-idm-mstr.idmdc2.com >> (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >> (0x0020): ldap_sasl_bind failed (-2)[Local error] >> (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI >> Error: Unspecified GSS failure. Minor code may provide more >> information (KDC policy rejects request)] > > When AD says "KDC policy rejects request" it means that trust is not > working well -- AD DC was unable to complete trust validation when it > was established. See another emails around the trust last week or so, > they have details on how to debug this. This is probably the case, however, I'd like to drill down further to see exactly what part of the trust is broken, because it seems the trust was established without error (using "ipa trust-add"), and I seem to be able to get trust information with " ipa trust-show": Re-adding the trusts: --- [root at loldc2-idm-mstr ~]# ipa trust-add --type=ad lol.com --admin admin --password Active directory domain administrator's password: ------------------------------------------ Re-established trust to domain "lol.com" ------------------------------------------ Realm name: lol.com Domain NetBIOS name: LOL Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 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 [root at loldc2-idm-mstr ~]# --- Using trust show: --- [root at loldc2-idm-mstr sssd]# ipa trust-show Realm name: LOL.COM Realm name: lol.com Domain NetBIOS name: LOL Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 Trust direction: Two-way trust Trust type: Active Directory domain --- I can see that not all is well with the trusts because when I test with wbinfo, I get this: --- [root at loldc2-idm-mstr ~]# wbinfo --verbose -n 'LOL\Domain Admins' failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND Could not lookup name LOL\Domain Admins --- Looking at the samba logs with debug turned up, I get something potentially enlightening in the message "NT_STATUS_ACCESS_DENIED" ... However, the question is to pinpoint if this is due to an AD-side policy issue, or due to some weirdness on the IPA end of things: --- . . . [2015/03/10 17:02:46.934072, 3, pid=6917, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_lookupname.c:69(winbindd_lookupname_send) lookupname LOL\Domain Admins [2015/03/10 17:02:46.934190, 1, pid=6917, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName in: struct wbint_LookupName domain : * domain : 'LOL' name : * name : 'DOMAIN ADMINS' flags : 0x00000000 (0) [2015/03/10 17:02:46.934532, 50, pid=6917, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7facefb10430 [2015/03/10 17:02:46.934696, 50, pid=6917, effective(0, 0), real(0, 0)] ../lib/util/tevent_debug.c:63(samba_tevent_debug) samba_tevent: Run immediate event "tevent_req_trigger": 0x7facefb10430 [2015/03/10 17:02:46.934812, 1, pid=6917, effective(0, 0), real(0, 0)] ../librpc/ndr/ndr.c:333(ndr_print_function_debug) wbint_LookupName: struct wbint_LookupName out: struct wbint_LookupName type : * type : SID_NAME_USE_NONE (0) sid : * sid : S-0-0 result : NT_STATUS_ACCESS_DENIED [2015/03/10 17:02:46.935174, 5, pid=6917, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd_lookupname.c:104(winbindd_lookupname_recv) Could not convert sid S-0-0: NT_STATUS_ACCESS_DENIED [2015/03/10 17:02:46.935281, 10, pid=6917, effective(0, 0), real(0, 0), class=winbind] ../source3/winbindd/winbindd.c:755(wb_request_done) wb_request_done[8382:LOOKUPNAME]: NT_STATUS_ACCESS_DENIED --- (I can also kinit directly from the cli on the master using an AD user and get a ticker from the Active Directory kdc, which is confusing because it implies trust relationship working !): --- [root at loldc2-idm-mstr samba]# kinit traiano at LOL.COM Password for traiano at LOL.COM: [root at loldc2-idm-mstr samba]# [root at loldc2-idm-mstr samba]# klist Ticket cache: KEYRING:persistent:0:krb_ccache_Hrq3EtZ Default principal: traiano at LOL.COM Valid starting Expires Service principal 03/10/2015 17:21:49 03/11/2015 03:21:49 krbtgt/LOL.COM at LOL.COM renew until 03/11/2015 17:21:45 [root at loldc2-idm-mstr samba]# --- So the question is: Are there further diagnostics I can do to drill down further into how/where trust is broken, and what the NT_STATUS_ACCESS_DENIED from the dc is being triggered in response to? From ranger at opennms.org Tue Mar 10 14:29:23 2015 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 10 Mar 2015 10:29:23 -0400 Subject: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1) In-Reply-To: <20150310140626.GN25455@redhat.com> References: <54FEEE44.8000207@opennms.org> <20150310133150.GM25455@redhat.com> <54FEF59A.7040109@opennms.org> <20150310140626.GN25455@redhat.com> Message-ID: <54FEFFC3.4090200@opennms.org> On 3/10/15 10:06 AM, Alexander Bokovoy wrote: > We have http://www.freeipa.org/page/Documentation#User_Guides and going > through user guide would be our recommended action. There is a whole > chapter 6 in RHEL7 docs for upgrades and migration. Ah, I see it now. I had no idea from the name that " Linux Domain Identity, Authentication and Policy Guide for RHEL 7" referred to the general user/admin guide. As a newb to FreeIPA and domain management in general, it looked like word soup. Sorry for the noise. :P > Looks like you don't have CA installed on auth.internal so you don't > need to update CA schema there. Great. So I started the install on the CentOS7 machine, and it almost completed, but failed out with this error: > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes > 30 seconds > [1/19]: creating certificate server user > [2/19]: configuring certificate server instance > ipa : CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmp2_03I3' returned non-zero exit > status 1 In the ipareplica-install.log file, I find this: > Storing deployment configuration into > /etc/sysconfig/pki/tomcat/pki-tomcat/ca/deployment.cfg. > Installation failed. > > > 2015-03-10T14:12:04Z 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 > > 2015-03-10T14:12:04Z CRITICAL failed to configure ca instance Command > '/usr/sbin/pkispawn -s CA -f /tmp/tmp2_03I3' returned non-zero exit > status 1 > 2015-03-10T14:12:04Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 638, in run_script I ran `ipa-server-install --uninstall` to undo everything, as it suggested. Then I generated a new replica file on the RHEL6 machine with `ipa-replica-prepare` and tried the install again. This time, it successfully finishes, but the last thing it says is: > Done configuring directory server (dirsrv). > A CA is already configured on this system. ...which makes me think it just didn't undo everything when I did `ipa-server-install --uninstall` and the CA isn't actually set up properly. Is there a good way to confirm everything is actually working as expected? Thanks, Ben -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From dpal at redhat.com Tue Mar 10 14:43:13 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Mar 2015 10:43:13 -0400 Subject: [Freeipa-users] freeIPA SSL authentication In-Reply-To: <54FEFE11.6060500@redhat.com> References: <54FEFE11.6060500@redhat.com> Message-ID: <54FF0301.1020409@redhat.com> On 03/10/2015 10:22 AM, Rob Crittenden wrote: > K SHK wrote: >> hi, >> >> My hortonworks hadoop cluster is keberized with FreeIPA and works >> splendid :) >> >> I want to clarify if SSL authentication with out a login/password will >> work against FreeIPA... >> >> ie. client connects to apache webserver over SSL, and sets in username via >> >> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername >> >> and the webserver will get the valid ticket from freeIPA... >> >> any idea what type of certificate and apache modules will be needed to >> accomplish this? > IPA doesn't support user SSL certificates at the moment, so that's the > first hurdle. It is being worked on for 4.2. You'd need to include the > PKINIT EKU in the client cert, something that should be configurable > when the work is done. > > The second problem is that the IPA PKINIT configuration is rather > incomplete at the moment. I'm not sure if it is sufficient in it's > current state, even with properly formatted certificates. > > And even further, I"m not familiar enough with PKINIT to know whether a > web-based SSL authentication is enough to get a ticket. > > rob > I think it is but the biggest problem is remapping the identities from the cert to users in identity system - IPA in this case. I will file a ticket. https://fedorahosted.org/freeipa/ticket/4942 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From abokovoy at redhat.com Tue Mar 10 14:50:38 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 10 Mar 2015 16:50:38 +0200 Subject: [Freeipa-users] Filter/Block/Limit Interaction with Multiple Domain Controllers In-Reply-To: References: <20150309170400.GC25455@redhat.com> <20150309184922.GF25455@redhat.com> <20150310090817.GJ25455@redhat.com> Message-ID: <20150310145038.GR25455@redhat.com> On Tue, 10 Mar 2015, Traiano Welcome wrote: >Hi Alexander > > >On Tue, Mar 10, 2015 at 12:08 PM, Alexander Bokovoy wrote: >> On Tue, 10 Mar 2015, Traiano Welcome wrote: >>> >>> However, I'm still not able to authenticate via the ssh->sssd path (I >>> cn get kerberos tickets for ad users via cli though), so I think that >>> incorrect dc discovery is not really the issue here. Instead, it seem >>> the ldap query against the discovered AD domain controller is failing >>> with some kid of policy related error: >>> >>> Here's a snippet what we're seeing in the IPA master sssd logs during >>> an a client connection attempt: >>> >>> --- >>> . >>> . >>> . >>> (Tue Mar 10 09:48:05 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >>> (0x0100): Executing sasl bind mech: gssapi, user: >>> host/lolospr-idm-mstr.idmdc2.com >>> (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >>> (0x0020): ldap_sasl_bind failed (-2)[Local error] >>> (Tue Mar 10 09:48:06 2015) [sssd[be[idmdc2.com]]] [sasl_bind_send] >>> (0x0080): Extended failure message: [SASL(-1): generic failure: GSSAPI >>> Error: Unspecified GSS failure. Minor code may provide more >>> information (KDC policy rejects request)] >> >> When AD says "KDC policy rejects request" it means that trust is not >> working well -- AD DC was unable to complete trust validation when it >> was established. See another emails around the trust last week or so, >> they have details on how to debug this. > >This is probably the case, however, I'd like to drill down further to >see exactly what part of the trust is broken, because it seems the >trust was established without error (using "ipa trust-add"), and I >seem to be able to get trust information with " ipa trust-show": In FreeIPA 3.3 we don't check the error code of validation process. We do in FreeIPA 4.1 so you need to use debug info in /var/log/httpd/error_log to find out -- like I wrote in other threads. > >Re-adding the trusts: > >--- >[root at loldc2-idm-mstr ~]# ipa trust-add --type=ad lol.com --admin >admin --password >Active directory domain administrator's password: >------------------------------------------ >Re-established trust to domain "lol.com" >------------------------------------------ > Realm name: lol.com > Domain NetBIOS name: LOL > Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 > 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 >[root at loldc2-idm-mstr ~]# >--- > > >Using trust show: > >--- >[root at loldc2-idm-mstr sssd]# ipa trust-show >Realm name: LOL.COM > Realm name: lol.com > Domain NetBIOS name: LOL > Domain Security Identifier: S-1-5-21-4090660947-345563186-3527492641 > Trust direction: Two-way trust > Trust type: Active Directory domain >--- > >I can see that not all is well with the trusts because when I test >with wbinfo, I get this: > >--- >[root at loldc2-idm-mstr ~]# wbinfo --verbose -n 'LOL\Domain Admins' >failed to call wbcLookupName: WBC_ERR_DOMAIN_NOT_FOUND >Could not lookup name LOL\Domain Admins >--- > >Looking at the samba logs with debug turned up, I get something >potentially enlightening in the message "NT_STATUS_ACCESS_DENIED" ... >However, the question is to pinpoint if this is due to an AD-side >policy issue, or due to some weirdness on the IPA end of things: > > >--- >. >. >. > >[2015/03/10 17:02:46.934072, 3, pid=6917, effective(0, 0), real(0, 0), >class=winbind] >../source3/winbindd/winbindd_lookupname.c:69(winbindd_lookupname_send) > lookupname LOL\Domain Admins >[2015/03/10 17:02:46.934190, 1, pid=6917, effective(0, 0), real(0, 0)] >../librpc/ndr/ndr.c:333(ndr_print_function_debug) > wbint_LookupName: struct wbint_LookupName > in: struct wbint_LookupName > domain : * > domain : 'LOL' > name : * > name : 'DOMAIN ADMINS' > flags : 0x00000000 (0) >[2015/03/10 17:02:46.934532, 50, pid=6917, effective(0, 0), real(0, 0)] >../lib/util/tevent_debug.c:63(samba_tevent_debug) > samba_tevent: Schedule immediate event "tevent_req_trigger": 0x7facefb10430 >[2015/03/10 17:02:46.934696, 50, pid=6917, effective(0, 0), real(0, 0)] >../lib/util/tevent_debug.c:63(samba_tevent_debug) > samba_tevent: Run immediate event "tevent_req_trigger": 0x7facefb10430 >[2015/03/10 17:02:46.934812, 1, pid=6917, effective(0, 0), real(0, 0)] >../librpc/ndr/ndr.c:333(ndr_print_function_debug) > wbint_LookupName: struct wbint_LookupName > out: struct wbint_LookupName > type : * > type : SID_NAME_USE_NONE (0) > sid : * > sid : S-0-0 > result : NT_STATUS_ACCESS_DENIED >[2015/03/10 17:02:46.935174, 5, pid=6917, effective(0, 0), real(0, 0), >class=winbind] >../source3/winbindd/winbindd_lookupname.c:104(winbindd_lookupname_recv) > Could not convert sid S-0-0: NT_STATUS_ACCESS_DENIED >[2015/03/10 17:02:46.935281, 10, pid=6917, effective(0, 0), real(0, 0), >class=winbind] ../source3/winbindd/winbindd.c:755(wb_request_done) > wb_request_done[8382:LOOKUPNAME]: NT_STATUS_ACCESS_DENIED > >--- > > >(I can also kinit directly from the cli on the master using an AD user >and get a ticker from the Active Directory kdc, which is confusing >because it implies trust relationship working !): > >--- > >[root at loldc2-idm-mstr samba]# kinit traiano at LOL.COM >Password for traiano at LOL.COM: >[root at loldc2-idm-mstr samba]# >[root at loldc2-idm-mstr samba]# klist >Ticket cache: KEYRING:persistent:0:krb_ccache_Hrq3EtZ >Default principal: traiano at LOL.COM > >Valid starting Expires Service principal >03/10/2015 17:21:49 03/11/2015 03:21:49 krbtgt/LOL.COM at LOL.COM > renew until 03/11/2015 17:21:45 >[root at loldc2-idm-mstr samba]# > >--- > >So the question is: Are there further diagnostics I can do to drill >down further into how/where trust is broken, and what the >NT_STATUS_ACCESS_DENIED from the dc is being triggered in response to? Follow the procedure in http://www.freeipa.org/page/Howto/IPAv3_AD_trust_setup#Debugging_trust and see logs in error_log. -- / Alexander Bokovoy From danofsatx at gmail.com Tue Mar 10 16:06:38 2015 From: danofsatx at gmail.com (Dan Mossor) Date: Tue, 10 Mar 2015 11:06:38 -0500 Subject: [Freeipa-users] Web UI Authentication errors - revisited In-Reply-To: <54FA05B8.8050402@redhat.com> References: <54F8D5D8.4010509@redhat.com> <54F8DED8.8040402@redhat.com> <54F8F86F.7000203@redhat.com> <54F9010F.7040507@redhat.com> <54F95730.40408@redhat.com> <54F9C602.3080608@redhat.com> <54F9CB33.3040206@redhat.com> <54FA05B8.8050402@redhat.com> Message-ID: On Fri, Mar 6, 2015 at 1:53 PM, Martin Kosek wrote: > On 03/06/2015 05:59 PM, Dan Mossor wrote: > >> >> IT WORKS! WOOT! >> >> In the steps of researching a small issue on another hypervisor, I >> discovered >> that my underlying network, while operational, was not properly >> configured. The >> IPA server and my workstation were supposed to be talking in VLAN 100 and >> 110, >> respectively. The network is temporarily configured to route every packet >> it >> receives to the proper VLAN, no matter where it originates. >> >> My workstation is indeed on VLAN 110, and is tagging the packets >> appropriately. >> The server, however, due to a bridge misconfiguration on the host, was on >> VLAN >> 1 and not sending tagged packets at all. But as the router is configured >> to >> route all appropriate packets it appeared to be operating normally. >> >> I blew away the network configuration on the host and rebuilt it again, >> this >> time ensuring that VLAN 1 was not available on that switch port, and that >> the >> packets leaving the host were tagged with VLAN 100. I brought the IPA >> server >> back up and was able to log in. >> >> So, chalk this one up to misrouted packets. I didn't even think to look >> there, >> the 401 error gave no clue that networking may be the issue. >> >> Regards, >> Dan Mossor >> > > Ugh, that one was nasty, I am glad you figured it out. Now, when you know > what was the problem, would you maybe have some general Troubleshooting > advice to > > http://www.freeipa.org/page/Troubleshooting#Cannot_authenticate_to_Web_UI > > that would help people like you uncover the root cause easier? > > Thanks, > Martin > Martin, I would love to. Let me think on an effective method to target networking issues, and I'll write something up for the wiki. Regards, Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Tue Mar 10 17:19:20 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 10 Mar 2015 13:19:20 -0400 Subject: [Freeipa-users] freeIPA SSL authentication In-Reply-To: <54FF0301.1020409@redhat.com> References: <54FEFE11.6060500@redhat.com> <54FF0301.1020409@redhat.com> Message-ID: <54FF2798.20602@redhat.com> Dmitri Pal wrote: > On 03/10/2015 10:22 AM, Rob Crittenden wrote: >> K SHK wrote: >>> hi, >>> >>> My hortonworks hadoop cluster is keberized with FreeIPA and works >>> splendid :) >>> >>> I want to clarify if SSL authentication with out a login/password will >>> work against FreeIPA... >>> >>> ie. client connects to apache webserver over SSL, and sets in >>> username via >>> >>> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername >>> >>> and the webserver will get the valid ticket from freeIPA... >>> >>> any idea what type of certificate and apache modules will be needed to >>> accomplish this? >> IPA doesn't support user SSL certificates at the moment, so that's the >> first hurdle. It is being worked on for 4.2. You'd need to include the >> PKINIT EKU in the client cert, something that should be configurable >> when the work is done. >> >> The second problem is that the IPA PKINIT configuration is rather >> incomplete at the moment. I'm not sure if it is sufficient in it's >> current state, even with properly formatted certificates. >> >> And even further, I"m not familiar enough with PKINIT to know whether a >> web-based SSL authentication is enough to get a ticket. >> >> rob >> > I think it is but the biggest problem is remapping the identities from > the cert to users in identity system - IPA in this case. > I will file a ticket. > https://fedorahosted.org/freeipa/ticket/4942 > IIRC with PKINIT the principal is encoded in the certificate so no mapping is required. rob From sipazzo at yahoo.com Tue Mar 10 17:44:42 2015 From: sipazzo at yahoo.com (sipazzo) Date: Tue, 10 Mar 2015 17:44:42 +0000 (UTC) Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <1877934055.712562.1426006167512.JavaMail.yahoo@mail.yahoo.com> References: <1877934055.712562.1426006167512.JavaMail.yahoo@mail.yahoo.com> Message-ID: <907884175.1931824.1426009482210.JavaMail.yahoo@mail.yahoo.com> I was told the GoDaddy certs were just imported using certutil -a but in looking at the certs the original certs were actually replaced. This is only in /etc/dirsrv/slapd-REALM-COM: Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust Attributes?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SSL,S/MIME,JAR/XPI GD_CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,CNWF_GD ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u The certs in /etc/dirsrv/slapd-PKI-CA are still the originals: [root at ipa2-corp ~]# certutil -L -d /etc/dirsrv/slapd-PKI-IPA/ Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust Attributes?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SSL,S/MIME,JAR/XPI IPADOMAIN.COM IPA CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,Server-Cert? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u ?I am not even sure how this even works or if it can be fixed? Should/Can we go back to using the original dogtag certs? From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Wednesday, March 04, 2015 2:57 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Need to replace cert for ipa servers ?On 03/04/2015 04:32 PM, sipazzo wrote: Good afternoon, we have a freeipa 3.0.42 installation running on redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was originally configured with the built in dogtag certificate CA and then one of my co-workers added our GoDaddy certificate to the certificate bundle. My understanding is this cert is used for communication between the ipa servers as well as the clients are also configured to trust the GoDaddy certificate. We recently had to get a new GoDaddy cert so our old one is revoked. I need to figure out how to either replace the existing revoked cert with the new one or add the new one to the bundle and then remove the revoked certificate so as not to break anything. ?Any help is appreciated. I am not strong with certificates so the more detail you can give the better.Thank you. You say it was running with the self signed IPA CA and than GoDaddy cert was added to the bundle. How was it added? IPA does not use certs for communication between the instances. It uses Kerberos. I am not sure the DoDaddy cert you added is even used in some way by IPA. It seems that your GoDaddy cert is an orthogonal trust so if you replaced the main key pair then you just need to distribute your new GoDaddy cert to the clients as you did on the first place. -- Thank you,Dmitri Pal ?Sr. Engineering Manager IdM portfolioRed Hat, Inc. #yiv5565645412 #yiv5565645412 -- filtered {panose-1:0 0 0 0 0 0 0 0 0 0;}#yiv5565645412 filtered {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;}#yiv5565645412 filtered {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;}#yiv5565645412 filtered {font-family:Consolas;panose-1:0 0 0 0 0 0 0 0 0 0;}#yiv5565645412 filtered {panose-1:2 5 6 4 5 5 5 2 2 4;}#yiv5565645412 p.yiv5565645412MsoNormal, #yiv5565645412 li.yiv5565645412MsoNormal, #yiv5565645412 div.yiv5565645412MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;color:black;}#yiv5565645412 a:link, #yiv5565645412 span.yiv5565645412MsoHyperlink {color:blue;text-decoration:underline;}#yiv5565645412 a:visited, #yiv5565645412 span.yiv5565645412MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv5565645412 pre {margin:0in;margin-bottom:.0001pt;font-size:10.0pt;color:black;}#yiv5565645412 span.yiv5565645412HTMLPreformattedChar {color:black;}#yiv5565645412 span.yiv5565645412EmailStyle19 {color:#1F497D;}#yiv5565645412 .yiv5565645412MsoChpDefault {font-size:10.0pt;}#yiv5565645412 filtered {margin:1.0in 1.0in 1.0in 1.0in;}#yiv5565645412 div.yiv5565645412WordSection1 {}#yiv5565645412 -------------- next part -------------- An HTML attachment was scrubbed... URL: From robert.erzen at g-r-v.com Tue Mar 10 18:39:45 2015 From: robert.erzen at g-r-v.com (Robert Erzen) Date: Tue, 10 Mar 2015 19:39:45 +0100 Subject: [Freeipa-users] freeIPA function basics from user's perspective Message-ID: Hi all, I'm new to freeIPA and I'm researching how freeIPA bassically work. How does this looks like from the perspective of the end user. Can you please confirm or correct my knowledge about freeIPA functioning. Let assume we have a mixed environment of five freeIPA servers which are gatheredint one domain. Then we have additional ten Linux servers which are aded to realm as Linux hosts. Then we have also five Windows servers, which are connected into Active directory. Trust relationship between freeIPA and AD is established. When Windows user log into AD, he gets authenticated by AD and gain access to assets in AD as well in freeIPA. Is this correct? How does things go with a Linux user? Will I be able to join his Ubuntu user name and password to freeIPA? Will he authenticate with freeIPA every time, he will log into his Ubuntu? Thanx -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Mar 10 19:10:24 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Mar 2015 15:10:24 -0400 Subject: [Freeipa-users] freeIPA SSL authentication In-Reply-To: <54FF2798.20602@redhat.com> References: <54FEFE11.6060500@redhat.com> <54FF0301.1020409@redhat.com> <54FF2798.20602@redhat.com> Message-ID: <54FF41A0.6040900@redhat.com> On 03/10/2015 01:19 PM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 03/10/2015 10:22 AM, Rob Crittenden wrote: >>> K SHK wrote: >>>> hi, >>>> >>>> My hortonworks hadoop cluster is keberized with FreeIPA and works >>>> splendid :) >>>> >>>> I want to clarify if SSL authentication with out a login/password will >>>> work against FreeIPA... >>>> >>>> ie. client connects to apache webserver over SSL, and sets in >>>> username via >>>> >>>> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername >>>> >>>> and the webserver will get the valid ticket from freeIPA... >>>> >>>> any idea what type of certificate and apache modules will be needed to >>>> accomplish this? >>> IPA doesn't support user SSL certificates at the moment, so that's the >>> first hurdle. It is being worked on for 4.2. You'd need to include the >>> PKINIT EKU in the client cert, something that should be configurable >>> when the work is done. >>> >>> The second problem is that the IPA PKINIT configuration is rather >>> incomplete at the moment. I'm not sure if it is sufficient in it's >>> current state, even with properly formatted certificates. >>> >>> And even further, I"m not familiar enough with PKINIT to know whether a >>> web-based SSL authentication is enough to get a ticket. >>> >>> rob >>> >> I think it is but the biggest problem is remapping the identities from >> the cert to users in identity system - IPA in this case. >> I will file a ticket. >> https://fedorahosted.org/freeipa/ticket/4942 >> > IIRC with PKINIT the principal is encoded in the certificate so no > mapping is required. > > rob There are several use cases here: - do PKINIT on the client and then use ST to connect to IPA UI - this is already planned - use certificate auth via mod_nss directly to IPA. The challenge would be to deal with the case when there is no principal (or other good identifier) in the cert and you have to remap. Unfortunately we can't guarantee that principal is in the cert. Some known entities that we need to work with do not have the principal in the cert. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From bslusky at smartling.com Tue Mar 10 19:25:44 2015 From: bslusky at smartling.com (Ben Slusky) Date: Tue, 10 Mar 2015 15:25:44 -0400 Subject: [Freeipa-users] Trying to migrate, can't set hashed passwords In-Reply-To: <20150309184549.GE25455@redhat.com> References: <20150309184549.GE25455@redhat.com> Message-ID: On Mon, Mar 9, 2015 at 2:45 PM, Alexander Bokovoy wrote: > On Mon, 09 Mar 2015, Ben Slusky wrote: > >> Greetings FreeIPA users, >> >> I'm setting up FreeIPA service in our production environment to replace >> several different authentication methods for various systems. I'm trying >> to >> migrate the first wave of users now My plan was to copy their passwords >> from an old LDAP directory (one of the aforementioned several >> authentication methods) and then send them to the migration page to finish >> the job. >> > Even in migration mode, you can only set pre-hashed passwords when > creating the records, not when modifying them. > > >> bslusky at ipa1.aws:~$ head techteam-passwords.ldif >> dn: uid=user1001,cn=users,cn=accounts,dc=smartling,dc=int >> changeType: modify >> replace: userPassword >> userPassword:: e1NTSE[...] >> - >> >> dn: uid=user1002,cn=users,cn=accounts,dc=smartling,dc=int >> changeType: modify >> replace: userPassword >> userPassword:: e1NIQX[...] >> >> Unfortunately it isn't working: >> >> bslusky at ipa1.aws:~$ ldapmodify -x -D cn=directory\ manager -W -f >> techteam-passwords.ldif >> Enter LDAP Password: >> modifying entry "uid=user1001,cn=users,cn=accounts,dc=smartling,dc=int" >> ldap_modify: Operations error (1) >> >> I found some possible causes of this error, and fixed them: >> >> bslusky at ipa1.aws:~$ ipa config-show |grep migration >> Enable migration mode: TRUE >> >> bslusky at ipa1.aws:~$ ldapsearch -x -D cn=directory\ manager -W -b >> cn=config >> |grep allow-hashed >> Enter LDAP Password: >> nsslapd-allow-hashed-passwords: on >> >> Still no soap. Any suggestions? >> > Works as designed. We only allow unhashed passwords in migration mode > when entry is added, not modified. > > -- > / Alexander Bokovoy > Alexander: Thanks for clarifying that. To anyone dealing with this or a similar problem who might find this in a web search: ipa user-add user0001 --first=User --last=0001 --setattr=userPassword='{SHA}...' works like a charm (if migration mode is enabled). -- *Ben Slusky*Smartling, Inc. Senior Operations Engineer bslusky at smartling.com | smartling.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Mar 10 21:33:40 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 10 Mar 2015 17:33:40 -0400 Subject: [Freeipa-users] freeIPA function basics from user's perspective In-Reply-To: References: Message-ID: <54FF6334.6070804@redhat.com> On 03/10/2015 02:39 PM, Robert Erzen wrote: > Hi all, > > I'm new to freeIPA and I'm researching how freeIPA bassically work. > How does this looks like from the perspective of the end user. > Can you please confirm or correct my knowledge about freeIPA functioning. > > Let assume we have a mixed environment of five freeIPA servers which > are gatheredint one domain. > Then we have additional ten Linux servers which are aded to realm as > Linux hosts. > Then we have also five Windows servers, which are connected into > Active directory. > Trust relationship between freeIPA and AD is established. > When Windows user log into AD, he gets authenticated by AD and gain > access to assets in AD as well in freeIPA. Is this correct? > How does things go with a Linux user? Will I be able to join his > Ubuntu user name and password to freeIPA? Linux users are managed by IPA. SSSD will know based on the fully qualified name of the user (or short name which will be assumed to be an IPA user name in default configuration) that the user needs to be authenticated against IPA. > Will he authenticate with freeIPA every time, he will log into his Ubuntu? Yes. And policies defined in IPA will apply. All this assumes you have a relatively recent SSSD version on Ubuntu you plan to use. There is a solution for legacy clients too. See more details on the wiki on the documentation page (search for the word "legacy" on the page). > > Thanx > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From alpha at krisindigitalage.com Wed Mar 11 11:34:20 2015 From: alpha at krisindigitalage.com (K SHK) Date: Wed, 11 Mar 2015 11:34:20 +0000 Subject: [Freeipa-users] freeIPA SSL authentication In-Reply-To: <54FF41A0.6040900@redhat.com> References: <54FEFE11.6060500@redhat.com> <54FF0301.1020409@redhat.com> <54FF2798.20602@redhat.com> <54FF41A0.6040900@redhat.com> Message-ID: thanks Dmitri, I am now testing two-way SSL auth to a Apache webserver using auth_kerb_module which authenticates to IPA, idea is that it will reverse proxy to another server which is under IPA domain. I will try out mod_nss and later PKINIT. thanks for the reply. -KSHK On Tue, Mar 10, 2015 at 7:10 PM, Dmitri Pal wrote: > On 03/10/2015 01:19 PM, Rob Crittenden wrote: > >> Dmitri Pal wrote: >> >>> On 03/10/2015 10:22 AM, Rob Crittenden wrote: >>> >>>> K SHK wrote: >>>> >>>>> hi, >>>>> >>>>> My hortonworks hadoop cluster is keberized with FreeIPA and works >>>>> splendid :) >>>>> >>>>> I want to clarify if SSL authentication with out a login/password will >>>>> work against FreeIPA... >>>>> >>>>> ie. client connects to apache webserver over SSL, and sets in >>>>> username via >>>>> >>>>> http://httpd.apache.org/docs/2.2/mod/mod_ssl.html#sslusername >>>>> >>>>> and the webserver will get the valid ticket from freeIPA... >>>>> >>>>> any idea what type of certificate and apache modules will be needed to >>>>> accomplish this? >>>>> >>>> IPA doesn't support user SSL certificates at the moment, so that's the >>>> first hurdle. It is being worked on for 4.2. You'd need to include the >>>> PKINIT EKU in the client cert, something that should be configurable >>>> when the work is done. >>>> >>>> The second problem is that the IPA PKINIT configuration is rather >>>> incomplete at the moment. I'm not sure if it is sufficient in it's >>>> current state, even with properly formatted certificates. >>>> >>>> And even further, I"m not familiar enough with PKINIT to know whether a >>>> web-based SSL authentication is enough to get a ticket. >>>> >>>> rob >>>> >>>> I think it is but the biggest problem is remapping the identities from >>> the cert to users in identity system - IPA in this case. >>> I will file a ticket. >>> https://fedorahosted.org/freeipa/ticket/4942 >>> >>> IIRC with PKINIT the principal is encoded in the certificate so no >> mapping is required. >> >> rob >> > There are several use cases here: > - do PKINIT on the client and then use ST to connect to IPA UI - this is > already planned > - use certificate auth via mod_nss directly to IPA. > > The challenge would be to deal with the case when there is no principal > (or other good identifier) in the cert and you have to remap. > Unfortunately we can't guarantee that principal is in the cert. Some known > entities that we need to work with do not have the principal in the cert. > > -- > 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 robert.erzen at g-r-v.com Wed Mar 11 11:57:47 2015 From: robert.erzen at g-r-v.com (Robert Erzen) Date: Wed, 11 Mar 2015 12:57:47 +0100 Subject: [Freeipa-users] freeIPA function basics from user's perspective In-Reply-To: <54FF6334.6070804@redhat.com> References: <54FF6334.6070804@redhat.com> Message-ID: Thanks for your input. Since I have most users on Windows clients, I will have to consider implementing AD and join Linux servers in. Any thought on that? br -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Wed Mar 11 13:50:32 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 11 Mar 2015 16:50:32 +0300 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login Message-ID: HI i can able to reach upto level that IPA user can able to login on solaris box, but how can i create home directories automatically on solaris while IPA user login. even i change the shell in IPA web interface that is getting affected. i saw some option in IPA 3.3 web interface like automount and that is not in IPA 4.1.2 please anyone tell me where it is and how can i achieve this regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Wed Mar 11 15:13:50 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Wed, 11 Mar 2015 11:13:50 -0400 Subject: [Freeipa-users] ipa-server setup with external CA fails Message-ID: We?re trying to setup IPA with it acting as an intermediate CA against our test Active Directory environment. The first part goes well: # ipa-server-install -a admin-pass ?hostname=server.domain.com -n unix.test.osuwmc -p password -P password -r UNIX.TEST.OSUWMC --external-ca ?external-ca-type=ms?cs We send our CSR off to our AD admin and he signs it on gives us the cert. We go to import the cert with: # ipa-server-install --external-cert-file=/root/ipa.crt It blows up when trying to create the RA cert. 2015-03-10T21:17:55Z DEBUG Process finished, return code=0 2015-03-10T21:17:55Z DEBUG stdout= Certificate request generated by Netscape certutil Phone: (not specified) Common Name: IPA RA Email: (not specified) Organization: UNIX.TEST.OSUWMC State: (not specified) Country: (not specified) -----BEGIN NEW CERTIFICATE REQUEST----- MIICcTCCAVkCAQAwLDEZMBcGA1UEChMQVU5JWC5URVNULk9TVVdNQzEPMA0GA1UE AxMGSVBBIFJBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0DavkHxe PoY8q6UWCAHKWOCCv8PvU7J5scsmdLfjSyN8rIgq8pGoICAqawm9lZntD8G/7sJQ H2bNDe08DooGbdTLHB2j3JViUUlQn2YlWw7IXm6mgwxStGLSS/G+CnyVPdGWV48X GHb7GLLNYD8nhpzNzqVGsVMTyV/dqD7y8srbpPjmAqH+VjKLDSmr3pgV2IvOUEpW wePYJW7h4FBQtwQpPgo30oXMqXa/ob8RJ4NQ74Uv6irq9G2IXNpKhAbHB1YZ+DGm FJFlURdxey0FUbDn1WqMeVLa6SMURZI1zncMxB6bwgax/2VdYVeYHiVU9GgGmw0F VgUjgpg0RMCaSQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBAI1YCN5oS2o5+fky jTNCeWFq+oEyHcuPtGzBAA5HMNEsoFvIY0sut+lf7Upw/ZHvV/F09DPwT+Xrm8yp D0e6F6HawEV+NvKYk2kmpK9xxyOi0raBz1WuvlmqwGhiTOxpk+nIW5wiNhiOJmzd xLojqGnkP5tBuYtHXUFqps7KDknsk5VxoAGe3/ZvsDvqlYXF93V+/nXv90X2yEKH +wLUCDtS5WRWtnxTs1bWsMjBsTyDcv8XBdWqDO/4DVLs9HjHijfsUtUqg8bR5dU1 kVM+yLXVogJPBMN79SJQ1un8IWNMHCallsX3urNbXxYuSlqsh6UCdRLXFW44jJIK xAmXvOg= -----END NEW CERTIFICATE REQUEST----- 2015-03-10T21:17:55Z DEBUG stderr= Generating key. This may take a few moments... 2015-03-10T21:17:55Z 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/cainstance.py", line 1149, in __request_ra_certificate self.requestId = item_node[0].childNodes[0].data IndexError: list index out of range 2015-03-10T21:17:55Z DEBUG [error] IndexError: list index out of range 2015-03-10T21:17:55Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 646, in run_script return_value = main_function() File "/sbin/ipa-server-install", line 1170, in main ca_signing_algorithm=options.ca_signing_algorithm) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 520, in configure_instance self.start_creation(runtime=210) 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/cainstance.py", line 1149, in __request_ra_certificate self.requestId = item_node[0].childNodes[0].data 2015-03-10T21:17:55Z DEBUG The ipa-server-install command failed, exception: IndexError: list index out of range I?ve looked at the debug log. I believe this is the part that?s most helpful. [10/Mar/2015:17:17:24][localhost-startStop-1]: SelfTestSubsystem::runSelfTestsAtStartup(): ENTERING . . . [10/Mar/2015:17:17:24][localhost-startStop-1]: SelfTestSubsystem::runSelfTestsAtStartup(): running "CAPresence" [10/Mar/2015:17:17:24][localhost-startStop-1]: SelfTestSubsystem::runSelfTestsAtStartup(): running "SystemCertsVerification" [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=signing [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed:caSigningCert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Fai lure][CertNickName=caSigningCert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=ocsp_signing [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed:ocspSigningCert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Fai lure][CertNickName=ocspSigningCert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=sslserver [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed:Server-Cert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Fai lure][CertNickName=Server-Cert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=subsystem [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() failed:subsystemCert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Fai lure][CertNickName=subsystemCert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCerts() cert tag=audit_signing [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname(): calling isCertValid() [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: verifySystemCertByNickname() passed:auditSigningCert cert-pki-ca [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Suc cess][CertNickName=auditSigningCert cert-pki-ca] CIMC certificate verification [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: create() message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failur e] self tests execution (see selftests.log for details) The selftests.log contradicts itself and I?m not really sure where to look next. Any ideas? Joshua From dpal at redhat.com Wed Mar 11 16:32:53 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 12:32:53 -0400 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: References: Message-ID: <55006E35.2090808@redhat.com> On 03/11/2015 09:50 AM, Ben .T.George wrote: > HI > > i can able to reach upto level that IPA user can able to login on > solaris box, > > but how can i create home directories automatically on solaris while > IPA user login. > > even i change the shell in IPA web interface that is getting affected. > i saw some option in IPA 3.3 web interface like automount and that is > not in IPA 4.1.2 All the options are still there. The menus got re-arranged a bit. Hopefully someone with a Solaris knowledge will help you with the rest. > > please anyone tell me where it is and how can i achieve this > > regards, > Ben > > -- 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 Mar 11 16:36:22 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 12:36:22 -0400 Subject: [Freeipa-users] freeIPA function basics from user's perspective In-Reply-To: References: <54FF6334.6070804@redhat.com> Message-ID: <55006F06.7030405@redhat.com> On 03/11/2015 07:57 AM, Robert Erzen wrote: > Thanks for your input. > Since I have most users on Windows clients, I will have to consider > implementing AD and join Linux servers in. > Any thought on that? > > br I think the best would be to read my blogs. Jan 20, 2015 An Introduction to Interoperability Challenges in the Modern Enterprise Jan 22, 2015 Closing the Integration Gap Jan 28, 2015 Aspects of Integration Feb 04, 2015 Overview of Direct Integration Options Feb 19, 2015 Overview of Indirect Active Directory Integration Using Identity Management (IdM) Feb 26, 2015 Active Directory and Identity Management (IdM) Trusts ? Exactly Where Are My Users? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sipazzo at yahoo.com Wed Mar 11 16:37:27 2015 From: sipazzo at yahoo.com (sipazzo) Date: Wed, 11 Mar 2015 16:37:27 +0000 (UTC) Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <903DF15B7B9D3B4D9137A06F63687859172C8A724C@FHDP1LUMXC7V33.us.one.verizon.com> References: <903DF15B7B9D3B4D9137A06F63687859172C8A724C@FHDP1LUMXC7V33.us.one.verizon.com> Message-ID: <1420341203.2669446.1426091847417.JavaMail.yahoo@mail.yahoo.com> #yiv2229194538 #yiv2229194538 -- _filtered #yiv2229194538 {font-family:Helvetica;panose-1:2 11 6 4 2 2 2 2 2 4;} _filtered #yiv2229194538 {panose-1:2 4 5 3 5 4 6 3 2 4;} _filtered #yiv2229194538 {font-family:Calibri;panose-1:2 15 5 2 2 2 4 3 2 4;} _filtered #yiv2229194538 {font-family:Tahoma;panose-1:2 11 6 4 3 5 4 4 2 4;} _filtered #yiv2229194538 {font-family:Consolas;panose-1:2 11 6 9 2 2 4 3 2 4;} _filtered #yiv2229194538 {panose-1:2 5 6 4 5 5 5 2 2 4;} _filtered #yiv2229194538 {font-family:Menlo;panose-1:0 0 0 0 0 0 0 0 0 0;}#yiv2229194538 #yiv2229194538 p.yiv2229194538MsoNormal, #yiv2229194538 li.yiv2229194538MsoNormal, #yiv2229194538 div.yiv2229194538MsoNormal {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;}#yiv2229194538 a:link, #yiv2229194538 span.yiv2229194538MsoHyperlink {color:blue;text-decoration:underline;}#yiv2229194538 a:visited, #yiv2229194538 span.yiv2229194538MsoHyperlinkFollowed {color:purple;text-decoration:underline;}#yiv2229194538 pre {margin:0in;margin-bottom:.0001pt;font-size:10.0pt;}#yiv2229194538 p.yiv2229194538MsoAcetate, #yiv2229194538 li.yiv2229194538MsoAcetate, #yiv2229194538 div.yiv2229194538MsoAcetate {margin:0in;margin-bottom:.0001pt;font-size:8.0pt;}#yiv2229194538 span.yiv2229194538HTMLPreformattedChar {font-family:Consolas;}#yiv2229194538 p.yiv2229194538msonormal, #yiv2229194538 li.yiv2229194538msonormal, #yiv2229194538 div.yiv2229194538msonormal {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv2229194538 p.yiv2229194538msochpdefault, #yiv2229194538 li.yiv2229194538msochpdefault, #yiv2229194538 div.yiv2229194538msochpdefault {margin-right:0in;margin-left:0in;font-size:12.0pt;}#yiv2229194538 span.yiv2229194538msohyperlink {}#yiv2229194538 span.yiv2229194538msohyperlinkfollowed {}#yiv2229194538 span.yiv2229194538htmlpreformattedchar {}#yiv2229194538 span.yiv2229194538emailstyle19 {}#yiv2229194538 p.yiv2229194538msonormal1, #yiv2229194538 li.yiv2229194538msonormal1, #yiv2229194538 div.yiv2229194538msonormal1 {margin:0in;margin-bottom:.0001pt;font-size:12.0pt;color:black;}#yiv2229194538 span.yiv2229194538msohyperlink1 {color:blue;text-decoration:underline;}#yiv2229194538 span.yiv2229194538msohyperlinkfollowed1 {color:purple;text-decoration:underline;}#yiv2229194538 span.yiv2229194538htmlpreformattedchar1 {color:black;}#yiv2229194538 span.yiv2229194538emailstyle191 {color:#1F497D;}#yiv2229194538 p.yiv2229194538msochpdefault1, #yiv2229194538 li.yiv2229194538msochpdefault1, #yiv2229194538 div.yiv2229194538msochpdefault1 {margin-right:0in;margin-left:0in;font-size:10.0pt;}#yiv2229194538 span.yiv2229194538BalloonTextChar {}#yiv2229194538 span.yiv2229194538EmailStyle33 {color:#1F497D;}#yiv2229194538 .yiv2229194538MsoChpDefault {font-size:10.0pt;} _filtered #yiv2229194538 {margin:1.0in 1.0in 1.0in 1.0in;}#yiv2229194538 div.yiv2229194538WordSection1 {}#yiv2229194538 ? ? This issue has now gotten much worse and we are unable to enroll clients. We are getting an error saying the server does not have a cert: Do you want download the CA cert from http://ipa1.example.com/ipa/config/ca.crt ? (this is INSECURE) [no]: yes Cannot obtain CA certificate 'http://ipa1.example.com/ipa/config/ca.crt' doesn't have a certificate. Can we somehow replace our certs and revert back to the original one's issue by the dogtag server so we have a standard configuration or is there a clean way to fix this issue? Thank you I was told the GoDaddy certs were just imported using certutil -a but in looking at the certs the original certs were actually replaced. This is only in /etc/dirsrv/slapd-REALM-COM: ?Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust Attributes?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SSL,S/MIME,JAR/XPI ?GD_CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,CNWF_GD ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u ? ?The certs in /etc/dirsrv/slapd-PKI-CA are still the originals: ?[root at ipa2-corp ~]# certutil -L -d /etc/dirsrv/slapd-PKI-IPA/ ?Certificate Nickname ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust Attributes?? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? SSL,S/MIME,JAR/XPI ?IPADOMAIN.COM IPA CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,Server-Cert? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u ??I am not even sure how this even works or if it can be fixed? Should/Can we go back to using the original dogtag certs? ?From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Wednesday, March 04, 2015 2:57 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Need to replace cert for ipa servers?On 03/04/2015 04:32 PM, sipazzo wrote: Good afternoon, we have a freeipa 3.0.42 installation running on redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was originally configured with the built in dogtag certificate CA and then one of my co-workers added our GoDaddy certificate to the certificate bundle. My understanding is this cert is used for communication between the ipa servers as well as the clients are also configured to trust the GoDaddy certificate. We recently had to get a new GoDaddy cert so our old one is revoked. I need to figure out how to either replace the existing revoked cert with the new one or add the new one to the bundle and then remove the revoked certificate so as not to break anything.?Any help is appreciated. I am not strong with certificates so the more detail you can give the better.Thank you. ? You say it was running with the self signed IPA CA and than GoDaddy cert was added to the bundle. How was it added? IPA does not use certs for communication between the instances. It uses Kerberos. I am not sure the DoDaddy cert you added is even used in some way by IPA. It seems that your GoDaddy cert is an orthogonal trust so if you replaced the main key pair then you just need to distribute your new GoDaddy cert to the clients as you did on the first place. -- Thank you,Dmitri Pal ?Sr. Engineering Manager IdM portfolioRed Hat, Inc. ? ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Mar 11 16:39:55 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 12:39:55 -0400 Subject: [Freeipa-users] ipa-server setup with external CA fails In-Reply-To: References: Message-ID: <55006FDB.2000903@redhat.com> On 03/11/2015 11:13 AM, Gould, Joshua wrote: > We?re trying to setup IPA with it acting as an intermediate CA against our > test Active Directory environment. > > The first part goes well: > > # ipa-server-install -a admin-pass ?hostname=server.domain.com -n > unix.test.osuwmc -p password -P password -r UNIX.TEST.OSUWMC > --external-ca ?external-ca-type=ms?cs > > We send our CSR off to our AD admin and he signs it on gives us the cert. > We go to import the cert with: > > # ipa-server-install --external-cert-file=/root/ipa.crt > > It blows up when trying to create the RA cert. > > 2015-03-10T21:17:55Z DEBUG Process finished, return code=0 > 2015-03-10T21:17:55Z DEBUG stdout= > Certificate request generated by Netscape certutil > Phone: (not specified) > Common Name: IPA RA > Email: (not specified) > Organization: UNIX.TEST.OSUWMC > State: (not specified) > Country: (not specified) > -----BEGIN NEW CERTIFICATE REQUEST----- > MIICcTCCAVkCAQAwLDEZMBcGA1UEChMQVU5JWC5URVNULk9TVVdNQzEPMA0GA1UE > AxMGSVBBIFJBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0DavkHxe > PoY8q6UWCAHKWOCCv8PvU7J5scsmdLfjSyN8rIgq8pGoICAqawm9lZntD8G/7sJQ > H2bNDe08DooGbdTLHB2j3JViUUlQn2YlWw7IXm6mgwxStGLSS/G+CnyVPdGWV48X > GHb7GLLNYD8nhpzNzqVGsVMTyV/dqD7y8srbpPjmAqH+VjKLDSmr3pgV2IvOUEpW > wePYJW7h4FBQtwQpPgo30oXMqXa/ob8RJ4NQ74Uv6irq9G2IXNpKhAbHB1YZ+DGm > FJFlURdxey0FUbDn1WqMeVLa6SMURZI1zncMxB6bwgax/2VdYVeYHiVU9GgGmw0F > VgUjgpg0RMCaSQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBAI1YCN5oS2o5+fky > jTNCeWFq+oEyHcuPtGzBAA5HMNEsoFvIY0sut+lf7Upw/ZHvV/F09DPwT+Xrm8yp > D0e6F6HawEV+NvKYk2kmpK9xxyOi0raBz1WuvlmqwGhiTOxpk+nIW5wiNhiOJmzd > xLojqGnkP5tBuYtHXUFqps7KDknsk5VxoAGe3/ZvsDvqlYXF93V+/nXv90X2yEKH > +wLUCDtS5WRWtnxTs1bWsMjBsTyDcv8XBdWqDO/4DVLs9HjHijfsUtUqg8bR5dU1 > kVM+yLXVogJPBMN79SJQ1un8IWNMHCallsX3urNbXxYuSlqsh6UCdRLXFW44jJIK > xAmXvOg= > -----END NEW CERTIFICATE REQUEST----- > 2015-03-10T21:17:55Z DEBUG stderr= > Generating key. This may take a few moments... > 2015-03-10T21:17:55Z 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/cainstance.py", line > 1149, in __request_ra_certificate > self.requestId = item_node[0].childNodes[0].data > IndexError: list index out of range > 2015-03-10T21:17:55Z DEBUG [error] IndexError: list index out of range > 2015-03-10T21:17:55Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", > line 646, in run_script > return_value = main_function() > File "/sbin/ipa-server-install", line 1170, in main > ca_signing_algorithm=options.ca_signing_algorithm) > File > "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line > 520, in configure_instance > self.start_creation(runtime=210) > 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/cainstance.py", line > 1149, in __request_ra_certificate > self.requestId = item_node[0].childNodes[0].data > 2015-03-10T21:17:55Z DEBUG The ipa-server-install command failed, > exception: IndexError: list index out of range > > > I?ve looked at the debug log. I believe this is the part that?s most > helpful. > > [10/Mar/2015:17:17:24][localhost-startStop-1]: > SelfTestSubsystem::runSelfTestsAtStartup(): ENTERING . . . > [10/Mar/2015:17:17:24][localhost-startStop-1]: > SelfTestSubsystem::runSelfTestsAtStartup(): running "CAPresence" > [10/Mar/2015:17:17:24][localhost-startStop-1]: > SelfTestSubsystem::runSelfTestsAtStartup(): running > "SystemCertsVerification" > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCerts() cert tag=signing > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(): calling isCertValid() > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname() failed:caSigningCert cert-pki-ca > [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Fai > lure][CertNickName=caSigningCert cert-pki-ca] CIMC certificate verification > > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCerts() cert tag=ocsp_signing > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(): calling isCertValid() > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname() failed:ocspSigningCert cert-pki-ca > [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Fai > lure][CertNickName=ocspSigningCert cert-pki-ca] CIMC certificate > verification > > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCerts() cert tag=sslserver > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(): calling isCertValid() > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname() failed:Server-Cert cert-pki-ca > [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Fai > lure][CertNickName=Server-Cert cert-pki-ca] CIMC certificate verification > > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCerts() cert tag=subsystem > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(): calling isCertValid() > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname() failed:subsystemCert cert-pki-ca > [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Fai > lure][CertNickName=subsystemCert cert-pki-ca] CIMC certificate verification > > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCerts() cert tag=audit_signing > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname(): calling isCertValid() > [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: > verifySystemCertByNickname() passed:auditSigningCert cert-pki-ca > [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=Suc > cess][CertNickName=auditSigningCert cert-pki-ca] CIMC certificate > verification > > [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: > create() > message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Failur > e] self tests execution (see selftests.log for details) > > The selftests.log contradicts itself and I?m not really sure where to look > next. Any ideas? > > > Joshua > > > Which version is it? A similar problem have been seen with the early IPA 3.3 version and was related to the format of the cert file returned by AD. AFAIR it contains more certs that we expected. Something along those lines. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From andrew.holway at gmail.com Wed Mar 11 17:13:04 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Wed, 11 Mar 2015 18:13:04 +0100 Subject: [Freeipa-users] Backwards compatability Message-ID: Hi, We have a mix of Centos 6 and Centos 7 machines which we would like to manage with FreeIPA. I remember that setting up freeipa on Centos 6 can be a bit tricky although I found this method which works. https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html I imagine the Centos 7 client setup is somewhat more streamlined. Assuming we install freeipa on Centos 7, will our centos 6 clients have any problem connection? Any caveats which we should be aware of? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Wed Mar 11 17:18:57 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 11 Mar 2015 20:18:57 +0300 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: <55006E35.2090808@redhat.com> References: <55006E35.2090808@redhat.com> Message-ID: HI thanks for the rply. even i tried native auto_master file with directory checking script. if i feed the user manually to the script, the directory is creating and while login request comes, it didn't. i don't think no one did full solaris integration util now as i asked many questions related to that. now i am little bit confident up to this level. and if everything is working fine, i will try to create automated script for IPA join Regards, Ben On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal wrote: > On 03/11/2015 09:50 AM, Ben .T.George wrote: > > HI > > i can able to reach upto level that IPA user can able to login on > solaris box, > > but how can i create home directories automatically on solaris while IPA > user login. > > even i change the shell in IPA web interface that is getting affected. i > saw some option in IPA 3.3 web interface like automount and that is not in > IPA 4.1.2 > > > All the options are still there. The menus got re-arranged a bit. > Hopefully someone with a Solaris knowledge will help you with the rest. > > > please anyone tell me where it is and how can i achieve this > > regards, > Ben > > > > > -- > 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 Joshua.Gould at osumc.edu Wed Mar 11 17:33:43 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Wed, 11 Mar 2015 13:33:43 -0400 Subject: [Freeipa-users] ipa-server setup with external CA fails In-Reply-To: <55006FDB.2000903@redhat.com> References: <55006FDB.2000903@redhat.com> Message-ID: We?re trying to setup RHEL7 with the latest updates. Our ipa-server shows ipa-server-4.1.0-18.el7.x86_64. On 3/11/15, 12:39 PM, "Dmitri Pal" wrote: >On 03/11/2015 11:13 AM, Gould, Joshua wrote: >> We?re trying to setup IPA with it acting as an intermediate CA against >>our >> test Active Directory environment. >> >> The first part goes well: >> >> # ipa-server-install -a admin-pass ?hostname=server.domain.com -n >> unix.test.osuwmc -p password -P password -r UNIX.TEST.OSUWMC >> --external-ca ?external-ca-type=ms?cs >> >> We send our CSR off to our AD admin and he signs it on gives us the >>cert. >> We go to import the cert with: >> >> # ipa-server-install --external-cert-file=/root/ipa.crt >> >> It blows up when trying to create the RA cert. >> >> 2015-03-10T21:17:55Z DEBUG Process finished, return code=0 >> 2015-03-10T21:17:55Z DEBUG stdout= >> Certificate request generated by Netscape certutil >> Phone: (not specified) >> Common Name: IPA RA >> Email: (not specified) >> Organization: UNIX.TEST.OSUWMC >> State: (not specified) >> Country: (not specified) >> -----BEGIN NEW CERTIFICATE REQUEST----- >> MIICcTCCAVkCAQAwLDEZMBcGA1UEChMQVU5JWC5URVNULk9TVVdNQzEPMA0GA1UE >> AxMGSVBBIFJBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0DavkHxe >> PoY8q6UWCAHKWOCCv8PvU7J5scsmdLfjSyN8rIgq8pGoICAqawm9lZntD8G/7sJQ >> H2bNDe08DooGbdTLHB2j3JViUUlQn2YlWw7IXm6mgwxStGLSS/G+CnyVPdGWV48X >> GHb7GLLNYD8nhpzNzqVGsVMTyV/dqD7y8srbpPjmAqH+VjKLDSmr3pgV2IvOUEpW >> wePYJW7h4FBQtwQpPgo30oXMqXa/ob8RJ4NQ74Uv6irq9G2IXNpKhAbHB1YZ+DGm >> FJFlURdxey0FUbDn1WqMeVLa6SMURZI1zncMxB6bwgax/2VdYVeYHiVU9GgGmw0F >> VgUjgpg0RMCaSQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBAI1YCN5oS2o5+fky >> jTNCeWFq+oEyHcuPtGzBAA5HMNEsoFvIY0sut+lf7Upw/ZHvV/F09DPwT+Xrm8yp >> D0e6F6HawEV+NvKYk2kmpK9xxyOi0raBz1WuvlmqwGhiTOxpk+nIW5wiNhiOJmzd >> xLojqGnkP5tBuYtHXUFqps7KDknsk5VxoAGe3/ZvsDvqlYXF93V+/nXv90X2yEKH >> +wLUCDtS5WRWtnxTs1bWsMjBsTyDcv8XBdWqDO/4DVLs9HjHijfsUtUqg8bR5dU1 >> kVM+yLXVogJPBMN79SJQ1un8IWNMHCallsX3urNbXxYuSlqsh6UCdRLXFW44jJIK >> xAmXvOg= >> -----END NEW CERTIFICATE REQUEST----- >> 2015-03-10T21:17:55Z DEBUG stderr= >> Generating key. This may take a few moments... >> 2015-03-10T21:17:55Z 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/cainstance.py", line >> 1149, in __request_ra_certificate >> self.requestId = item_node[0].childNodes[0].data >> IndexError: list index out of range >> 2015-03-10T21:17:55Z DEBUG [error] IndexError: list index out of range >> 2015-03-10T21:17:55Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >> line 646, in run_script >> return_value = main_function() >> File "/sbin/ipa-server-install", line 1170, in main >> ca_signing_algorithm=options.ca_signing_algorithm) >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >> 520, in configure_instance >> self.start_creation(runtime=210) >> 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/cainstance.py", line >> 1149, in __request_ra_certificate >> self.requestId = item_node[0].childNodes[0].data >> 2015-03-10T21:17:55Z DEBUG The ipa-server-install command failed, >> exception: IndexError: list index out of range >> >> >> I?ve looked at the debug log. I believe this is the part that?s most >> helpful. >> >> [10/Mar/2015:17:17:24][localhost-startStop-1]: >> SelfTestSubsystem::runSelfTestsAtStartup(): ENTERING . . . >> [10/Mar/2015:17:17:24][localhost-startStop-1]: >> SelfTestSubsystem::runSelfTestsAtStartup(): running "CAPresence" >> [10/Mar/2015:17:17:24][localhost-startStop-1]: >> SelfTestSubsystem::runSelfTestsAtStartup(): running >> "SystemCertsVerification" >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCerts() cert tag=signing >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname(): calling isCertValid() >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname() failed:caSigningCert cert-pki-ca >> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >> create() >> >>message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>ai >> lure][CertNickName=caSigningCert cert-pki-ca] CIMC certificate >>verification >> >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCerts() cert tag=ocsp_signing >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname(): calling isCertValid() >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname() failed:ocspSigningCert cert-pki-ca >> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >> create() >> >>message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>ai >> lure][CertNickName=ocspSigningCert cert-pki-ca] CIMC certificate >> verification >> >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCerts() cert tag=sslserver >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname(): calling isCertValid() >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname() failed:Server-Cert cert-pki-ca >> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >> create() >> >>message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>ai >> lure][CertNickName=Server-Cert cert-pki-ca] CIMC certificate >>verification >> >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCerts() cert tag=subsystem >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname(): calling isCertValid() >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname() failed:subsystemCert cert-pki-ca >> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >> create() >> >>message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>ai >> lure][CertNickName=subsystemCert cert-pki-ca] CIMC certificate >>verification >> >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCerts() cert tag=audit_signing >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname(): calling isCertValid() >> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >> verifySystemCertByNickname() passed:auditSigningCert cert-pki-ca >> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >> create() >> >>message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=S >>uc >> cess][CertNickName=auditSigningCert cert-pki-ca] CIMC certificate >> verification >> >> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >> create() >> >>message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Fail >>ur >> e] self tests execution (see selftests.log for details) >> >> The selftests.log contradicts itself and I?m not really sure where to >>look >> next. Any ideas? >> >> >> Joshua >> >> >> >Which version is it? >A similar problem have been seen with the early IPA 3.3 version and was >related to the format of the cert file returned by AD. AFAIR it contains >more certs that we expected. >Something along those lines. > >-- >Thank you, >Dmitri Pal > >Sr. Engineering Manager IdM portfolio >Red Hat, Inc. > >-- >Manage your subscription for the Freeipa-users mailing list: >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma >n_listinfo_freeipa-2Dusers&d=AwIF-g&c=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S >FEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24&m=h5oW5B694QIxIFZz30 >YpHYRTTf82-7TQJn-c3JZPMEI&s=bekc3w9LwD5vNCRvK7q44uOWht6TAjts5vO9uxCXsCo&e= > >Go to >https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.org&d=AwIF-g&c >=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk >8zPbIs_SvJwojC24&m=h5oW5B694QIxIFZz30YpHYRTTf82-7TQJn-c3JZPMEI&s=5wQ5LeH20 >oFmoV1OwkXJQHYOm1ZZdUEe9uqwmJKSaCk&e= for more info on the project From guertin at middlebury.edu Wed Mar 11 17:41:04 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Wed, 11 Mar 2015 17:41:04 +0000 Subject: [Freeipa-users] Can't add AD user group to IPA group In-Reply-To: <20150310114733.GL25455@redhat.com> References: <1425672251562.91790@middlebury.edu> <20150308204011.GP3477@hendrix.arn.redhat.com> <54FED525.9080002@redhat.com> <6e1738b9b5ad4336b35f6f6f07b39505@greyhound.middlebury.edu> <20150310114733.GL25455@redhat.com> Message-ID: > For troubleshooting this you need to enable debug_level=10 in sssd.conf in > domain and pam sections. Restart sssd and try to login. OK, this has pinpointed the problem. The log file now shows: (Wed Mar 11 11:31:01 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x1000): Mapping user [guertin-s] objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to unix ID (Wed Mar 11 11:31:01 2015) [sssd[be[middlebury.edu]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID It seems that this is due to incorrect ID range settings. So I have increased the ID range to 2,000,000, which ought to be enough for a RID of 245906: # ipa idrange-find ---------------- 2 ranges matched ---------------- Range name: CSNS.MIDDLEBURY.EDU_id_range First Posix ID of the range: 528800000 Number of IDs in the range: 2000000 First RID of the corresponding RID range: 1 First RID of the secondary RID range: 2000001 Range type: local domain range Range name: MIDDLEBURY.EDU_id_range First Posix ID of the range: 1000 Number of IDs in the range: 2000000 Domain SID of the trusted domain: S-1-5-21-1983215674-46037090-646806464 Range type: Active Directory trust range with POSIX attributes ---------------------------- Number of entries returned 2 ---------------------------- But the problem still persists. I cannot SSH in as a user (getent passwd, id, etc. all still do show the users). David Guertin From dpal at redhat.com Wed Mar 11 17:46:09 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 13:46:09 -0400 Subject: [Freeipa-users] Backwards compatability In-Reply-To: References: Message-ID: <55007F61.8070408@redhat.com> On 03/11/2015 01:13 PM, Andrew Holway wrote: > Hi, > > We have a mix of Centos 6 and Centos 7 machines which we would like to > manage with FreeIPA. > > I remember that setting up freeipa on Centos 6 can be a bit tricky > although I found this method which works. > > https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html > > I imagine the Centos 7 client setup is somewhat more streamlined. > > Assuming we install freeipa on Centos 7, will our centos 6 clients > have any problem connection? Any caveats which we should be aware of? > > Thanks, > > Andrew > > Clients should work without any issues. The only thing to keep in mind is that IPA's remote management CLI should be used from the systems of the same versions as the server. In other words the ipa-admintools package that contains CLI would not work from CentOS 6 system against CentOS 7 system. But would work from 7 to 7. -- 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 Mar 11 17:49:47 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 13:49:47 -0400 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: References: <55006E35.2090808@redhat.com> Message-ID: <5500803B.7020108@redhat.com> On 03/11/2015 01:18 PM, Ben .T.George wrote: > HI > > thanks for the rply. > > even i tried native auto_master file with directory checking script. > if i feed the user manually to the script, the directory is creating > and while login request comes, it didn't. > > i don't think no one did full solaris integration util now as i asked > many questions related to that. > > now i am little bit confident up to this level. and if everything is > working fine, i will try to create automated script for IPA join I really do not know Solaris that well. There are some threads from this and last week about Solaris. You can find them in the mail archive for March. There are pointers to wikis and bugzillas in those threads. The bugzilla bugs have some extended info on how to configure Solaris clients. They were pretty detailed. May be they have the automount info you are looking for. > > Regards, > Ben > > > > On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal > wrote: > > On 03/11/2015 09:50 AM, Ben .T.George wrote: >> HI >> >> i can able to reach upto level that IPA user can able to login on >> solaris box, >> >> but how can i create home directories automatically on solaris >> while IPA user login. >> >> even i change the shell in IPA web interface that is getting >> affected. i saw some option in IPA 3.3 web interface like >> automount and that is not in IPA 4.1.2 > > All the options are still there. The menus got re-arranged a bit. > Hopefully someone with a Solaris knowledge will help you with the > rest. > >> >> please anyone tell me where it is and how can i achieve this >> >> regards, >> Ben >> >> > > > -- > 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 bentech4you at gmail.com Wed Mar 11 17:56:11 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 11 Mar 2015 20:56:11 +0300 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: <5500803B.7020108@redhat.com> References: <55006E35.2090808@redhat.com> <5500803B.7020108@redhat.com> Message-ID: HI yea , i saw that mail thread and he claims that he achieved somehow. but not clear. and the steps mentioned is too technical for me. :) as i am very new to IPA it's bit confusing. later that thread also closed without proper explanation. i think you guys can contact him to change existing wiki :) as there are many solaris related documents which is pretty old. anyway still waiting for rply Regards, Ben On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal wrote: > On 03/11/2015 01:18 PM, Ben .T.George wrote: > > HI > > thanks for the rply. > > even i tried native auto_master file with directory checking script. if > i feed the user manually to the script, the directory is creating and while > login request comes, it didn't. > > i don't think no one did full solaris integration util now as i asked > many questions related to that. > > now i am little bit confident up to this level. and if everything is > working fine, i will try to create automated script for IPA join > > > I really do not know Solaris that well. There are some threads from this > and last week about Solaris. You can find them in the mail archive for > March. > There are pointers to wikis and bugzillas in those threads. The bugzilla > bugs have some extended info on how to configure Solaris clients. They were > pretty detailed. May be they have the automount info you are looking for. > > > > Regards, > Ben > > > > On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal wrote: > >> On 03/11/2015 09:50 AM, Ben .T.George wrote: >> >> HI >> >> i can able to reach upto level that IPA user can able to login on >> solaris box, >> >> but how can i create home directories automatically on solaris while >> IPA user login. >> >> even i change the shell in IPA web interface that is getting affected. >> i saw some option in IPA 3.3 web interface like automount and that is not >> in IPA 4.1.2 >> >> >> All the options are still there. The menus got re-arranged a bit. >> Hopefully someone with a Solaris knowledge will help you with the rest. >> >> >> please anyone tell me where it is and how can i achieve this >> >> regards, >> Ben >> >> >> >> >> -- >> 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 dpal at redhat.com Wed Mar 11 18:11:55 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 14:11:55 -0400 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: References: <55006E35.2090808@redhat.com> <5500803B.7020108@redhat.com> Message-ID: <5500856B.2000205@redhat.com> On 03/11/2015 01:56 PM, Ben .T.George wrote: > HI > > yea , i saw that mail thread and he claims that he achieved somehow. > but not clear. > > and the steps mentioned is too technical for me. :) as i am very new > to IPA it's bit confusing. > > later that thread also closed without proper explanation. > > i think you guys can contact him to change existing wiki :) as there > are many solaris related documents which is pretty old. > > anyway still waiting for rply Have you found the BZ? They are very detailed. https://bugzilla.redhat.com/show_bug.cgi?id=815515 The DUA profile is attached to the bug. > > Regards, > Ben > > On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal > wrote: > > On 03/11/2015 01:18 PM, Ben .T.George wrote: >> HI >> >> thanks for the rply. >> >> even i tried native auto_master file with directory checking >> script. if i feed the user manually to the script, the directory >> is creating and while login request comes, it didn't. >> >> i don't think no one did full solaris integration util now as i >> asked many questions related to that. >> >> now i am little bit confident up to this level. and if everything >> is working fine, i will try to create automated script for IPA join > > I really do not know Solaris that well. There are some threads > from this and last week about Solaris. You can find them in the > mail archive for March. > There are pointers to wikis and bugzillas in those threads. The > bugzilla bugs have some extended info on how to configure Solaris > clients. They were pretty detailed. May be they have the automount > info you are looking for. > > >> >> Regards, >> Ben >> >> >> >> On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal > > wrote: >> >> On 03/11/2015 09:50 AM, Ben .T.George wrote: >>> HI >>> >>> i can able to reach upto level that IPA user can able to >>> login on solaris box, >>> >>> but how can i create home directories automatically on >>> solaris while IPA user login. >>> >>> even i change the shell in IPA web interface that is getting >>> affected. i saw some option in IPA 3.3 web interface like >>> automount and that is not in IPA 4.1.2 >> >> All the options are still there. The menus got re-arranged a bit. >> Hopefully someone with a Solaris knowledge will help you with >> the rest. >> >>> >>> please anyone tell me where it is and how can i achieve this >>> >>> regards, >>> Ben >>> >>> >> >> >> -- >> 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Wed Mar 11 18:22:02 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 11 Mar 2015 21:22:02 +0300 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: <5500856B.2000205@redhat.com> References: <55006E35.2090808@redhat.com> <5500803B.7020108@redhat.com> <5500856B.2000205@redhat.com> Message-ID: from BZ "While we value your interest in IPA Solaris support, the implementation of the DUA profile is not on our nearest schedule at the moment. We lack both knowledge and resources to focus on integration with Solaris. This is where we need a help (ideally patches) and contribution from the community to help us push these features in. I checked your example DUAConfigProfile and I think it cannot be just added to FreeIPA right away. E.g. for defaultServerList or preferredServerList, you would need to expand installers and ipa-replica-manage to handle these lists and update them when replica is added or updated to prevent it being outdated. printers or aliases serviceSearchDescriptor refers to objects not being available and so on. It is not as straightforward as it seems. What I think that we can work on is to work together onhttp://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 ... and add all the steps needed to make IPA work on Solaris 10. I could for example prepare an updated page and you could review it. Would that work for you?" this what i followed util now. but's not authenticate with AD, IPA user can login on solaris box On Wed, Mar 11, 2015 at 9:11 PM, Dmitri Pal wrote: > On 03/11/2015 01:56 PM, Ben .T.George wrote: > > HI > > yea , i saw that mail thread and he claims that he achieved somehow. but > not clear. > > and the steps mentioned is too technical for me. :) as i am very new to > IPA it's bit confusing. > > later that thread also closed without proper explanation. > > i think you guys can contact him to change existing wiki :) as there are > many solaris related documents which is pretty old. > > anyway still waiting for rply > > > Have you found the BZ? They are very detailed. > https://bugzilla.redhat.com/show_bug.cgi?id=815515 > The DUA profile is attached to the bug. > > > > Regards, > Ben > > On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal wrote: > >> On 03/11/2015 01:18 PM, Ben .T.George wrote: >> >> HI >> >> thanks for the rply. >> >> even i tried native auto_master file with directory checking script. if >> i feed the user manually to the script, the directory is creating and while >> login request comes, it didn't. >> >> i don't think no one did full solaris integration util now as i asked >> many questions related to that. >> >> now i am little bit confident up to this level. and if everything is >> working fine, i will try to create automated script for IPA join >> >> >> I really do not know Solaris that well. There are some threads from this >> and last week about Solaris. You can find them in the mail archive for >> March. >> There are pointers to wikis and bugzillas in those threads. The bugzilla >> bugs have some extended info on how to configure Solaris clients. They were >> pretty detailed. May be they have the automount info you are looking for. >> >> >> >> Regards, >> Ben >> >> >> >> On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal wrote: >> >>> On 03/11/2015 09:50 AM, Ben .T.George wrote: >>> >>> HI >>> >>> i can able to reach upto level that IPA user can able to login on >>> solaris box, >>> >>> but how can i create home directories automatically on solaris while >>> IPA user login. >>> >>> even i change the shell in IPA web interface that is getting affected. >>> i saw some option in IPA 3.3 web interface like automount and that is not >>> in IPA 4.1.2 >>> >>> >>> All the options are still there. The menus got re-arranged a bit. >>> Hopefully someone with a Solaris knowledge will help you with the rest. >>> >>> >>> please anyone tell me where it is and how can i achieve this >>> >>> regards, >>> Ben >>> >>> >>> >>> >>> -- >>> 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. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.topping at gmail.com Wed Mar 11 19:02:41 2015 From: brian.topping at gmail.com (Brian Topping) Date: Wed, 11 Mar 2015 15:02:41 -0400 Subject: [Freeipa-users] Weird IPA shutdown issues Message-ID: <5690D6D3-343E-4F95-A2C1-DCC6E525F27D@gmail.com> Hi all, I have a weird shutdown issue on an IPA instance (ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64) on CentOS (CentOS Linux release 7.0.1406) that's been working fine for at least six months, maybe longer. It's replicated to an identical instance that is having no problems. https://gist.github.com/briantopping/2fc430038b4ca6c80d05 is the relevant snippets of /var/log/messages. It starts booting up, everything working, then systemd decides to shut down IPA for no apparent reason. I haven't touched any system software for several weeks. When the system is booting, "runlevel" reports "unknown". It seems to be about the same time that it changes to "N 3" that everything starts shutting down. My sense is systemd is configured with some dependency in the IPA processes that it (correctly) finds a fault and shut everything down. I just don't see anything in the messages above that would indicate such a fault. By the time it's over, even named is shut down! Systemd is new to me still, if I need to RTFM, I guess that's one answer, but I thought I would check here to see if I could get a better idea of how everything is wired. I am limping by on the second box for now, so this isn't an emergency. Thanks for any consideration to this! Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From erinn.looneytriggs at gmail.com Wed Mar 11 19:15:31 2015 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Wed, 11 Mar 2015 13:15:31 -0600 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 Message-ID: <4210294.jkvoj2gI6j@scrapy.abaqis.com> First off congratulations on getting this out. Love the new UI, all pretty and integrates well with the access.redhat.com UI. Second, did DNSSEC not make the chop? It looks like for FreeIPA DNSSEC was included in the 4.1.0 release, but near as I can tell it is not part of IPA 4.1.0 in RHEL 7.1. Third, there appears to be a behavior change from in ipalib. I cleaned up a little inventory script for ansible, you can take a look at it here: https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 worked, now it fails: Traceback (most recent call last): File "./freeipa.py", line 133, in list_groups(api) File "./freeipa.py", line 71, in list_groups result = api.Command.host_find()['result'] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, in forward command = getattr(self.conn, name) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'MainThread' Is this expected? Is this a regression? Thanks again for your work. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From brian.topping at gmail.com Wed Mar 11 19:19:09 2015 From: brian.topping at gmail.com (Brian Topping) Date: Wed, 11 Mar 2015 15:19:09 -0400 Subject: [Freeipa-users] SOLVED (Re: Weird IPA shutdown issues) In-Reply-To: <5690D6D3-343E-4F95-A2C1-DCC6E525F27D@gmail.com> References: <5690D6D3-343E-4F95-A2C1-DCC6E525F27D@gmail.com> Message-ID: <135C0C3E-F7F6-4C01-88F1-B1FE4ED78FC8@gmail.com> Okay, one of those "as soon as you press send" issues. The problem that wasn't obvious was that the tomcat service was enabled on the first box. Seems to be stable after removing that and rebooting. Whew!! > On Mar 11, 2015, at 3:02 PM, Brian Topping wrote: > > Hi all, I have a weird shutdown issue on an IPA instance (ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64) on CentOS (CentOS Linux release 7.0.1406) that's been working fine for at least six months, maybe longer. It's replicated to an identical instance that is having no problems. > > https://gist.github.com/briantopping/2fc430038b4ca6c80d05 is the relevant snippets of /var/log/messages. It starts booting up, everything working, then systemd decides to shut down IPA for no apparent reason. I haven't touched any system software for several weeks. > > When the system is booting, "runlevel" reports "unknown". It seems to be about the same time that it changes to "N 3" that everything starts shutting down. > > My sense is systemd is configured with some dependency in the IPA processes that it (correctly) finds a fault and shut everything down. I just don't see anything in the messages above that would indicate such a fault. By the time it's over, even named is shut down! > > Systemd is new to me still, if I need to RTFM, I guess that's one answer, but I thought I would check here to see if I could get a better idea of how everything is wired. > > I am limping by on the second box for now, so this isn't an emergency. > > Thanks for any consideration to this! > > Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From rcritten at redhat.com Wed Mar 11 19:36:36 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Mar 2015 15:36:36 -0400 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: References: <55006E35.2090808@redhat.com> Message-ID: <55009944.10704@redhat.com> Ben .T.George wrote: > HI > > thanks for the rply. > > even i tried native auto_master file with directory checking script. if > i feed the user manually to the script, the directory is creating and > while login request comes, it didn't. > > i don't think no one did full solaris integration util now as i asked > many questions related to that. > > now i am little bit confident up to this level. and if everything is > working fine, i will try to create automated script for IPA join automount is not a technology that automatically creates directories, it just automatically mounts them on demand. I'm not aware of a way to automatically create directories on new-user logins in Solaris. rob > > Regards, > Ben > > > > On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal > wrote: > > On 03/11/2015 09:50 AM, Ben .T.George wrote: >> HI >> >> i can able to reach upto level that IPA user can able to login on >> solaris box, >> >> but how can i create home directories automatically on solaris >> while IPA user login. >> >> even i change the shell in IPA web interface that is getting >> affected. i saw some option in IPA 3.3 web interface like >> automount and that is not in IPA 4.1.2 > > All the options are still there. The menus got re-arranged a bit. > Hopefully someone with a Solaris knowledge will help you with the rest. > >> >> please anyone tell me where it is and how can i achieve this >> >> regards, >> Ben >> >> > > > -- > 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 Steven.Jones at vuw.ac.nz Wed Mar 11 19:43:57 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 11 Mar 2015 19:43:57 +0000 Subject: [Freeipa-users] Extending IPA to include multiple (say 5) fields for MAC addresses per user In-Reply-To: <135C0C3E-F7F6-4C01-88F1-B1FE4ED78FC8@gmail.com> References: <5690D6D3-343E-4F95-A2C1-DCC6E525F27D@gmail.com>, <135C0C3E-F7F6-4C01-88F1-B1FE4ED78FC8@gmail.com> Message-ID: <1426102883958.97607@vuw.ac.nz> Hi, I have been asked to look at packetfence and linking it to IPA for authentication but I might need to allow users to login into their IPA info and add MAC addresses themselves, this is possible I think? Since ppl these days can have 3 mobile devices, (ipad, iphone and laptop) I would need multiple MAC fields so would have to extend IPA's schema? is this a good idea? regards Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Wed Mar 11 19:49:34 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 11 Mar 2015 19:49:34 +0000 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <4210294.jkvoj2gI6j@scrapy.abaqis.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> Message-ID: <1426103220469.42356@vuw.ac.nz> Hi, When I try to join a 7.1 based replica to an existing setup and use an AD forwarder the command complains that the AD box isnt doing DNSSEC suggesting to me it is present in 7.1? At the moment however I cant join a 7.1 based IPA server into a 6.6 based IPA cluster. Or a 7.1 client to IPA, to 6.6 for that matter, 7.0 works fine though. regards Steven ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Erinn Looney-Triggs Sent: Thursday, 12 March 2015 8:15 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 First off congratulations on getting this out. Love the new UI, all pretty and integrates well with the access.redhat.com UI. Second, did DNSSEC not make the chop? It looks like for FreeIPA DNSSEC was included in the 4.1.0 release, but near as I can tell it is not part of IPA 4.1.0 in RHEL 7.1. Third, there appears to be a behavior change from in ipalib. I cleaned up a little inventory script for ansible, you can take a look at it here: https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 worked, now it fails: Traceback (most recent call last): File "./freeipa.py", line 133, in list_groups(api) File "./freeipa.py", line 71, in list_groups result = api.Command.host_find()['result'] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ ret = self.run(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run return self.forward(*args, **options) File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in forward return self.Backend.rpcclient.forward(self.name, *args, **kw) File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, in forward command = getattr(self.conn, name) File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in __get_conn self.id, threading.currentThread().getName()) AttributeError: no context.rpcclient in thread 'MainThread' Is this expected? Is this a regression? Thanks again for your work. -Erinn From natxo.asenjo at gmail.com Wed Mar 11 19:51:02 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Wed, 11 Mar 2015 20:51:02 +0100 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: <55009944.10704@redhat.com> References: <55006E35.2090808@redhat.com> <55009944.10704@redhat.com> Message-ID: On Wed, Mar 11, 2015 at 8:36 PM, Rob Crittenden wrote: > Ben .T.George wrote: > > HI > > > > thanks for the rply. > > > > even i tried native auto_master file with directory checking script. if > > i feed the user manually to the script, the directory is creating and > > while login request comes, it didn't. > > > > i don't think no one did full solaris integration util now as i asked > > many questions related to that. > > > > now i am little bit confident up to this level. and if everything is > > working fine, i will try to create automated script for IPA join > > automount is not a technology that automatically creates directories, it > just automatically mounts them on demand. > > I'm not aware of a way to automatically create directories on new-user > logins in Solaris. > I have not used 'official' solaris but using omnios (open solaris derivative) I have used this with their automounter: http://omnios.omniti.com/wiki.php/GeneralAdministration#Addinglocalusers Quite nifty. It should work with solaris as well (well, maybe with a little work). -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Mar 11 20:05:25 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 16:05:25 -0400 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <4210294.jkvoj2gI6j@scrapy.abaqis.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> Message-ID: <5500A005.5010500@redhat.com> On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: > First off congratulations on getting this out. Love the new UI, all pretty and > integrates well with the access.redhat.com UI. Thanks! > Second, did DNSSEC not make the chop? It looks like for FreeIPA DNSSEC was > included in the 4.1.0 release, but near as I can tell it is not part of IPA > 4.1.0 in RHEL 7.1. It did not make the cut. The DNSSEC feature is not in RHEL7 yet. But we are working on making this happen. > > Third, there appears to be a behavior change from in ipalib. I cleaned up a > little inventory script for ansible, you can take a look at it here: > https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py > > Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 > worked, now it fails: > > Traceback (most recent call last): > File "./freeipa.py", line 133, in > list_groups(api) > File "./freeipa.py", line 71, in list_groups > result = api.Command.host_find()['result'] > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in > forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, in forward > command = getattr(self.conn, name) > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in > __get_conn > self.id, threading.currentThread().getName()) > AttributeError: no context.rpcclient in thread 'MainThread' > > Is this expected? Is this a regression? Some things changed. I would leave for developers to take a look and provide more guidance. > > Thanks again for your work. > > -Erinn > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Wed Mar 11 20:06:23 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 11 Mar 2015 23:06:23 +0300 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: References: <55006E35.2090808@redhat.com> <55009944.10704@redhat.com> Message-ID: Hi Naxto, i think your solutions will work in my case. sems like both os's are same. using opensolaris anyway let me try this and will let you know the status Thanks & regards, Ben On Wed, Mar 11, 2015 at 10:51 PM, Natxo Asenjo wrote: > On Wed, Mar 11, 2015 at 8:36 PM, Rob Crittenden > wrote: > >> Ben .T.George wrote: >> > HI >> > >> > thanks for the rply. >> > >> > even i tried native auto_master file with directory checking script. if >> > i feed the user manually to the script, the directory is creating and >> > while login request comes, it didn't. >> > >> > i don't think no one did full solaris integration util now as i asked >> > many questions related to that. >> > >> > now i am little bit confident up to this level. and if everything is >> > working fine, i will try to create automated script for IPA join >> >> automount is not a technology that automatically creates directories, it >> just automatically mounts them on demand. >> >> I'm not aware of a way to automatically create directories on new-user >> logins in Solaris. >> > > I have not used 'official' solaris but using omnios (open solaris > derivative) I have used this with their automounter: > > http://omnios.omniti.com/wiki.php/GeneralAdministration#Addinglocalusers > > Quite nifty. It should work with solaris as well (well, maybe with a > little work). > > -- > regards, > natxo > > -- > 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 Wed Mar 11 20:07:00 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 16:07:00 -0400 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <1426103220469.42356@vuw.ac.nz> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <1426103220469.42356@vuw.ac.nz> Message-ID: <5500A064.6090202@redhat.com> On 03/11/2015 03:49 PM, Steven Jones wrote: > Hi, > > When I try to join a 7.1 based replica to an existing setup and use an AD forwarder the command complains that the AD box isnt doing DNSSEC suggesting to me it is present in 7.1? Can you share the message that you get and what steps you take to get to that message? > > At the moment however I cant join a 7.1 based IPA server into a 6.6 based IPA cluster. Or a 7.1 client to IPA, to 6.6 for that matter, 7.0 works fine though. > > > regards > > Steven > > ________________________________________ > From: freeipa-users-bounces at redhat.com on behalf of Erinn Looney-Triggs > Sent: Thursday, 12 March 2015 8:15 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 > > First off congratulations on getting this out. Love the new UI, all pretty and > integrates well with the access.redhat.com UI. > > Second, did DNSSEC not make the chop? It looks like for FreeIPA DNSSEC was > included in the 4.1.0 release, but near as I can tell it is not part of IPA > 4.1.0 in RHEL 7.1. > > Third, there appears to be a behavior change from in ipalib. I cleaned up a > little inventory script for ansible, you can take a look at it here: > https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py > > Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 > worked, now it fails: > > Traceback (most recent call last): > File "./freeipa.py", line 133, in > list_groups(api) > File "./freeipa.py", line 71, in list_groups > result = api.Command.host_find()['result'] > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in > forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, in forward > command = getattr(self.conn, name) > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in > __get_conn > self.id, threading.currentThread().getName()) > AttributeError: no context.rpcclient in thread 'MainThread' > > Is this expected? Is this a regression? > > Thanks again for your work. > > -Erinn > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Wed Mar 11 20:10:42 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 11 Mar 2015 21:10:42 +0100 Subject: [Freeipa-users] ipa-server setup with external CA fails In-Reply-To: References: <55006FDB.2000903@redhat.com> Message-ID: <5500A142.3020503@redhat.com> On 03/11/2015 06:33 PM, Gould, Joshua wrote: > We?re trying to setup RHEL7 with the latest updates. Our ipa-server shows > ipa-server-4.1.0-18.el7.x86_64. > > On 3/11/15, 12:39 PM, "Dmitri Pal" wrote: > >> On 03/11/2015 11:13 AM, Gould, Joshua wrote: >>> We?re trying to setup IPA with it acting as an intermediate CA against >>> our >>> test Active Directory environment. >>> >>> The first part goes well: >>> >>> # ipa-server-install -a admin-pass ?hostname=server.domain.com -n >>> unix.test.osuwmc -p password -P password -r UNIX.TEST.OSUWMC >>> --external-ca ?external-ca-type=ms?cs >>> >>> We send our CSR off to our AD admin and he signs it on gives us the >>> cert. >>> We go to import the cert with: >>> >>> # ipa-server-install --external-cert-file=/root/ipa.crt >>> >>> It blows up when trying to create the RA cert. >>> >>> 2015-03-10T21:17:55Z DEBUG Process finished, return code=0 >>> 2015-03-10T21:17:55Z DEBUG stdout= >>> Certificate request generated by Netscape certutil >>> Phone: (not specified) >>> Common Name: IPA RA >>> Email: (not specified) >>> Organization: UNIX.TEST.OSUWMC >>> State: (not specified) >>> Country: (not specified) >>> -----BEGIN NEW CERTIFICATE REQUEST----- >>> MIICcTCCAVkCAQAwLDEZMBcGA1UEChMQVU5JWC5URVNULk9TVVdNQzEPMA0GA1UE >>> AxMGSVBBIFJBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0DavkHxe >>> PoY8q6UWCAHKWOCCv8PvU7J5scsmdLfjSyN8rIgq8pGoICAqawm9lZntD8G/7sJQ >>> H2bNDe08DooGbdTLHB2j3JViUUlQn2YlWw7IXm6mgwxStGLSS/G+CnyVPdGWV48X >>> GHb7GLLNYD8nhpzNzqVGsVMTyV/dqD7y8srbpPjmAqH+VjKLDSmr3pgV2IvOUEpW >>> wePYJW7h4FBQtwQpPgo30oXMqXa/ob8RJ4NQ74Uv6irq9G2IXNpKhAbHB1YZ+DGm >>> FJFlURdxey0FUbDn1WqMeVLa6SMURZI1zncMxB6bwgax/2VdYVeYHiVU9GgGmw0F >>> VgUjgpg0RMCaSQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBAI1YCN5oS2o5+fky >>> jTNCeWFq+oEyHcuPtGzBAA5HMNEsoFvIY0sut+lf7Upw/ZHvV/F09DPwT+Xrm8yp >>> D0e6F6HawEV+NvKYk2kmpK9xxyOi0raBz1WuvlmqwGhiTOxpk+nIW5wiNhiOJmzd >>> xLojqGnkP5tBuYtHXUFqps7KDknsk5VxoAGe3/ZvsDvqlYXF93V+/nXv90X2yEKH >>> +wLUCDtS5WRWtnxTs1bWsMjBsTyDcv8XBdWqDO/4DVLs9HjHijfsUtUqg8bR5dU1 >>> kVM+yLXVogJPBMN79SJQ1un8IWNMHCallsX3urNbXxYuSlqsh6UCdRLXFW44jJIK >>> xAmXvOg= >>> -----END NEW CERTIFICATE REQUEST----- >>> 2015-03-10T21:17:55Z DEBUG stderr= >>> Generating key. This may take a few moments... >>> 2015-03-10T21:17:55Z 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/cainstance.py", line >>> 1149, in __request_ra_certificate >>> self.requestId = item_node[0].childNodes[0].data >>> IndexError: list index out of range >>> 2015-03-10T21:17:55Z DEBUG [error] IndexError: list index out of range >>> 2015-03-10T21:17:55Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>> line 646, in run_script >>> return_value = main_function() >>> File "/sbin/ipa-server-install", line 1170, in main >>> ca_signing_algorithm=options.ca_signing_algorithm) >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line >>> 520, in configure_instance >>> self.start_creation(runtime=210) >>> 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/cainstance.py", line >>> 1149, in __request_ra_certificate >>> self.requestId = item_node[0].childNodes[0].data >>> 2015-03-10T21:17:55Z DEBUG The ipa-server-install command failed, >>> exception: IndexError: list index out of range >>> >>> >>> I?ve looked at the debug log. I believe this is the part that?s most >>> helpful. >>> >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: >>> SelfTestSubsystem::runSelfTestsAtStartup(): ENTERING . . . >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: >>> SelfTestSubsystem::runSelfTestsAtStartup(): running "CAPresence" >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: >>> SelfTestSubsystem::runSelfTestsAtStartup(): running >>> "SystemCertsVerification" >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCerts() cert tag=signing >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname(): calling isCertValid() >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname() failed:caSigningCert cert-pki-ca >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>> create() >>> >>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>> ai >>> lure][CertNickName=caSigningCert cert-pki-ca] CIMC certificate >>> verification >>> >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCerts() cert tag=ocsp_signing >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname(): calling isCertValid() >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname() failed:ocspSigningCert cert-pki-ca >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>> create() >>> >>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>> ai >>> lure][CertNickName=ocspSigningCert cert-pki-ca] CIMC certificate >>> verification >>> >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCerts() cert tag=sslserver >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname(): calling isCertValid() >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname() failed:Server-Cert cert-pki-ca >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>> create() >>> >>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>> ai >>> lure][CertNickName=Server-Cert cert-pki-ca] CIMC certificate >>> verification >>> >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCerts() cert tag=subsystem >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname(): calling isCertValid() >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname() failed:subsystemCert cert-pki-ca >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>> create() >>> >>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>> ai >>> lure][CertNickName=subsystemCert cert-pki-ca] CIMC certificate >>> verification >>> >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCerts() cert tag=audit_signing >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname(): calling isCertValid() >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>> verifySystemCertByNickname() passed:auditSigningCert cert-pki-ca >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>> create() >>> >>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=S >>> uc >>> cess][CertNickName=auditSigningCert cert-pki-ca] CIMC certificate >>> verification >>> >>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>> create() >>> >>> message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Fail >>> ur >>> e] self tests execution (see selftests.log for details) >>> >>> The selftests.log contradicts itself and I?m not really sure where to >>> look >>> next. Any ideas? >>> >>> >>> Joshua >>> >>> >>> >> Which version is it? >> A similar problem have been seen with the early IPA 3.3 version and was >> related to the format of the cert file returned by AD. AFAIR it contains >> more certs that we expected. >> Something along those lines. I am CCing Jan Cholasta who was fixing very similar error in IPA 3.3.3 in RHEL-7.0 (should have been fixed in RHEL-7.1), he should have more context. I am also CCing Endi from Dogtag team, he may also have some idea from PKI side. HTH, Martin From rcritten at redhat.com Wed Mar 11 20:13:37 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Mar 2015 16:13:37 -0400 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <1420341203.2669446.1426091847417.JavaMail.yahoo@mail.yahoo.com> References: <903DF15B7B9D3B4D9137A06F63687859172C8A724C@FHDP1LUMXC7V33.us.one.verizon.com> <1420341203.2669446.1426091847417.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5500A1F1.2050100@redhat.com> sipazzo wrote: > > > > > * > * > This issue has now gotten much worse and we are unable to enroll > clients. We are getting an error saying the server does not have a cert: > > Do you want download the CA cert from > http://ipa1.example.com/ipa/config/ca.crt ? > (this is INSECURE) [no]: yes > Cannot obtain CA certificate > 'http://ipa1.example.com/ipa/config/ca.crt' doesn't have a certificate.j I don't see how this is at all related, or new. The CA cert exists in the filesystem in /usr/share/ipa/html/ca.crt. It wouldn't be affected by expiring certificates. > Can we somehow replace our certs and revert back to the original one's > issue by the dogtag server so we have a standard configuration or is > there a clean way to fix this issue? You swapped out for the GoDaddy cert for a reason. I'd start there. Do you need to retain that cert or is it acceptable to try to revert back to IPA server certs? Note that going back could affect clients enrolled using the GoDaddy cert depending on how your machines are configured (if using SSSD then not likely a problem). As Dmitri said we mostly use Kerberos to communicate. rob > > Thank you > > > > I was told the GoDaddy certs were just imported using certutil -a but in > looking at the certs the original certs were actually replaced. This is > only in /etc/dirsrv/slapd-REALM-COM: > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > GD_CA CT,C,C > NWF_GD u,u,u > > > The certs in /etc/dirsrv/slapd-PKI-CA are still the originals: > > [root at ipa2-corp ~]# certutil -L -d /etc/dirsrv/slapd-PKI-IPA/ > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > IPADOMAIN.COM IPA CA CT,C, > Server-Cert u,u,u > > I am not even sure how this even works or if it can be fixed? > Should/Can we go back to using the original dogtag certs? > ------------------------------------------------------------------------ > > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Wednesday, March 04, 2015 2:57 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Need to replace cert for ipa servers > > On 03/04/2015 04:32 PM, sipazzo wrote: > > Good afternoon, we have a freeipa 3.0.42 installation running on > redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was > originally configured with the built in dogtag certificate CA and > then one of my co-workers added our GoDaddy certificate to the > certificate bundle. My understanding is this cert is used for > communication between the ipa servers as well as the clients are > also configured to trust the GoDaddy certificate. We recently had to > get a new GoDaddy cert so our old one is revoked. I need to figure > out how to either replace the existing revoked cert with the new one > or add the new one to the bundle and then remove the revoked > certificate so as not to break anything. > > Any help is appreciated. I am not strong with certificates so the > more detail you can give the better. > Thank you. > > > You say it was running with the self signed IPA CA and than GoDaddy cert > was added to the bundle. How was it added? > IPA does not use certs for communication between the instances. It uses > Kerberos. I am not sure the DoDaddy cert you added is even used in some > way by IPA. > It seems that your GoDaddy cert is an orthogonal trust so if you > replaced the main key pair then you just need to distribute your new > GoDaddy cert to the clients as you did on the first place. > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > > > > From dpal at redhat.com Wed Mar 11 20:15:41 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 16:15:41 -0400 Subject: [Freeipa-users] Extending IPA to include multiple (say 5) fields for MAC addresses per user In-Reply-To: <1426102883958.97607@vuw.ac.nz> References: <5690D6D3-343E-4F95-A2C1-DCC6E525F27D@gmail.com>, <135C0C3E-F7F6-4C01-88F1-B1FE4ED78FC8@gmail.com> <1426102883958.97607@vuw.ac.nz> Message-ID: <5500A26D.9080707@redhat.com> On 03/11/2015 03:43 PM, Steven Jones wrote: > > Hi, > > > I have been asked to look at packetfence and linking it to IPA for > authentication but I might need to allow users to login into their IPA > info and add MAC addresses themselves, this is possible I think? > > > Since ppl these days can have 3 mobile devices, (ipad, iphone and > laptop) I would need multiple MAC fields so would have to extend IPA's > schema? is this a good idea? > I would treat the devices as hosts rather than extend user schema. But can you explain the use case and what you have in mind. Based on the PF site they support different LDAP servers for authentication so I am not sure any schema change would be needed. > > > > regards > > Steven > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sipazzo at yahoo.com Wed Mar 11 20:35:01 2015 From: sipazzo at yahoo.com (sipazzo) Date: Wed, 11 Mar 2015 20:35:01 +0000 (UTC) Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: <903DF15B7B9D3B4D9137A06F63687859172C8A74CD@FHDP1LUMXC7V33.us.one.verizon.com> References: <903DF15B7B9D3B4D9137A06F63687859172C8A74CD@FHDP1LUMXC7V33.us.one.verizon.com> Message-ID: <965702260.2825462.1426106101246.JavaMail.yahoo@mail.yahoo.com> This is how use the automounter to automatically create home directories for ipa users under /export/home/ and mount them under /home/ on Solaris 10, as well as copy over the profile files and assign appropriate owner and group: We first created a service account called "auth" in ipa to allow ldap lookups with no password expiration On the clients create a "mkhomedir" script in /usr/local/adm (or where ever you like):#!/bin/ksh -p HOMEDIRPATH=/home PHYSICALDIRPATH=/export/home hdir=~$1 phdir="$PHYSICALDIRPATH/$1" if [ -d "$phdir" ]; then ??????? echo "localhost:$phdir" ??????? exit fi mkdir -p $phdir #Perform ldap lookup to get user and group of logged in user GID=`ldapsearch -h idmserver.example.com -D "uid=auth,cn=users,cn=accounts,dc=example,d c=com" -w 'authpassword' -b "cn=users,cn=accounts,dc=example,dc=com" "(uid=$1)" ?| grep gid | cut -d " " -f2` #Copy profile filescp /etc/skel/.bash_profile $phdir/.bash_profile cp /etc/skel/.bashrc $phdir/.bashrc cp /etc/skel/.profile $phdir/.profile cp /etc/skel/.vimrc $phdir/.vimrc #Change the owner and group to logged in user chown -R "$1":"$GID" $phdir echo "localhost:$phdir" ######END######## You need to change permissions on the "mkhomedir" script to 755 Login to client directly as root so you can move home directories around (edit /etc/ssh/sshd_config if needed to allow this) Ensure no one else is logged in Ensure nothing else is mounted in /export/homeCopy home directories to /export/home rsync -av /home/ /export/home/ Add this line to the /etc/auto_master file so the "mkhomedir" script runs at login /home?????????? /usr/local/adm/mkhomedir Remove original /home/ directories rm -rf /home/* Restart autofs so the change takes effect svcadm restart autofs Make sure you change your sshd_config back if you don't wish to allow root ssh access. From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Ben .T.George Sent: Wednesday, March 11, 2015 11:22 AM To: dpal Cc: freeipa-users Subject: Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login ?from BZ ?"While we value your interest in IPA Solaris support, the implementation of the DUA profile is not on our nearest schedule at the moment. We lack both knowledge and resources to focus on integration with Solaris. This is where we need a help (ideally patches) and contribution from the community to help us push these features in.I checked your example DUAConfigProfile and I think it cannot be just added to FreeIPA right away. E.g. for defaultServerList or preferredServerList, you would need to expand installers and ipa-replica-manage to handle these lists and update them when replica is added or updated to prevent it being outdated. printers or aliases serviceSearchDescriptor refers to objects not being available and so on. It is not as straightforward as it seems. ?What I think that we can work on is to work together onhttp://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10... and add all the steps needed to make IPA work on Solaris 10. I could for example prepare an updated page and you could review it. Would that work for you?" ?this what i followed util now. but's not authenticate with AD, IPA user can login on solaris box ? ? ?On Wed, Mar 11, 2015 at 9:11 PM, Dmitri Pal wrote:On 03/11/2015 01:56 PM, Ben .T.George wrote: HI ?yea , i saw that mail thread and he claims that he achieved somehow. but not clear. ?and the ?steps mentioned is too technical for me. :) as i am very new to IPA it's bit confusing.? ?later that thread also closed without proper explanation.? ?i think you guys can contact him to change existing wiki :) as there are many solaris related documents which is pretty old. ?anyway still waiting for rply Have you found the BZ? They are very detailed. https://bugzilla.redhat.com/show_bug.cgi?id=815515 The DUA profile is attached to the bug. ?Regards,Ben ?On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal wrote:On 03/11/2015 01:18 PM, Ben .T.George wrote: HI? ?thanks for the rply. ?even i tried native auto_master file with directory checking script. if i feed the user manually to the script, the directory is creating and while login request comes, it didn't. ?i don't think no one did full solaris integration util now as i asked many questions related to that. ?now i am little bit confident up to this level. and if everything is working fine, i will try to create automated script for IPA join I really do not know Solaris that well. There are some threads from this and last week about Solaris. You can find them in the mail archive for March. There are pointers to wikis and bugzillas in those threads. The bugzilla bugs have some extended info on how to configure Solaris clients. They were pretty detailed. May be they have the automount info you are looking for. ?Regards,Ben ? ? ?On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal wrote:On 03/11/2015 09:50 AM, Ben .T.George wrote: HI ?i can able to reach upto level that IPA user can able to login on solaris box, ?but?how can i create home directories automatically on solaris while IPA user login. ?even i change the shell in IPA web interface that is getting affected. i saw some option in IPA 3.3 web interface like automount and that is not in IPA 4.1.2 All the options are still there. The menus got re-arranged a bit. Hopefully someone with a Solaris knowledge will help you with the rest. ?please anyone tell me where it is and how can i achieve this ?regards,Ben ? -- Thank you,Dmitri Pal ?Sr. Engineering Manager IdM portfolioRed 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 portfolioRed Hat, Inc. ? -- Thank you,Dmitri Pal ?Sr. Engineering Manager IdM portfolioRed Hat, Inc. ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Wed Mar 11 20:37:33 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 11 Mar 2015 20:37:33 +0000 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <5500A064.6090202@redhat.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <1426103220469.42356@vuw.ac.nz>,<5500A064.6090202@redhat.com> Message-ID: <1426106100052.92593@vuw.ac.nz> ====== [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck Checking forwarders, please wait ... WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers Please fix forwarder configuration to enable DNSSEC support. (For BIND 9 add directive "dnssec-enable yes;" to "options {}") WARNING: DNSSEC validation will be disabled ====== The AD server is a win2k12r2. regards Steven ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Thursday, 12 March 2015 9:07 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 On 03/11/2015 03:49 PM, Steven Jones wrote: > Hi, > > When I try to join a 7.1 based replica to an existing setup and use an AD forwarder the command complains that the AD box isnt doing DNSSEC suggesting to me it is present in 7.1? Can you share the message that you get and what steps you take to get to that message? > > At the moment however I cant join a 7.1 based IPA server into a 6.6 based IPA cluster. Or a 7.1 client to IPA, to 6.6 for that matter, 7.0 works fine though. > > > regards > > Steven > > ________________________________________ > From: freeipa-users-bounces at redhat.com on behalf of Erinn Looney-Triggs > Sent: Thursday, 12 March 2015 8:15 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 > > First off congratulations on getting this out. Love the new UI, all pretty and > integrates well with the access.redhat.com UI. > > Second, did DNSSEC not make the chop? It looks like for FreeIPA DNSSEC was > included in the 4.1.0 release, but near as I can tell it is not part of IPA > 4.1.0 in RHEL 7.1. > > Third, there appears to be a behavior change from in ipalib. I cleaned up a > little inventory script for ansible, you can take a look at it here: > https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py > > Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 > worked, now it fails: > > Traceback (most recent call last): > File "./freeipa.py", line 133, in > list_groups(api) > File "./freeipa.py", line 71, in list_groups > result = api.Command.host_find()['result'] > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in > __call__ > ret = self.run(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run > return self.forward(*args, **options) > File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in > forward > return self.Backend.rpcclient.forward(self.name, *args, **kw) > File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, in forward > command = getattr(self.conn, name) > File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in > __get_conn > self.id, threading.currentThread().getName()) > AttributeError: no context.rpcclient in thread 'MainThread' > > Is this expected? Is this a regression? > > Thanks again for your work. > > -Erinn > -- 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 Steven.Jones at vuw.ac.nz Wed Mar 11 20:54:58 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Wed, 11 Mar 2015 20:54:58 +0000 Subject: [Freeipa-users] Extending IPA to include multiple (say 5) fields for MAC addresses per user In-Reply-To: <5500A26D.9080707@redhat.com> References: <5690D6D3-343E-4F95-A2C1-DCC6E525F27D@gmail.com>, <135C0C3E-F7F6-4C01-88F1-B1FE4ED78FC8@gmail.com> <1426102883958.97607@vuw.ac.nz>,<5500A26D.9080707@redhat.com> Message-ID: <1426107145052.37541@vuw.ac.nz> Hi, Hosts however would have to be joined by an admin? They also wouldnt be very IPA aware and stable from what I can see, ie joining a non-RH OS to IPA just looks an awful nightmare especially for 10000+ devices plus with 3 different OSes at least (IOS, Win, Android, linux and apple and windows laptops plus others) and multiple versions and patch levels.....um no, insanity beckons, LOL. I am still trying to figure out what is wanted so I am vague because so are criteria and I have never done this before. All I have is, free, open source, The idea is that an employee can have a zero config access / sign in to wifi for their device once initially connected. The solution must be robust and available ie close to 99.999% availability. IPA can do this as the backend and yes PF can use LDAP hence my interest. Packet fence can be active/passive HA so its possible. Virtualised across multiple ESXi hosts and SANs. I have a RFE in for a IPA howto section to be added to the PF manual as even the openldap section is empty. Or I might try and write it if I get the go ahead myself. The PF servers would be RHEL6.6 so Im hoping adding a service in IPA will "simply" work. regards Steven ________________________________ From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal Sent: Thursday, 12 March 2015 9:15 a.m. To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Extending IPA to include multiple (say 5) fields for MAC addresses per user On 03/11/2015 03:43 PM, Steven Jones wrote: Hi, I have been asked to look at packetfence and linking it to IPA for authentication but I might need to allow users to login into their IPA info and add MAC addresses themselves, this is possible I think? Since ppl these days can have 3 mobile devices, (ipad, iphone and laptop) I would need multiple MAC fields so would have to extend IPA's schema? is this a good idea? I would treat the devices as hosts rather than extend user schema. But can you explain the use case and what you have in mind. Based on the PF site they support different LDAP servers for authentication so I am not sure any schema change would be needed. regards Steven -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sipazzo at yahoo.com Wed Mar 11 21:49:28 2015 From: sipazzo at yahoo.com (sipazzo) Date: Wed, 11 Mar 2015 21:49:28 +0000 (UTC) Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <903DF15B7B9D3B4D9137A06F63687859172C8A7535@FHDP1LUMXC7V33.us.one.verizon.com> References: <903DF15B7B9D3B4D9137A06F63687859172C8A7535@FHDP1LUMXC7V33.us.one.verizon.com> Message-ID: <1850196245.2880833.1426110568968.JavaMail.yahoo@mail.yahoo.com> Thanks Rob, I apologize that error was probably not helpful. This is what I see when running install in debug mode: Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa2-corp.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA server Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is not recognized. The certificates are very confusing to me. I don't understand how things are working when we have a set of GoDaddy certs in slapd-NETWORKFLEET-COM and a set of the Dogtag certs in slapd-PKI-CA. The cert in /usr/share/ipa/html/ca.crt looks like the original one issued by the Dogtag cert system and matches the ones on the clients. Not to further confuse things but the original master server that signed all these certs was taken offline months ago due to some issues it was having. I do still have access to it if necessary. As far as why the godaddy certs were swapped out for the Dogtag certs it was originally for something as simple as the untrusted certificate dialogue when accessing the ipa gui. I did not swap out the certs so am unsure of exactly what happened. There is no real need to use the GoDaddy certs as far as I am concerned. I just want the best solution to the issues I am seeing as I am in kind of a bind with the GoDaddy cert being revoked and needing to be replaced and the master Dogtag certificate server offline. We have a mixed environment with Rhel 5, 6 and Solaris clients so are not using sssd in all cases. I know this is asking a lot but appreciate any help you can give. Thank you. -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden Sent: Wednesday, March 11, 2015 1:14 PM To: sipazzo; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Need to replace cert for ipa servers sipazzo wrote: >? >? > > > * > * > This issue has now gotten much worse and we are unable to enroll > clients. We are getting an error saying the server does not have a cert: > > Do you want download the CA cert from > http://ipa1.example.com/ipa/config/ca.crt ? > (this is INSECURE) [no]: yes > Cannot obtain CA certificate > 'http://ipa1.example.com/ipa/config/ca.crt' doesn't have a > certificate.j I don't see how this is at all related, or new. The CA cert exists in the filesystem in /usr/share/ipa/html/ca.crt. It wouldn't be affected by expiring certificates. > Can we somehow replace our certs and revert back to the original one's > issue by the dogtag server so we have a standard configuration or is > there a clean way to fix this issue? You swapped out for the GoDaddy cert for a reason. I'd start there. Do you need to retain that cert or is it acceptable to try to revert back to IPA server certs? Note that going back could affect clients enrolled using the GoDaddy cert depending on how your machines are configured (if using SSSD then not likely a problem). As Dmitri said we mostly use Kerberos to communicate. rob > > Thank you > > > > I was told the GoDaddy certs were just imported using certutil -a but > in looking at the certs the original certs were actually replaced. > This is only in /etc/dirsrv/slapd-REALM-COM: >? > Certificate Nickname? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust > Attributes >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > SSL,S/MIME,JAR/XPI >? > GD_CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,C > NWF_GD? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u >? >? > The certs in /etc/dirsrv/slapd-PKI-CA are still the originals: >? > [root at ipa2-corp ~]# certutil -L -d /etc/dirsrv/slapd-PKI-IPA/ >? > Certificate Nickname? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? Trust > Attributes >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? > SSL,S/MIME,JAR/XPI >? > IPADOMAIN.COM IPA CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C, > Server-Cert? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? u,u,u >? >? I am not even sure how this even works or if it can be fixed? > Should/Can we go back to using the original dogtag certs? > ---------------------------------------------------------------------- > -- >? > *From:*freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Dmitri Pal > *Sent:* Wednesday, March 04, 2015 2:57 PM > *To:* freeipa-users at redhat.com > *Subject:* Re: [Freeipa-users] Need to replace cert for ipa servers >? > On 03/04/2015 04:32 PM, sipazzo wrote: > >? ? Good afternoon, we have a freeipa 3.0.42 installation running on >? ? redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was >? ? originally configured with the built in dogtag certificate CA and >? ? then one of my co-workers added our GoDaddy certificate to the >? ? certificate bundle. My understanding is this cert is used for >? ? communication between the ipa servers as well as the clients are >? ? also configured to trust the GoDaddy certificate. We recently had to >? ? get a new GoDaddy cert so our old one is revoked. I need to figure >? ? out how to either replace the existing revoked cert with the new one >? ? or add the new one to the bundle and then remove the revoked >? ? certificate so as not to break anything. >? ? ? >? ? Any help is appreciated. I am not strong with certificates so the >? ? more detail you can give the better. >? ? Thank you. >? ? ? > > You say it was running with the self signed IPA CA and than GoDaddy > cert was added to the bundle. How was it added? > IPA does not use certs for communication between the instances. It > uses Kerberos. I am not sure the DoDaddy cert you added is even used > in some way by IPA. > It seems that your GoDaddy cert is an orthogonal trust so if you > replaced the main key pair then you just need to distribute your new > GoDaddy cert to the clients as you did on the first place. > > > -- > > 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 dpal at redhat.com Wed Mar 11 23:17:15 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 11 Mar 2015 19:17:15 -0400 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <1426106100052.92593@vuw.ac.nz> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <1426103220469.42356@vuw.ac.nz>, <5500A064.6090202@redhat.com> <1426106100052.92593@vuw.ac.nz> Message-ID: <5500CCFB.5030602@redhat.com> On 03/11/2015 04:37 PM, Steven Jones wrote: > ====== > [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck > Checking forwarders, please wait ... > WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers > Please fix forwarder configuration to enable DNSSEC support. > (For BIND 9 add directive "dnssec-enable yes;" to "options {}") > WARNING: DNSSEC validation will be disabled > ====== > > The AD server is a win2k12r2. Thanks, I will follow up. > regards > > Steven > ________________________________________ > From: freeipa-users-bounces at redhat.com on behalf of Dmitri Pal > Sent: Thursday, 12 March 2015 9:07 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 > > On 03/11/2015 03:49 PM, Steven Jones wrote: >> Hi, >> >> When I try to join a 7.1 based replica to an existing setup and use an AD forwarder the command complains that the AD box isnt doing DNSSEC suggesting to me it is present in 7.1? > Can you share the message that you get and what steps you take to get to > that message? > >> At the moment however I cant join a 7.1 based IPA server into a 6.6 based IPA cluster. Or a 7.1 client to IPA, to 6.6 for that matter, 7.0 works fine though. >> >> >> regards >> >> Steven >> >> ________________________________________ >> From: freeipa-users-bounces at redhat.com on behalf of Erinn Looney-Triggs >> Sent: Thursday, 12 March 2015 8:15 a.m. >> To: freeipa-users at redhat.com >> Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 >> >> First off congratulations on getting this out. Love the new UI, all pretty and >> integrates well with the access.redhat.com UI. >> >> Second, did DNSSEC not make the chop? It looks like for FreeIPA DNSSEC was >> included in the 4.1.0 release, but near as I can tell it is not part of IPA >> 4.1.0 in RHEL 7.1. >> >> Third, there appears to be a behavior change from in ipalib. I cleaned up a >> little inventory script for ansible, you can take a look at it here: >> https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py >> >> Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 >> worked, now it fails: >> >> Traceback (most recent call last): >> File "./freeipa.py", line 133, in >> list_groups(api) >> File "./freeipa.py", line 71, in list_groups >> result = api.Command.host_find()['result'] >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in >> __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run >> return self.forward(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in >> forward >> return self.Backend.rpcclient.forward(self.name, *args, **kw) >> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, in forward >> command = getattr(self.conn, name) >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in >> __get_conn >> self.id, threading.currentThread().getName()) >> AttributeError: no context.rpcclient in thread 'MainThread' >> >> Is this expected? Is this a regression? >> >> Thanks again for your work. >> >> -Erinn >> > > -- > 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 edewata at redhat.com Thu Mar 12 01:55:51 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Thu, 12 Mar 2015 08:55:51 +0700 Subject: [Freeipa-users] ipa-server setup with external CA fails In-Reply-To: References: Message-ID: <5500F227.3060601@redhat.com> On 3/11/2015 10:13 PM, Gould, Joshua wrote: > The selftests.log contradicts itself and I?m not really sure where to look > next. Any ideas? There's an existing ticket about the confusing selftest messages: https://fedorahosted.org/pki/ticket/1249 Could you post the full CA debug log (i.e. /var/log/pki/pki-tomcat/ca/debug)? The error might have happened much earlier. Thanks. -- Endi S. Dewata From rcritten at redhat.com Thu Mar 12 02:20:09 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 11 Mar 2015 22:20:09 -0400 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <1850196245.2880833.1426110568968.JavaMail.yahoo@mail.yahoo.com> References: <903DF15B7B9D3B4D9137A06F63687859172C8A7535@FHDP1LUMXC7V33.us.one.verizon.com> <1850196245.2880833.1426110568968.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5500F7D9.30705@redhat.com> sipazzo wrote: > Thanks Rob, I apologize that error was probably not helpful. This is > what I see when running install in debug mode: > > Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an IPA > server > Init LDAP connection with: ldap://ipa2-corp.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is > not recognized. > Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA server > Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is > not recognized. > Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA server > Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is > not recognized. > Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA server > Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is > not recognized. > Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA server > Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer is > not recognized. > > The certificates are very confusing to me. I don't understand how things > are working when we have a set of GoDaddy certs in > slapd-NETWORKFLEET-COM and a set of the Dogtag certs in slapd-PKI-CA. > The cert in /usr/share/ipa/html/ca.crt looks like the original one > issued by the Dogtag cert system and matches the ones on the clients. > Not to further confuse things but the original master server that signed > all these certs was taken offline months ago due to some issues it was > having. I do still have access to it if necessary. > > As far as why the godaddy certs were swapped out for the Dogtag certs it > was originally for something as simple as the untrusted certificate > dialogue when accessing the ipa gui. I did not swap out the certs so am > unsure of exactly what happened. There is no real need to use the > GoDaddy certs as far as I am concerned. I just want the best solution to > the issues I am seeing as I am in kind of a bind with the GoDaddy cert > being revoked and needing to be replaced and the master Dogtag > certificate server offline. We have a mixed environment with Rhel 5, 6 > and Solaris clients so are not using sssd in all cases. > > I know this is asking a lot but appreciate any help you can give. What is the current state of things? Does your IPA Apache server work? Is 389-ds up and running? Do you have a working IPA CA? Does ipa cert-show 1 work? If the answer is yes to all then we should be able to generate new certs for all the services. rob From jcholast at redhat.com Thu Mar 12 06:14:40 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 12 Mar 2015 07:14:40 +0100 Subject: [Freeipa-users] ipa-server setup with external CA fails In-Reply-To: <5500A142.3020503@redhat.com> References: <55006FDB.2000903@redhat.com> <5500A142.3020503@redhat.com> Message-ID: <55012ED0.2090105@redhat.com> Dne 11.3.2015 v 21:10 Martin Kosek napsal(a): > On 03/11/2015 06:33 PM, Gould, Joshua wrote: >> We?re trying to setup RHEL7 with the latest updates. Our ipa-server shows >> ipa-server-4.1.0-18.el7.x86_64. >> >> On 3/11/15, 12:39 PM, "Dmitri Pal" wrote: >> >>> On 03/11/2015 11:13 AM, Gould, Joshua wrote: >>>> We?re trying to setup IPA with it acting as an intermediate CA against >>>> our >>>> test Active Directory environment. >>>> >>>> The first part goes well: >>>> >>>> # ipa-server-install -a admin-pass ?hostname=server.domain.com -n >>>> unix.test.osuwmc -p password -P password -r UNIX.TEST.OSUWMC >>>> --external-ca ?external-ca-type=ms?cs >>>> >>>> We send our CSR off to our AD admin and he signs it on gives us the >>>> cert. >>>> We go to import the cert with: >>>> >>>> # ipa-server-install --external-cert-file=/root/ipa.crt >>>> >>>> It blows up when trying to create the RA cert. >>>> >>>> 2015-03-10T21:17:55Z DEBUG Process finished, return code=0 >>>> 2015-03-10T21:17:55Z DEBUG stdout= >>>> Certificate request generated by Netscape certutil >>>> Phone: (not specified) >>>> Common Name: IPA RA >>>> Email: (not specified) >>>> Organization: UNIX.TEST.OSUWMC >>>> State: (not specified) >>>> Country: (not specified) >>>> -----BEGIN NEW CERTIFICATE REQUEST----- >>>> MIICcTCCAVkCAQAwLDEZMBcGA1UEChMQVU5JWC5URVNULk9TVVdNQzEPMA0GA1UE >>>> AxMGSVBBIFJBMIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEA0DavkHxe >>>> PoY8q6UWCAHKWOCCv8PvU7J5scsmdLfjSyN8rIgq8pGoICAqawm9lZntD8G/7sJQ >>>> H2bNDe08DooGbdTLHB2j3JViUUlQn2YlWw7IXm6mgwxStGLSS/G+CnyVPdGWV48X >>>> GHb7GLLNYD8nhpzNzqVGsVMTyV/dqD7y8srbpPjmAqH+VjKLDSmr3pgV2IvOUEpW >>>> wePYJW7h4FBQtwQpPgo30oXMqXa/ob8RJ4NQ74Uv6irq9G2IXNpKhAbHB1YZ+DGm >>>> FJFlURdxey0FUbDn1WqMeVLa6SMURZI1zncMxB6bwgax/2VdYVeYHiVU9GgGmw0F >>>> VgUjgpg0RMCaSQIDAQABoAAwDQYJKoZIhvcNAQEFBQADggEBAI1YCN5oS2o5+fky >>>> jTNCeWFq+oEyHcuPtGzBAA5HMNEsoFvIY0sut+lf7Upw/ZHvV/F09DPwT+Xrm8yp >>>> D0e6F6HawEV+NvKYk2kmpK9xxyOi0raBz1WuvlmqwGhiTOxpk+nIW5wiNhiOJmzd >>>> xLojqGnkP5tBuYtHXUFqps7KDknsk5VxoAGe3/ZvsDvqlYXF93V+/nXv90X2yEKH >>>> +wLUCDtS5WRWtnxTs1bWsMjBsTyDcv8XBdWqDO/4DVLs9HjHijfsUtUqg8bR5dU1 >>>> kVM+yLXVogJPBMN79SJQ1un8IWNMHCallsX3urNbXxYuSlqsh6UCdRLXFW44jJIK >>>> xAmXvOg= >>>> -----END NEW CERTIFICATE REQUEST----- >>>> 2015-03-10T21:17:55Z DEBUG stderr= >>>> Generating key. This may take a few moments... >>>> 2015-03-10T21:17:55Z 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/cainstance.py", >>>> line >>>> 1149, in __request_ra_certificate >>>> self.requestId = item_node[0].childNodes[0].data >>>> IndexError: list index out of range >>>> 2015-03-10T21:17:55Z DEBUG [error] IndexError: list index out of >>>> range >>>> 2015-03-10T21:17:55Z DEBUG File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", >>>> line 646, in run_script >>>> return_value = main_function() >>>> File "/sbin/ipa-server-install", line 1170, in main >>>> ca_signing_algorithm=options.ca_signing_algorithm) >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", >>>> line >>>> 520, in configure_instance >>>> self.start_creation(runtime=210) >>>> 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/cainstance.py", >>>> line >>>> 1149, in __request_ra_certificate >>>> self.requestId = item_node[0].childNodes[0].data >>>> 2015-03-10T21:17:55Z DEBUG The ipa-server-install command failed, >>>> exception: IndexError: list index out of range >>>> >>>> >>>> I?ve looked at the debug log. I believe this is the part that?s most >>>> helpful. >>>> >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: >>>> SelfTestSubsystem::runSelfTestsAtStartup(): ENTERING . . . >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: >>>> SelfTestSubsystem::runSelfTestsAtStartup(): running "CAPresence" >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: >>>> SelfTestSubsystem::runSelfTestsAtStartup(): running >>>> "SystemCertsVerification" >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCerts() cert tag=signing >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname(): calling isCertValid() >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname() failed:caSigningCert cert-pki-ca >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>>> create() >>>> >>>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>>> >>>> ai >>>> lure][CertNickName=caSigningCert cert-pki-ca] CIMC certificate >>>> verification >>>> >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCerts() cert tag=ocsp_signing >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname(): calling isCertValid() >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname() failed:ocspSigningCert cert-pki-ca >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>>> create() >>>> >>>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>>> >>>> ai >>>> lure][CertNickName=ocspSigningCert cert-pki-ca] CIMC certificate >>>> verification >>>> >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCerts() cert tag=sslserver >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname(): calling isCertValid() >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname() failed:Server-Cert cert-pki-ca >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>>> create() >>>> >>>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>>> >>>> ai >>>> lure][CertNickName=Server-Cert cert-pki-ca] CIMC certificate >>>> verification >>>> >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCerts() cert tag=subsystem >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname(): calling isCertValid() >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname() failed:subsystemCert cert-pki-ca >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>>> create() >>>> >>>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=F >>>> >>>> ai >>>> lure][CertNickName=subsystemCert cert-pki-ca] CIMC certificate >>>> verification >>>> >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCerts() cert tag=audit_signing >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname(): calling isCertValid() >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: CertUtils: >>>> verifySystemCertByNickname() passed:auditSigningCert cert-pki-ca >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>>> create() >>>> >>>> message=[AuditEvent=CIMC_CERT_VERIFICATION][SubjectID=$System$][Outcome=S >>>> >>>> uc >>>> cess][CertNickName=auditSigningCert cert-pki-ca] CIMC certificate >>>> verification >>>> >>>> [10/Mar/2015:17:17:24][localhost-startStop-1]: SignedAuditEventFactory: >>>> create() >>>> >>>> message=[AuditEvent=SELFTESTS_EXECUTION][SubjectID=$System$][Outcome=Fail >>>> >>>> ur >>>> e] self tests execution (see selftests.log for details) >>>> >>>> The selftests.log contradicts itself and I?m not really sure where to >>>> look >>>> next. Any ideas? >>>> >>>> >>>> Joshua >>>> >>>> >>>> >>> Which version is it? >>> A similar problem have been seen with the early IPA 3.3 version and was >>> related to the format of the cert file returned by AD. AFAIR it contains >>> more certs that we expected. >>> Something along those lines. > > I am CCing Jan Cholasta who was fixing very similar error in IPA 3.3.3 > in RHEL-7.0 (should have been fixed in RHEL-7.1), he should have more > context. > > I am also CCing Endi from Dogtag team, he may also have some idea from > PKI side. > > HTH, > Martin I would like to see /root/ipa.crt and /etc/pki/pki-tomcat/ca/CS.cfg. Without them, I can't really tell what's wrong. -- Jan Cholasta From mkosek at redhat.com Thu Mar 12 07:25:11 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Mar 2015 08:25:11 +0100 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <5500A005.5010500@redhat.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <5500A005.5010500@redhat.com> Message-ID: <55013F57.4060003@redhat.com> On 03/11/2015 09:05 PM, Dmitri Pal wrote: > On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: ... >> Third, there appears to be a behavior change from in ipalib. I cleaned up a >> little inventory script for ansible, you can take a look at it here: >> https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py >> >> Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 >> worked, now it fails: >> >> Traceback (most recent call last): >> File "./freeipa.py", line 133, in >> list_groups(api) >> File "./freeipa.py", line 71, in list_groups >> result = api.Command.host_find()['result'] >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in >> __call__ >> ret = self.run(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run >> return self.forward(*args, **options) >> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in >> forward >> return self.Backend.rpcclient.forward(self.name, *args, **kw) >> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, in forward >> command = getattr(self.conn, name) >> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in >> __get_conn >> self.id, threading.currentThread().getName()) >> AttributeError: no context.rpcclient in thread 'MainThread' >> >> Is this expected? Is this a regression? > > Some things changed. I would leave for developers to take a look and provide > more guidance. Erinn, it may help us if you share the whole sequence how you bootstrap and authenticatoin the API. Honza, was there any related change causing ^^^? From mkosek at redhat.com Thu Mar 12 07:30:22 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Mar 2015 08:30:22 +0100 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <5500CCFB.5030602@redhat.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <1426103220469.42356@vuw.ac.nz>, <5500A064.6090202@redhat.com> <1426106100052.92593@vuw.ac.nz> <5500CCFB.5030602@redhat.com> Message-ID: <5501408E.60900@redhat.com> On 03/12/2015 12:17 AM, Dmitri Pal wrote: > On 03/11/2015 04:37 PM, Steven Jones wrote: >> ====== >> [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns >> --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg >> --skip-conncheck >> Checking forwarders, please wait ... >> WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers >> Please fix forwarder configuration to enable DNSSEC support. >> (For BIND 9 add directive "dnssec-enable yes;" to "options {}") >> WARNING: DNSSEC validation will be disabled >> ====== >> >> The AD server is a win2k12r2. > > Thanks, I will follow up. As Dmitri said, all automatic DNSSEC key handling did not make the cut in RHEL-7.1. If you want to test DNSSEC, you are very welcome, but you would be left with manual configuration as described in upstream article: http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support We, however, still left this error message to make users and customers aware that their name server is not ready even for manual DNSSEC. However, I did a short research, and win2k12r2 should already support DNSSEC. Maybe the support needs to be enabled. What DNS server do you have in /etc/resolv.conf? IPA DNS server + configured DNS forward zone or do you have there AD IP address directly? Martin Basti (CCed) recently found an issue with this check and DNS forwarders IIRC. From jcholast at redhat.com Thu Mar 12 08:10:24 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Thu, 12 Mar 2015 09:10:24 +0100 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <55013F57.4060003@redhat.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <5500A005.5010500@redhat.com> <55013F57.4060003@redhat.com> Message-ID: <550149F0.9030305@redhat.com> Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): > On 03/11/2015 09:05 PM, Dmitri Pal wrote: >> On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: > ... >>> Third, there appears to be a behavior change from in ipalib. I cleaned up a >>> little inventory script for ansible, you can take a look at it here: >>> https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py >>> >>> Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] on line 30 >>> worked, now it fails: >>> >>> Traceback (most recent call last): >>> File "./freeipa.py", line 133, in >>> list_groups(api) >>> File "./freeipa.py", line 71, in list_groups >>> result = api.Command.host_find()['result'] >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in >>> __call__ >>> ret = self.run(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 755, in run >>> return self.forward(*args, **options) >>> File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 776, in >>> forward >>> return self.Backend.rpcclient.forward(self.name, *args, **kw) >>> File "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, in forward >>> command = getattr(self.conn, name) >>> File "/usr/lib/python2.7/site-packages/ipalib/backend.py", line 97, in >>> __get_conn >>> self.id, threading.currentThread().getName()) >>> AttributeError: no context.rpcclient in thread 'MainThread' >>> >>> Is this expected? Is this a regression? >> >> Some things changed. I would leave for developers to take a look and provide >> more guidance. > > Erinn, it may help us if you share the whole sequence how you bootstrap and > authenticatoin the API. Honza, was there any related change causing ^^^? > https://fedorahosted.org/freeipa/ticket/3299 There is api.Backend.xmlclient.connect() in the code, but JSON-RPC is now used by default. This can be fixed by calling api.Backend.rpcclient.connect() instead. -- Jan Cholasta From bentech4you at gmail.com Thu Mar 12 08:10:05 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Thu, 12 Mar 2015 11:10:05 +0300 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: <965702260.2825462.1426106101246.JavaMail.yahoo@mail.yahoo.com> References: <903DF15B7B9D3B4D9137A06F63687859172C8A74CD@FHDP1LUMXC7V33.us.one.verizon.com> <965702260.2825462.1426106101246.JavaMail.yahoo@mail.yahoo.com> Message-ID: HI i tried both method and still it's not creating the home directories regards, Ben On Wed, Mar 11, 2015 at 11:35 PM, sipazzo wrote: > This is how use the automounter to automatically create home directories > for ipa users under /export/home/ and mount them under /home/ on Solaris > 10, as well as copy over the profile files and assign appropriate owner and > group: > > We first created a service account called "auth" in ipa to allow ldap > lookups with no password expiration > > On the clients create a "mkhomedir" script in /usr/local/adm (or where > ever you like): > #!/bin/ksh -p > > HOMEDIRPATH=/home > > PHYSICALDIRPATH=/export/home > > hdir=~$1 > > phdir="$PHYSICALDIRPATH/$1" > > if [ -d "$phdir" ]; then > echo "localhost:$phdir" > exit > fi > > mkdir -p $phdir > > #Perform ldap lookup to get user and group of logged in user > GID=`ldapsearch -h idmserver.example.com -D > "uid=auth,cn=users,cn=accounts,dc=example,d > c=com" -w 'authpassword' -b "cn=users,cn=accounts,dc=example,dc=com" > "(uid=$1)" > | grep gid | cut -d " " -f2` > > #Copy profile files > cp /etc/skel/.bash_profile $phdir/.bash_profile > cp /etc/skel/.bashrc $phdir/.bashrc > cp /etc/skel/.profile $phdir/.profile > cp /etc/skel/.vimrc $phdir/.vimrc > > #Change the owner and group to logged in user > chown -R "$1":"$GID" $phdir > > echo "localhost:$phdir" > > ######END######## > > You need to change permissions on the "mkhomedir" script to 755 > > > Login to client directly as root so you can move home directories around > (edit /etc/ssh/sshd_config if needed to allow this) > > Ensure no one else is logged in > Ensure nothing else is mounted in /export/home > Copy home directories to /export/home > rsync -av /home/ /export/home/ > > Add this line to the /etc/auto_master file so the "mkhomedir" script runs > at login > /home /usr/local/adm/mkhomedir > > Remove original /home/ directories > rm -rf /home/* > > Restart autofs so the change takes effect > svcadm restart autofs > > Make sure you change your sshd_config back if you don't wish to allow root > ssh access. > ------------------------------ > *From:* freeipa-users-bounces at redhat.com [mailto: > freeipa-users-bounces at redhat.com] *On Behalf Of *Ben .T.George > *Sent:* Wednesday, March 11, 2015 11:22 AM > *To:* dpal > *Cc:* freeipa-users > *Subject:* Re: [Freeipa-users] how can i create home directories > automatically on solaris while IPA user login > > from BZ > > "While we value your interest in IPA Solaris support, the implementation > of the DUA profile is not on our nearest schedule at the moment. We lack > both knowledge and resources to focus on integration with Solaris. This is > where we need a help (ideally patches) and contribution from the community > to help us push these features in. > > I checked your example DUAConfigProfile and I think it cannot be just added to FreeIPA right away. E.g. for defaultServerList or preferredServerList, you would need to expand installers and ipa-replica-manage to handle these lists and update them when replica is added or updated to prevent it being outdated. printers or aliases serviceSearchDescriptor refers to objects not being available and so on. It is not as straightforward as it seems. > > > > What I think that we can work on is to work together on > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 > > ... and add all the steps needed to make IPA work on Solaris 10. I could for example prepare an updated page and you could review it. Would that work for you?" > > > > this what i followed util now. but's not authenticate with AD, IPA user can login on solaris box > > > > > > > On Wed, Mar 11, 2015 at 9:11 PM, Dmitri Pal wrote: > On 03/11/2015 01:56 PM, Ben .T.George wrote: > > HI > > yea , i saw that mail thread and he claims that he achieved somehow. but > not clear. > > and the steps mentioned is too technical for me. :) as i am very new to > IPA it's bit confusing. > > later that thread also closed without proper explanation. > > i think you guys can contact him to change existing wiki :) as there are > many solaris related documents which is pretty old. > > anyway still waiting for rply > > > Have you found the BZ? They are very detailed. > https://bugzilla.redhat.com/show_bug.cgi?id=815515 > The DUA profile is attached to the bug. > > > > > Regards, > Ben > > On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal wrote: > On 03/11/2015 01:18 PM, Ben .T.George wrote: > > HI > > thanks for the rply. > > even i tried native auto_master file with directory checking script. if i > feed the user manually to the script, the directory is creating and while > login request comes, it didn't. > > i don't think no one did full solaris integration util now as i asked many > questions related to that. > > now i am little bit confident up to this level. and if everything is > working fine, i will try to create automated script for IPA join > > > I really do not know Solaris that well. There are some threads from this > and last week about Solaris. You can find them in the mail archive for > March. > There are pointers to wikis and bugzillas in those threads. The bugzilla > bugs have some extended info on how to configure Solaris clients. They were > pretty detailed. May be they have the automount info you are looking for. > > > > > Regards, > Ben > > > > On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal wrote: > On 03/11/2015 09:50 AM, Ben .T.George wrote: > > HI > > i can able to reach upto level that IPA user can able to login on solaris > box, > > but how can i create home directories automatically on solaris while IPA > user login. > > even i change the shell in IPA web interface that is getting affected. i > saw some option in IPA 3.3 web interface like automount and that is not in > IPA 4.1.2 > > > All the options are still there. The menus got re-arranged a bit. > Hopefully someone with a Solaris knowledge will help you with the rest. > > > > please anyone tell me where it is and how can i achieve this > > regards, > Ben > > > > > -- > > 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. > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Mar 12 08:10:39 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Mar 2015 09:10:39 +0100 Subject: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. In-Reply-To: <1425945372163.97047@vuw.ac.nz> References: <1425936805454.63030@vuw.ac.nz>, <54FE1876.5060509@redhat.com> <1425945372163.97047@vuw.ac.nz> Message-ID: <550149FF.3060201@redhat.com> I think you should now check dirsrv errors logs on both server and the replica. It should have more info what went wrong with starting the replication. Please also check # systemctl status dirsrv at YOUR-REALM.service to check there are no SASL buffer related error messages. On 03/10/2015 12:58 AM, Steven Jones wrote: > ====== > 2015-03-09T21:15:31Z DEBUG flushing ldap://vuwunicoipam002.ods.vuw.ac.nz:389 from SchemaCache > 2015-03-09T21:15:31Z DEBUG retrieving schema for SchemaCache url=ldap://vuwunicoipam002.ods.vuw.ac.nz:389 conn= > 2015-03-09T21:15:31Z DEBUG flushing ldaps://vuwunicoipam004.ods.vuw.ac.nz:636 from SchemaCache > 2015-03-09T21:15:31Z DEBUG retrieving schema for SchemaCache url=ldaps://vuwunicoipam004.ods.vuw.ac.nz:636 conn= > 2015-03-09T21:17: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 969, in setup_replication > raise RuntimeError("Failed to start replication") > RuntimeError: Failed to start replication > > 2015-03-09T21:17:42Z DEBUG [error] RuntimeError: Failed to start replication > 2015-03-09T21:17:42Z 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 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 969, in setup_replication > raise RuntimeError("Failed to start replication") > > 2015-03-09T21:17:42Z DEBUG The ipa-replica-install command failed, exception: RuntimeError: Failed to start replication > > ========== > > > replica log. > > > ? > > > regards > > Steven > > ________________________________ > From: freeipa-users-bounces at redhat.com on behalf of Rich Megginson > Sent: Tuesday, 10 March 2015 11:02 a.m. > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Error in replication while inserting a RHEL7.1 server into a RHEL6.6 IPA setup. > > On 03/09/2015 03:35 PM, Steven Jones wrote: > > Any idea what is going on here please? > > > ========== > > [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg --skip-conncheck > Checking forwarders, please wait ... > WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers > Please fix forwarder configuration to enable DNSSEC support. > (For BIND 9 add directive "dnssec-enable yes;" to "options {}") > WARNING: DNSSEC validation will be disabled > > I don't know if this is a problem, so I will leave it to our DNS gurus to answer. > > > Directory Manager (existing master) password: > > Adding [10.100.32.50 vuwunicoipam004.ods.vuw.ac.nz] to your /etc/hosts file > Using reverse zone(s) 32.100.10.in-addr.arpa. > Configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv): Estimated time 1 minute > [1/35]: creating directory server user > [2/35]: creating directory server instance > [3/35]: adding default schema > [4/35]: enabling memberof plugin > [5/35]: enabling winsync plugin > [6/35]: configuring replication version plugin > [7/35]: enabling IPA enrollment plugin > [8/35]: enabling ldapi > [9/35]: configuring uniqueness plugin > [10/35]: configuring uuid plugin > [11/35]: configuring modrdn plugin > [12/35]: configuring DNS plugin > [13/35]: enabling entryUSN plugin > [14/35]: configuring lockout plugin > [15/35]: creating indices > [16/35]: enabling referential integrity plugin > [17/35]: configuring ssl for ds instance > [18/35]: configuring certmap.conf > [19/35]: configure autobind for root > [20/35]: configure new location for managed entries > [21/35]: configure dirsrv ccache > [22/35]: enable SASL mapping fallback > [23/35]: restarting directory server > [24/35]: setting up initial replication > Starting replication, please wait until this has completed. > Update in progress, 128 seconds elapsed > [vuwunicoipam002.ods.vuw.ac.nz] reports: Update failed! Status: [10 Total update abortedLDAP error: Referral] > > If the client got back a referral, it means the replica was being re-initialized at this time. Sounds like either the client is not checking to see if the initialization is complete, or the server is reporting back erroneously that initialization is complete. > > > > [error] RuntimeError: Failed to start replication > > Your system may be partly configured. > Run /usr/sbin/ipa-server-install --uninstall to clean up. > > Failed to start replication > [root at vuwunicoipam004 ipa-certs]# > ======== > > > No firewalls are active and the network is a simple vyos virtual router. > > > ===== > > [root at vuwunicoipam002 etc]# iptables -L -n > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > [root at vuwunicoipam002 etc]# > ===== > > ===== > > > Chain INPUT (policy ACCEPT) > target prot opt source destination > > Chain FORWARD (policy ACCEPT) > target prot opt source destination > > Chain OUTPUT (policy ACCEPT) > target prot opt source destination > [root at vuwunicoipam004 ipa-certs]# > ===== > > > > > > regards > Steven > > > > > > From mkosek at redhat.com Thu Mar 12 09:03:00 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Mar 2015 10:03:00 +0100 Subject: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1) In-Reply-To: <20150310140626.GN25455@redhat.com> References: <54FEEE44.8000207@opennms.org> <20150310133150.GM25455@redhat.com> <54FEF59A.7040109@opennms.org> <20150310140626.GN25455@redhat.com> Message-ID: <55015644.5090800@redhat.com> On 03/10/2015 03:06 PM, Alexander Bokovoy wrote: > On Tue, 10 Mar 2015, Benjamin Reed wrote: >> On 3/10/15 9:31 AM, Alexander Bokovoy wrote: >>> Are you following these instructions? >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html >>> >> >> >> Aha! No. There are so many false positives in google I had no idea >> that document existed. Pretty much everything I've found that links to >> "how to migrate" takes me to this: >> >> http://www.freeipa.org/page/Howto/Migration#Migrating_to_different_platform_or_OS >> >> >> ...which in turn pointed to this: >> >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Setting_up_IPA_Replicas.html >> >> >> I didn't see anything about RHEL6->RHEL7 or FreeIPA 3.0->3.3 >> http://www.freeipa.org/page/Documentation unless I missed it. The 3.3 >> section on there is pretty much just a collection of things about new >> features. (And a presentation deck that points to that first link above...) > We have http://www.freeipa.org/page/Documentation#User_Guides and going > through user guide would be our recommended action. There is a whole > chapter 6 in RHEL7 docs for upgrades and migration. Hmm, I looked in FreeIPA.org and saw that about a dozen of pages still pointed to the old, abandoned (http://www.freeipa.org/page/Upstream_User_Guide) Fedora guides. I went through the pages and changed them all to point to the most up to date user guide - RHEL-7 guide. I also added a link to the RHEL-7 migration guide to the FreeIPA.org migration page, for additional information: http://www.freeipa.org/page/Howto/Migration#Migrating_Identity_Management_in_RHEL.2FCentOS If you know about more sources like that, please tell me or update the page. Thanks, Martin From leszek.mis at gmail.com Thu Mar 12 09:37:22 2015 From: leszek.mis at gmail.com (crony) Date: Thu, 12 Mar 2015 10:37:22 +0100 Subject: [Freeipa-users] Adding external CA Message-ID: Hi FreeIPA Users, I have a fresh new FreeIPA 4.1 on RHEL7.1 with self-sign CA and I would like to change the self-sign CA to the external CA Do you have any step by step document for do it correctly on 4.1 version? /lm -------------- next part -------------- An HTML attachment was scrubbed... URL: From mbasti at redhat.com Thu Mar 12 11:02:58 2015 From: mbasti at redhat.com (Martin Basti) Date: Thu, 12 Mar 2015 12:02:58 +0100 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <5501408E.60900@redhat.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <1426103220469.42356@vuw.ac.nz>, <5500A064.6090202@redhat.com> <1426106100052.92593@vuw.ac.nz> <5500CCFB.5030602@redhat.com> <5501408E.60900@redhat.com> Message-ID: <55017262.7080202@redhat.com> On 12/03/15 08:30, Martin Kosek wrote: > On 03/12/2015 12:17 AM, Dmitri Pal wrote: >> On 03/11/2015 04:37 PM, Steven Jones wrote: >>> ====== >>> [root at vuwunicoipam004 ipa-certs]# ipa-replica-install --setup-dns >>> --forwarder=10.100.32.31 -U replica-info-vuwunicoipam004.ods.vuw.ac.nz.gpg >>> --skip-conncheck >>> Checking forwarders, please wait ... >>> WARNING: DNS forwarder 10.100.32.31 does not return DNSSEC signatures in answers >>> Please fix forwarder configuration to enable DNSSEC support. >>> (For BIND 9 add directive "dnssec-enable yes;" to "options {}") >>> WARNING: DNSSEC validation will be disabled >>> ====== >>> >>> The AD server is a win2k12r2. >> Thanks, I will follow up. > As Dmitri said, all automatic DNSSEC key handling did not make the cut in > RHEL-7.1. If you want to test DNSSEC, you are very welcome, but you would be > left with manual configuration as described in upstream article: > > http://www.freeipa.org/page/Releases/4.0.0#Experimental_DNSSEC_Support > > We, however, still left this error message to make users and customers aware > that their name server is not ready even for manual DNSSEC. However, I did a > short research, and win2k12r2 should already support DNSSEC. Maybe the support > needs to be enabled. > > What DNS server do you have in /etc/resolv.conf? IPA DNS server + configured > DNS forward zone or do you have there AD IP address directly? Martin Basti > (CCed) recently found an issue with this check and DNS forwarders IIRC. Hello, IPA tests forwarders, if they are able to return signed root zone. It is not issue with test itself, we always found a misconfiguration on a forwarder side. The issue is warning message, because problems reported as DNSSEC failure usually have different root cause (which also prevent to use DNSSEC). We plan to make this validation more specific, to report correct issues. This check happens only for global forwarders. IPA automatically disable DNSSEC validation during installation, if any of configured global forwarders are not DNSSEC capable. With enabled DNSSEC validation, DNS server may drop unsigned responses from forwarder. Martin -- Martin Basti From yamakasi.014 at gmail.com Thu Mar 12 11:17:31 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 12 Mar 2015 12:17:31 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> Message-ID: Hi Guys, Is Rob able to look at this ? I hope he has some sparetime as I'm kinda stuck with this issue. Thanks! 2015-03-08 12:30 GMT+01:00 Matt . : > I'm reviewing some things. > > When I'm using a loadbalancer, which I prefer in this setup I need to > have the same certificates on both servers. Maybe a wildcard for my > domain could do instead of having only both fqdn's of the servers > including the loadbalancer's fqdn. > > But the question remains, how? > > > > 2015-03-07 10:37 GMT+01:00 Matt . : >> Hi, >> >> I will balance with IP persistance so I think there won't be any >> mixing as long as that "used" server is online. >> >> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>> On 03/06/2015 11:05 AM, Matt . wrote: >>>> >>>> OK, understood. >>>> >>>> But when a webservice does execute a command (from scripting) to a SVR >>>> record and the first is not reacable, would it try to do it again or >>>> will handle DNS this in front of it ? >>>> >>>> I do a kinit against an IPA server using a keytab after I first >>>> checked if the user was able to auth himself using his ldap >>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>> to the IPA server. >>>> >>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>> is down and doesn't even try to direct any of the commands to it... >>>> I'm not sure if the SRV will handle this well when doing these command >>>> from PHP for an example. Building in extra checks in front could be >>>> done but it not ideal as a loadbalancer can handle such things much >>>> better. >>> >>> >>> OK, this makes things much more clear. Thanks for the explanation. >>> Rob. What is our failover logic for API? >>> >>> For CLI we use a negotiation and then we store a cookie so as long as the >>> whole conversation goes to the same server you should be fine. I do not >>> think you need to re-encrypt the traffic at load balancer and thus have a >>> cert there then if you can enforce the use of the same server in this case. >>> >>> The issue I anticipate is with Kerberos. I think you should not load balance >>> the Kerberos traffic, only the API commands starting with the negotiation. >>> >>> Rob does that make sense for you? >>> >>> >>>> >>>> Thanks! >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>> >>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>> >>>>>> Hi, >>>>>> >>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>> SRV won't fit here sorry to say. >>>>>> >>>>>> I auth users, so their keytab should be the same between two masters I >>>>>> believe ? >>>>> >>>>> >>>>> Each entity in Kerberos exchange has its own identity and key. >>>>> If you send a ticket that is destined to service A instead to service B >>>>> it >>>>> would not work unless they share the same keys and identity. Sharinf same >>>>> keys and identities between the servers just would not work with IPA. >>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>> you >>>>> do not have any load balancers and this is the common case. You are >>>>> trying >>>>> to add one where it is really not needed creating overhead for yourself. >>>>> >>>>> >>>>> >>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>> 100% there in step 6 >>>>>> >>>>>> Thanks again! >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Matthijs >>>>>> >>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>> >>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>> >>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>> curl/json. >>>>>>> >>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>> It >>>>>>> will >>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>> easiest >>>>>>> way. >>>>>>> >>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>> >>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>> way >>>>>>> is to >>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>> works >>>>>>> even when servers are geographically distributed/in different networks >>>>>>> and >>>>>>> does not have single point of failure (the load balancer). >>>>>>> >>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>> on the IPA server because this is needed for the http service >>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>> >>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>> keytab for a user against both servers from my clients. >>>>>>> >>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>> IPA >>>>>>> server have their own keytabs too. Every service on every server has >>>>>>> own >>>>>>> keytab with different key. >>>>>>> >>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>> possibility >>>>>>> of >>>>>>> sharing keytabs between IPA services. >>>>>>> >>>>>>>> Does this make it more clear ? >>>>>>> >>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>> clients. >>>>>>> >>>>>>> Petr^2 Spacek >>>>>>> >>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>> >>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>> ipa >>>>>>>>>> server ? >>>>>>>>>> >>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>> >>>>>>>>>> Any other options ? >>>>>>>>> >>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>> detail, please? >>>>>>>>> >>>>>>>>> Petr^2 Spacek >>>>>>>>> >>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>> >>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>> >>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>> can >>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>> >>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>> possible to use >>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>> >>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>> to ipa >>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>> classical load >>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>> you to mess >>>>>>>>>>> with certs and keytabs. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Petr^2 Spacek >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Petr Spacek @ Red Hat >>>>> >>>>> >>>>> >>>>> -- >>>>> 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. >>> >>> -- >>> 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 dkupka at redhat.com Thu Mar 12 11:36:49 2015 From: dkupka at redhat.com (David Kupka) Date: Thu, 12 Mar 2015 12:36:49 +0100 Subject: [Freeipa-users] Adding external CA In-Reply-To: References: Message-ID: <55017A51.4080100@redhat.com> On 03/12/2015 10:37 AM, crony wrote: > Hi FreeIPA Users, > I have a fresh new FreeIPA 4.1 on RHEL7.1 with self-sign CA and I would > like to change the self-sign CA to the external CA > > Do you have any step by step document for do it correctly on 4.1 version? > > /lm > > > Hello! I'm not aware of this being documented but fortunately this can be done in 3 easy steps: 1. # ipa-cacert-manage renew --external-ca 2. Let CA of your choice sing the CRL produced in step 1. 3. # ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate --external-cert-file=/path/to/external_ca_certificate -- David Kupka From leszek.mis at gmail.com Thu Mar 12 11:48:45 2015 From: leszek.mis at gmail.com (crony) Date: Thu, 12 Mar 2015 12:48:45 +0100 Subject: [Freeipa-users] Adding external CA In-Reply-To: <55017A51.4080100@redhat.com> References: <55017A51.4080100@redhat.com> Message-ID: Thank you David, I'll check it out. 2015-03-12 12:36 GMT+01:00 David Kupka : > On 03/12/2015 10:37 AM, crony wrote: > >> Hi FreeIPA Users, >> I have a fresh new FreeIPA 4.1 on RHEL7.1 with self-sign CA and I would >> like to change the self-sign CA to the external CA >> >> Do you have any step by step document for do it correctly on 4.1 version? >> >> /lm >> >> >> >> > Hello! > > I'm not aware of this being documented but fortunately this can be done in > 3 easy steps: > > 1. # ipa-cacert-manage renew --external-ca > 2. Let CA of your choice sing the CRL produced in step 1. > 3. # ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate > --external-cert-file=/path/to/external_ca_certificate > > -- > David Kupka > -- Pozdrawiam Leszek Mi? www: http://cronylab.pl www: http://emerge.pl Nothing is secure, paranoia is your friend. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sigbjorn at nixtra.com Thu Mar 12 13:00:33 2015 From: sigbjorn at nixtra.com (Sigbjorn Lie) Date: Thu, 12 Mar 2015 14:00:33 +0100 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: <55008BF5.4070003@redhat.com> References: <55008BF5.4070003@redhat.com> Message-ID: Hi, Yes the DUA profile needs manually editing and updating as IPA servers are added or removed. Ideally this would be managed by ipa-replica-manage, however as I was advised in the BZ, Red Hat does not have the knowledge or resources to focus on integration with Solaris, which is understandable. :) The DUA profile I?ve uploaded to the BZ is a copy (with server names edited), of the DUA profile I1ve used at several environments when configuring Solaris 10 to work with IPA, so unless there are typos I haven?t discovered, it would work ok. :) As for the auto mount, Linux uses ?.? between auto and the map name, such as auto.master, auto.home, etc. And Solaris uses ?_? between the auto and the map name, such as auto_master, auto_home. This can be worked around in the DUA profile by adding a searchServiceDescriptor for each auto mounter map, such as "serviceSearchDescriptor: auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=ix,dc=test,dc=com?. What I found as the best middle ground here, was to keep the master name auto.master and have a serviceSearchDescriptor in the DUA profile for auto.master, and have the remaining maps in IPA with ?_?as the separator. This works the best as Linux will look for auto.master by default, and be happy with the other maps being referred to with ?_?as separator. Solaris seem to require that all the maps use ?_?as seperator, unless serviceSearchDescriptor entries are added for each map. I hope this was what you we?re looking for? Regards, Siggi > On 11 Mar 2015, at 19:39, Dmitri Pal wrote: > > Hello, > > Is there any chance you can help this guy on the FreeIPA list? > > Thanks > Dmitri > > > -------- Original Message -------- > Subject: Re: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login > Date: Wed, 11 Mar 2015 21:22:02 +0300 > From: Ben .T.George > Reply-To: bentech4you at gmail.com > To: dpal > CC: freeipa-users > > from BZ > > "While > we value your interest in IPA Solaris support, the > implementation of the DUA profile is not on our nearest > schedule at the moment. We lack both knowledge and resources > to focus on integration with Solaris. This is where we need > a help (ideally patches) and contribution from the community > to help us push these features in. > I checked your example DUAConfigProfile and I think it cannot be just added to FreeIPA right away. E.g. for defaultServerList or preferredServerList, you would need to expand installers and ipa-replica-manage to handle these lists and update them when replica is added or updated to prevent it being outdated. printers or aliases serviceSearchDescriptor refers to objects not being available and so on. It is not as straightforward as it seems. > > What I think that we can work on is to work together on > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 > ... and add all the steps needed to make IPA work on Solaris 10. I could for example prepare an updated page and you could review it. Would that work for you?" > this what i followed util now. but's not authenticate with AD, IPA user can login on solaris box > > On Wed, Mar 11, 2015 at 9:11 PM, Dmitri Pal > wrote: > On 03/11/2015 01:56 PM, Ben .T.George wrote: >> HI >> >> yea , i saw that mail thread and he claims that he achieved somehow. but not clear. >> >> and the steps mentioned is too technical for me. :) as i am very new to IPA it's bit confusing. >> >> later that thread also closed without proper explanation. >> >> i think you guys can contact him to change existing wiki :) as there are many solaris related documents which is pretty old. >> >> anyway still waiting for rply > > Have you found the BZ? They are very detailed. > https://bugzilla.redhat.com/show_bug.cgi?id=815515 > The DUA profile is attached to the bug. > > >> >> Regards, >> Ben >> >> On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal > wrote: >> On 03/11/2015 01:18 PM, Ben .T.George wrote: >>> HI >>> >>> thanks for the rply. >>> >>> even i tried native auto_master file with directory checking script. if i feed the user manually to the script, the directory is creating and while login request comes, it didn't. >>> >>> i don't think no one did full solaris integration util now as i asked many questions related to that. >>> >>> now i am little bit confident up to this level. and if everything is working fine, i will try to create automated script for IPA join >> >> I really do not know Solaris that well. There are some threads from this and last week about Solaris. You can find them in the mail archive for March. >> There are pointers to wikis and bugzillas in those threads. The bugzilla bugs have some extended info on how to configure Solaris clients. They were pretty detailed. May be they have the automount info you are looking for. >> >> >>> >>> Regards, >>> Ben >>> >>> >>> >>> On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal > wrote: >>> On 03/11/2015 09:50 AM, Ben .T.George wrote: >>>> HI >>>> >>>> i can able to reach upto level that IPA user can able to login on solaris box, >>>> >>>> but how can i create home directories automatically on solaris while IPA user login. >>>> >>>> even i change the shell in IPA web interface that is getting affected. i saw some option in IPA 3.3 web interface like automount and that is not in IPA 4.1.2 >>> >>> All the options are still there. The menus got re-arranged a bit. >>> Hopefully someone with a Solaris knowledge will help you with the rest. >>> >>>> >>>> please anyone tell me where it is and how can i achieve this >>>> >>>> regards, >>>> Ben >>>> >>>> >>> >>> >>> -- >>> 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. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Mar 12 14:07:29 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Mar 2015 10:07:29 -0400 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> Message-ID: <55019DA1.6060302@redhat.com> Matt . wrote: > Hi Guys, > > Is Rob able to look at this ? I hope he has some sparetime as I'm > kinda stuck with this issue. Wildcard certs are not supported. You can request a SAN with certmonger using -D . That will work with IPA 4.x for sure, maybe 3.3.5. rob > > Thanks! > > > > 2015-03-08 12:30 GMT+01:00 Matt . : >> I'm reviewing some things. >> >> When I'm using a loadbalancer, which I prefer in this setup I need to >> have the same certificates on both servers. Maybe a wildcard for my >> domain could do instead of having only both fqdn's of the servers >> including the loadbalancer's fqdn. >> >> But the question remains, how? >> >> >> >> 2015-03-07 10:37 GMT+01:00 Matt . : >>> Hi, >>> >>> I will balance with IP persistance so I think there won't be any >>> mixing as long as that "used" server is online. >>> >>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>> >>>>> OK, understood. >>>>> >>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>> record and the first is not reacable, would it try to do it again or >>>>> will handle DNS this in front of it ? >>>>> >>>>> I do a kinit against an IPA server using a keytab after I first >>>>> checked if the user was able to auth himself using his ldap >>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>> to the IPA server. >>>>> >>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>> is down and doesn't even try to direct any of the commands to it... >>>>> I'm not sure if the SRV will handle this well when doing these command >>>>> from PHP for an example. Building in extra checks in front could be >>>>> done but it not ideal as a loadbalancer can handle such things much >>>>> better. >>>> >>>> >>>> OK, this makes things much more clear. Thanks for the explanation. >>>> Rob. What is our failover logic for API? >>>> >>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>> whole conversation goes to the same server you should be fine. I do not >>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>> cert there then if you can enforce the use of the same server in this case. >>>> >>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>> >>>> Rob does that make sense for you? >>>> >>>> >>>>> >>>>> Thanks! >>>>> >>>>> Cheers, >>>>> >>>>> Matt >>>>> >>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>> >>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>> >>>>>>> Hi, >>>>>>> >>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>> SRV won't fit here sorry to say. >>>>>>> >>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>> believe ? >>>>>> >>>>>> >>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>> If you send a ticket that is destined to service A instead to service B >>>>>> it >>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>> keys and identities between the servers just would not work with IPA. >>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>> you >>>>>> do not have any load balancers and this is the common case. You are >>>>>> trying >>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>> >>>>>> >>>>>> >>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>> 100% there in step 6 >>>>>>> >>>>>>> Thanks again! >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matthijs >>>>>>> >>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>> >>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>> >>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>> curl/json. >>>>>>>> >>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>> It >>>>>>>> will >>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>> easiest >>>>>>>> way. >>>>>>>> >>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>> >>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>> way >>>>>>>> is to >>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>> works >>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>> and >>>>>>>> does not have single point of failure (the load balancer). >>>>>>>> >>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>> >>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>> >>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>> IPA >>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>> own >>>>>>>> keytab with different key. >>>>>>>> >>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>> possibility >>>>>>>> of >>>>>>>> sharing keytabs between IPA services. >>>>>>>> >>>>>>>>> Does this make it more clear ? >>>>>>>> >>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>> clients. >>>>>>>> >>>>>>>> Petr^2 Spacek >>>>>>>> >>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>> >>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>> ipa >>>>>>>>>>> server ? >>>>>>>>>>> >>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>> >>>>>>>>>>> Any other options ? >>>>>>>>>> >>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>> detail, please? >>>>>>>>>> >>>>>>>>>> Petr^2 Spacek >>>>>>>>>> >>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>> >>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>> can >>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>> >>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>> possible to use >>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>> >>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>> to ipa >>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>> classical load >>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>> you to mess >>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Petr^2 Spacek >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Petr Spacek @ Red Hat >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>> >>>> -- >>>> 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 yamakasi.014 at gmail.com Thu Mar 12 14:17:44 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 12 Mar 2015 15:17:44 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <55019DA1.6060302@redhat.com> References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> Message-ID: Hi, Security wise I can understand that. Yes I have read about that... but that would let me use the loadbalancer to connect ? I was not sure if the SAN would "connect" as "other" host. 2015-03-12 15:07 GMT+01:00 Rob Crittenden : > Matt . wrote: >> Hi Guys, >> >> Is Rob able to look at this ? I hope he has some sparetime as I'm >> kinda stuck with this issue. > > Wildcard certs are not supported. > > You can request a SAN with certmonger using -D . That will work > with IPA 4.x for sure, maybe 3.3.5. > > rob > >> >> Thanks! >> >> >> >> 2015-03-08 12:30 GMT+01:00 Matt . : >>> I'm reviewing some things. >>> >>> When I'm using a loadbalancer, which I prefer in this setup I need to >>> have the same certificates on both servers. Maybe a wildcard for my >>> domain could do instead of having only both fqdn's of the servers >>> including the loadbalancer's fqdn. >>> >>> But the question remains, how? >>> >>> >>> >>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>> Hi, >>>> >>>> I will balance with IP persistance so I think there won't be any >>>> mixing as long as that "used" server is online. >>>> >>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>> >>>>>> OK, understood. >>>>>> >>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>> record and the first is not reacable, would it try to do it again or >>>>>> will handle DNS this in front of it ? >>>>>> >>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>> checked if the user was able to auth himself using his ldap >>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>> to the IPA server. >>>>>> >>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>> from PHP for an example. Building in extra checks in front could be >>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>> better. >>>>> >>>>> >>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>> Rob. What is our failover logic for API? >>>>> >>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>> whole conversation goes to the same server you should be fine. I do not >>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>> cert there then if you can enforce the use of the same server in this case. >>>>> >>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>> >>>>> Rob does that make sense for you? >>>>> >>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Cheers, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>> >>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>> >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>> SRV won't fit here sorry to say. >>>>>>>> >>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>> believe ? >>>>>>> >>>>>>> >>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>> it >>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>> you >>>>>>> do not have any load balancers and this is the common case. You are >>>>>>> trying >>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>> 100% there in step 6 >>>>>>>> >>>>>>>> Thanks again! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Matthijs >>>>>>>> >>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>> >>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>> >>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>> curl/json. >>>>>>>>> >>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>> It >>>>>>>>> will >>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>> easiest >>>>>>>>> way. >>>>>>>>> >>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>> >>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>> way >>>>>>>>> is to >>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>> works >>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>> and >>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>> >>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>> >>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>> >>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>> IPA >>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>> own >>>>>>>>> keytab with different key. >>>>>>>>> >>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>> possibility >>>>>>>>> of >>>>>>>>> sharing keytabs between IPA services. >>>>>>>>> >>>>>>>>>> Does this make it more clear ? >>>>>>>>> >>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>> clients. >>>>>>>>> >>>>>>>>> Petr^2 Spacek >>>>>>>>> >>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>> >>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>> ipa >>>>>>>>>>>> server ? >>>>>>>>>>>> >>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>> >>>>>>>>>>>> Any other options ? >>>>>>>>>>> >>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>> detail, please? >>>>>>>>>>> >>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>> >>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>> >>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>> can >>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>> >>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>> possible to use >>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>> >>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>> to ipa >>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>> classical load >>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>> you to mess >>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> Petr Spacek @ Red Hat >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>> >>>>> -- >>>>> 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 Thu Mar 12 14:35:03 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Mar 2015 15:35:03 +0100 Subject: [Freeipa-users] Backwards compatability In-Reply-To: <55007F61.8070408@redhat.com> References: <55007F61.8070408@redhat.com> Message-ID: <5501A417.9090306@redhat.com> On 03/11/2015 06:46 PM, Dmitri Pal wrote: > On 03/11/2015 01:13 PM, Andrew Holway wrote: >> Hi, >> >> We have a mix of Centos 6 and Centos 7 machines which we would like to manage >> with FreeIPA. >> >> I remember that setting up freeipa on Centos 6 can be a bit tricky although I >> found this method which works. >> >> https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html >> >> I imagine the Centos 7 client setup is somewhat more streamlined. >> >> Assuming we install freeipa on Centos 7, will our centos 6 clients have any >> problem connection? Any caveats which we should be aware of? >> >> Thanks, >> >> Andrew >> >> > Clients should work without any issues. > > The only thing to keep in mind is that IPA's remote management CLI should be > used from the systems of the same versions as the server. In other words the > ipa-admintools package that contains CLI would not work from CentOS 6 system > against CentOS 7 system. But would work from 7 to 7. Right. Compatiblity is explained also on upstream wiki: http://www.freeipa.org/page/Client#Compatibility Martin From mkosek at redhat.com Thu Mar 12 14:40:49 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Mar 2015 15:40:49 +0100 Subject: [Freeipa-users] Adding external CA In-Reply-To: References: <55017A51.4080100@redhat.com> Message-ID: <5501A571.9010509@redhat.com> On 03/12/2015 12:48 PM, crony wrote: > Thank you David, I'll check it out. > > 2015-03-12 12:36 GMT+01:00 David Kupka : > >> On 03/12/2015 10:37 AM, crony wrote: >> >>> Hi FreeIPA Users, >>> I have a fresh new FreeIPA 4.1 on RHEL7.1 with self-sign CA and I would >>> like to change the self-sign CA to the external CA >>> >>> Do you have any step by step document for do it correctly on 4.1 version? >>> >>> /lm >>> >>> >>> >>> >> Hello! >> >> I'm not aware of this being documented but fortunately this can be done in >> 3 easy steps: >> >> 1. # ipa-cacert-manage renew --external-ca >> 2. Let CA of your choice sing the CRL produced in step 1. >> 3. # ipa-cacert-manage renew --external-cert-file=/path/to/signed_certificate >> --external-cert-file=/path/to/external_ca_certificate Some documentation can be found in RHEL guide: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/cas.html#change-cert-chaining There is also upstream design page: http://www.freeipa.org/page/V4/CA_certificate_renewal But in general, David was right. You would just need to do one more step if you had FreIPA clients already enrolled - call ipa-certupdate on them. Martin From rcritten at redhat.com Thu Mar 12 14:54:36 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Mar 2015 10:54:36 -0400 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> Message-ID: <5501A8AC.8050403@redhat.com> Matt . wrote: > Hi, > > Security wise I can understand that. > > Yes I have read about that... but that would let me use the > loadbalancer to connect ? I was not sure if the SAN would "connect" as > "other" host. Kerberos through a load balancer can be a problem. Is this what you're worried about? rob > > 2015-03-12 15:07 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> Hi Guys, >>> >>> Is Rob able to look at this ? I hope he has some sparetime as I'm >>> kinda stuck with this issue. >> >> Wildcard certs are not supported. >> >> You can request a SAN with certmonger using -D . That will work >> with IPA 4.x for sure, maybe 3.3.5. >> >> rob >> >>> >>> Thanks! >>> >>> >>> >>> 2015-03-08 12:30 GMT+01:00 Matt . : >>>> I'm reviewing some things. >>>> >>>> When I'm using a loadbalancer, which I prefer in this setup I need to >>>> have the same certificates on both servers. Maybe a wildcard for my >>>> domain could do instead of having only both fqdn's of the servers >>>> including the loadbalancer's fqdn. >>>> >>>> But the question remains, how? >>>> >>>> >>>> >>>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>>> Hi, >>>>> >>>>> I will balance with IP persistance so I think there won't be any >>>>> mixing as long as that "used" server is online. >>>>> >>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>>> >>>>>>> OK, understood. >>>>>>> >>>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>>> record and the first is not reacable, would it try to do it again or >>>>>>> will handle DNS this in front of it ? >>>>>>> >>>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>>> checked if the user was able to auth himself using his ldap >>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>>> to the IPA server. >>>>>>> >>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>>> from PHP for an example. Building in extra checks in front could be >>>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>>> better. >>>>>> >>>>>> >>>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>>> Rob. What is our failover logic for API? >>>>>> >>>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>>> whole conversation goes to the same server you should be fine. I do not >>>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>>> cert there then if you can enforce the use of the same server in this case. >>>>>> >>>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>>> >>>>>> Rob does that make sense for you? >>>>>> >>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>>> >>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>>> SRV won't fit here sorry to say. >>>>>>>>> >>>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>>> believe ? >>>>>>>> >>>>>>>> >>>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>>> it >>>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>>> you >>>>>>>> do not have any load balancers and this is the common case. You are >>>>>>>> trying >>>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>>> 100% there in step 6 >>>>>>>>> >>>>>>>>> Thanks again! >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Matthijs >>>>>>>>> >>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>>> >>>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>>> >>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>>> curl/json. >>>>>>>>>> >>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>>> It >>>>>>>>>> will >>>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>>> easiest >>>>>>>>>> way. >>>>>>>>>> >>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>>> >>>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>>> way >>>>>>>>>> is to >>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>>> works >>>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>>> and >>>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>>> >>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>>> >>>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>>> >>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>>> IPA >>>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>>> own >>>>>>>>>> keytab with different key. >>>>>>>>>> >>>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>>> possibility >>>>>>>>>> of >>>>>>>>>> sharing keytabs between IPA services. >>>>>>>>>> >>>>>>>>>>> Does this make it more clear ? >>>>>>>>>> >>>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>>> clients. >>>>>>>>>> >>>>>>>>>> Petr^2 Spacek >>>>>>>>>> >>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>>> >>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>>> ipa >>>>>>>>>>>>> server ? >>>>>>>>>>>>> >>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>>> >>>>>>>>>>>>> Any other options ? >>>>>>>>>>>> >>>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>>> detail, please? >>>>>>>>>>>> >>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>> >>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>>> can >>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>>> possible to use >>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>>> to ipa >>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>>> classical load >>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>>> you to mess >>>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Petr Spacek @ Red Hat >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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. >>>>>> >>>>>> -- >>>>>> 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 yamakasi.014 at gmail.com Thu Mar 12 15:59:33 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 12 Mar 2015 16:59:33 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <5501A8AC.8050403@redhat.com> References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> Message-ID: Not worried, I need to try. I think it's not an issue as we use persistance for the connection. We only do some user adding/chaging stuff, nothing really fancy but it needs to be decent. As persistence comes in I think we don't have to worry about it, we discussed that here earlier as I remember. Or do I ? Something else; did you had a nice PTO ? 2015-03-12 15:54 GMT+01:00 Rob Crittenden : > Matt . wrote: >> Hi, >> >> Security wise I can understand that. >> >> Yes I have read about that... but that would let me use the >> loadbalancer to connect ? I was not sure if the SAN would "connect" as >> "other" host. > > Kerberos through a load balancer can be a problem. Is this what you're > worried about? > > rob > >> >> 2015-03-12 15:07 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> Hi Guys, >>>> >>>> Is Rob able to look at this ? I hope he has some sparetime as I'm >>>> kinda stuck with this issue. >>> >>> Wildcard certs are not supported. >>> >>> You can request a SAN with certmonger using -D . That will work >>> with IPA 4.x for sure, maybe 3.3.5. >>> >>> rob >>> >>>> >>>> Thanks! >>>> >>>> >>>> >>>> 2015-03-08 12:30 GMT+01:00 Matt . : >>>>> I'm reviewing some things. >>>>> >>>>> When I'm using a loadbalancer, which I prefer in this setup I need to >>>>> have the same certificates on both servers. Maybe a wildcard for my >>>>> domain could do instead of having only both fqdn's of the servers >>>>> including the loadbalancer's fqdn. >>>>> >>>>> But the question remains, how? >>>>> >>>>> >>>>> >>>>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>>>> Hi, >>>>>> >>>>>> I will balance with IP persistance so I think there won't be any >>>>>> mixing as long as that "used" server is online. >>>>>> >>>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>>>> >>>>>>>> OK, understood. >>>>>>>> >>>>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>>>> record and the first is not reacable, would it try to do it again or >>>>>>>> will handle DNS this in front of it ? >>>>>>>> >>>>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>>>> checked if the user was able to auth himself using his ldap >>>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>>>> to the IPA server. >>>>>>>> >>>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>>>> from PHP for an example. Building in extra checks in front could be >>>>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>>>> better. >>>>>>> >>>>>>> >>>>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>>>> Rob. What is our failover logic for API? >>>>>>> >>>>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>>>> whole conversation goes to the same server you should be fine. I do not >>>>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>>>> cert there then if you can enforce the use of the same server in this case. >>>>>>> >>>>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>>>> >>>>>>> Rob does that make sense for you? >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>>>> >>>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>>>> >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>>>> SRV won't fit here sorry to say. >>>>>>>>>> >>>>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>>>> believe ? >>>>>>>>> >>>>>>>>> >>>>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>>>> it >>>>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>>>> you >>>>>>>>> do not have any load balancers and this is the common case. You are >>>>>>>>> trying >>>>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>>>> 100% there in step 6 >>>>>>>>>> >>>>>>>>>> Thanks again! >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Matthijs >>>>>>>>>> >>>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>>>> >>>>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>>>> >>>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>>>> curl/json. >>>>>>>>>>> >>>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>>>> It >>>>>>>>>>> will >>>>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>>>> easiest >>>>>>>>>>> way. >>>>>>>>>>> >>>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>>>> >>>>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>>>> way >>>>>>>>>>> is to >>>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>>>> works >>>>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>>>> and >>>>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>>>> >>>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>>>> >>>>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>>>> >>>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>>>> IPA >>>>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>>>> own >>>>>>>>>>> keytab with different key. >>>>>>>>>>> >>>>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>>>> possibility >>>>>>>>>>> of >>>>>>>>>>> sharing keytabs between IPA services. >>>>>>>>>>> >>>>>>>>>>>> Does this make it more clear ? >>>>>>>>>>> >>>>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>>>> clients. >>>>>>>>>>> >>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>> >>>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>>>> >>>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>>>> ipa >>>>>>>>>>>>>> server ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Any other options ? >>>>>>>>>>>>> >>>>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>>>> detail, please? >>>>>>>>>>>>> >>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>>>> possible to use >>>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>>>> to ipa >>>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>>>> classical load >>>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>>>> you to mess >>>>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> Petr Spacek @ Red Hat >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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. >>>>>>> >>>>>>> -- >>>>>>> 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 erinn.looneytriggs at gmail.com Thu Mar 12 18:24:30 2015 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 12 Mar 2015 12:24:30 -0600 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <550149F0.9030305@redhat.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <5500A005.5010500@redhat.com> <55013F57.4060003@redhat.com> <550149F0.9030305@redhat.com> Message-ID: <5501D9DE.1050700@gmail.com> On 03/12/2015 02:10 AM, Jan Cholasta wrote: > Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): >> On 03/11/2015 09:05 PM, Dmitri Pal wrote: >>> On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: >> ... >>>> Third, there appears to be a behavior change from in ipalib. >>>> I cleaned up a little inventory script for ansible, you can >>>> take a look at it here: >>>> https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py >>>> >>>> >>>> >>>> Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] >>>> on line 30 worked, now it fails: >>>> >>>> Traceback (most recent call last): File "./freeipa.py", line >>>> 133, in list_groups(api) File "./freeipa.py", line >>>> 71, in list_groups result = >>>> api.Command.host_find()['result'] File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>> 439, in __call__ ret = self.run(*args, **options) File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>> 755, in run return self.forward(*args, **options) File >>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>> 776, in forward return >>>> self.Backend.rpcclient.forward(self.name, *args, **kw) File >>>> "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, >>>> in forward command = getattr(self.conn, name) File >>>> "/usr/lib/python2.7/site-packages/ipalib/backend.py", line >>>> 97, in __get_conn self.id, >>>> threading.currentThread().getName()) AttributeError: no >>>> context.rpcclient in thread 'MainThread' >>>> >>>> Is this expected? Is this a regression? >>> >>> Some things changed. I would leave for developers to take a >>> look and provide more guidance. >> >> Erinn, it may help us if you share the whole sequence how you >> bootstrap and authenticatoin the API. Honza, was there any >> related change causing ^^^? >> > > https://fedorahosted.org/freeipa/ticket/3299 > > There is api.Backend.xmlclient.connect() in the code, but JSON-RPC > is now used by default. This can be fixed by calling > api.Backend.rpcclient.connect() instead. > Thanks, is this backwards compatible? Or will I need to run a check for the IPA version? -Erinn From bentech4you at gmail.com Thu Mar 12 18:30:42 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Thu, 12 Mar 2015 21:30:42 +0300 Subject: [Freeipa-users] how can i create home directories automatically on solaris while IPA user login In-Reply-To: References: <55008BF5.4070003@redhat.com> Message-ID: HI Siggi, thanks for the detailed information. how can i apply this DUA profile? can you please give me the steps to apply this. my current stage is, i can able to login to solaris 10 box with AD user. only thing from command like without "-" in su Regards, Ben On Thu, Mar 12, 2015 at 4:00 PM, Sigbjorn Lie wrote: > Hi, > > Yes the DUA profile needs manually editing and updating as IPA servers are > added or removed. Ideally this would be managed by ipa-replica-manage, > however as I was advised in the BZ, Red Hat does not have the knowledge or > resources to focus on integration with Solaris, which is understandable. :) > > The DUA profile I?ve uploaded to the BZ is a copy (with server names > edited), of the DUA profile I1ve used at several environments when > configuring Solaris 10 to work with IPA, so unless there are typos I > haven?t discovered, it would work ok. :) > > As for the auto mount, Linux uses ?.? between auto and the map name, such > as auto.master, auto.home, etc. And Solaris uses ?_? between the auto and > the map name, such as auto_master, auto_home. > > This can be worked around in the DUA profile by adding a > searchServiceDescriptor for each auto mounter map, such as > "serviceSearchDescriptor: > auto_master:automountMapName=auto.master,cn=defualt,cn=automount,dc=ix,dc=test,dc=com?. > > What I found as the best middle ground here, was to keep the master name > auto.master and have a serviceSearchDescriptor in the DUA profile for > auto.master, and have the remaining maps in IPA with ?_?as the separator. > This works the best as Linux will look for auto.master by default, and be > happy with the other maps being referred to with ?_?as separator. Solaris > seem to require that all the maps use ?_?as seperator, unless > serviceSearchDescriptor entries are added for each map. > > I hope this was what you we?re looking for? > > > Regards, > Siggi > > > > > On 11 Mar 2015, at 19:39, Dmitri Pal wrote: > > Hello, > > Is there any chance you can help this guy on the FreeIPA list? > > Thanks > Dmitri > > > -------- Original Message -------- Subject: Re: [Freeipa-users] how can > i create home directories automatically on solaris while IPA user login Date: > Wed, 11 Mar 2015 21:22:02 +0300 From: Ben .T.George > Reply-To: > bentech4you at gmail.com To: dpal CC: freeipa-users > > > > from BZ > > "While we value your interest in IPA Solaris support, the implementation > of the DUA profile is not on our nearest schedule at the moment. We lack > both knowledge and resources to focus on integration with Solaris. This is > where we need a help (ideally patches) and contribution from the community > to help us push these features in. > > I checked your example DUAConfigProfile and I think it cannot be just added to FreeIPA right away. E.g. for defaultServerList or preferredServerList, you would need to expand installers and ipa-replica-manage to handle these lists and update them when replica is added or updated to prevent it being outdated. printers or aliases serviceSearchDescriptor refers to objects not being available and so on. It is not as straightforward as it seems. > > What I think that we can work on is to work together onhttp://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/Configuring_an_IPA_Client_on_Solaris.html#Configuring_an_IPA_Client_on_Solaris_10 > ... and add all the steps needed to make IPA work on Solaris 10. I could for example prepare an updated page and you could review it. Would that work for you?" > > this what i followed util now. but's not authenticate with AD, IPA user can login on solaris box > > > On Wed, Mar 11, 2015 at 9:11 PM, Dmitri Pal wrote: > >> On 03/11/2015 01:56 PM, Ben .T.George wrote: >> >> HI >> >> yea , i saw that mail thread and he claims that he achieved somehow. >> but not clear. >> >> and the steps mentioned is too technical for me. :) as i am very new >> to IPA it's bit confusing. >> >> later that thread also closed without proper explanation. >> >> i think you guys can contact him to change existing wiki :) as there >> are many solaris related documents which is pretty old. >> >> anyway still waiting for rply >> >> >> Have you found the BZ? They are very detailed. >> https://bugzilla.redhat.com/show_bug.cgi?id=815515 >> The DUA profile is attached to the bug. >> >> >> >> Regards, >> Ben >> >> On Wed, Mar 11, 2015 at 8:49 PM, Dmitri Pal wrote: >> >>> On 03/11/2015 01:18 PM, Ben .T.George wrote: >>> >>> HI >>> >>> thanks for the rply. >>> >>> even i tried native auto_master file with directory checking script. >>> if i feed the user manually to the script, the directory is creating and >>> while login request comes, it didn't. >>> >>> i don't think no one did full solaris integration util now as i asked >>> many questions related to that. >>> >>> now i am little bit confident up to this level. and if everything is >>> working fine, i will try to create automated script for IPA join >>> >>> >>> I really do not know Solaris that well. There are some threads from >>> this and last week about Solaris. You can find them in the mail archive for >>> March. >>> There are pointers to wikis and bugzillas in those threads. The bugzilla >>> bugs have some extended info on how to configure Solaris clients. They were >>> pretty detailed. May be they have the automount info you are looking for. >>> >>> >>> >>> Regards, >>> Ben >>> >>> >>> >>> On Wed, Mar 11, 2015 at 7:32 PM, Dmitri Pal wrote: >>> >>>> On 03/11/2015 09:50 AM, Ben .T.George wrote: >>>> >>>> HI >>>> >>>> i can able to reach upto level that IPA user can able to login on >>>> solaris box, >>>> >>>> but how can i create home directories automatically on solaris while >>>> IPA user login. >>>> >>>> even i change the shell in IPA web interface that is getting >>>> affected. i saw some option in IPA 3.3 web interface like automount and >>>> that is not in IPA 4.1.2 >>>> >>>> >>>> All the options are still there. The menus got re-arranged a bit. >>>> Hopefully someone with a Solaris knowledge will help you with the rest. >>>> >>>> >>>> please anyone tell me where it is and how can i achieve this >>>> >>>> regards, >>>> Ben >>>> >>>> >>>> >>>> >>>> -- >>>> 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. >> >> > > > > > -- > 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 sipazzo at yahoo.com Thu Mar 12 18:54:59 2015 From: sipazzo at yahoo.com (sipazzo) Date: Thu, 12 Mar 2015 18:54:59 +0000 (UTC) Subject: [Freeipa-users] Fw: Need to replace cert for ipa servers In-Reply-To: <903DF15B7B9D3B4D9137A06F63687859172C8A77A1@FHDP1LUMXC7V33.us.one.verizon.com> References: <903DF15B7B9D3B4D9137A06F63687859172C8A77A1@FHDP1LUMXC7V33.us.one.verizon.com> Message-ID: <289264466.3500514.1426186499556.JavaMail.yahoo@mail.yahoo.com> I do have other CAs (just not the master but it is available offline if needed) Directory server is runningThe apache web server is running and I can get to the guiipa cert-show 1 works Are the TLS errors due to the mismatch in certs between slapd-PKI-CA and slapd-NETWORKFLEET-COM? -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden Sent: Wednesday, March 11, 2015 7:20 PM To: sipazzo; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Need to replace cert for ipa servers sipazzo wrote: > Thanks Rob, I apologize that error was probably not helpful. This is > what I see when running install in debug mode: > > Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an > IPA server Init LDAP connection with: > ldap://ipa2-corp.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer > is not recognized. > Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA > server Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer > is not recognized. > Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA > server Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer > is not recognized. > Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA > server Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer > is not recognized. > Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA > server Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 > LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer > is not recognized. > > The certificates are very confusing to me. I don't understand how > things are working when we have a set of GoDaddy certs in > slapd-NETWORKFLEET-COM and a set of the Dogtag certs in slapd-PKI-CA. > The cert in /usr/share/ipa/html/ca.crt looks like the original one > issued by the Dogtag cert system and matches the ones on the clients. > Not to further confuse things but the original master server that > signed all these certs was taken offline months ago due to some issues > it was having. I do still have access to it if necessary. > > As far as why the godaddy certs were swapped out for the Dogtag certs > it was originally for something as simple as the untrusted certificate > dialogue when accessing the ipa gui. I did not swap out the certs so > am unsure of exactly what happened. There is no real need to use the > GoDaddy certs as far as I am concerned. I just want the best solution > to the issues I am seeing as I am in kind of a bind with the GoDaddy > cert being revoked and needing to be replaced and the master Dogtag > certificate server offline. We have a mixed environment with Rhel 5, 6 > and Solaris clients so are not using sssd in all cases. > > I know this is asking a lot but appreciate any help you can give. What is the current state of things? Does your IPA Apache server work? Is 389-ds up and running? Do you have a working IPA CA? Does ipa cert-show 1 work? If the answer is yes to all then we should be able to generate new certs for all the services. 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 -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Mar 12 19:46:35 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 12 Mar 2015 20:46:35 +0100 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <5501D9DE.1050700@gmail.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <5500A005.5010500@redhat.com> <55013F57.4060003@redhat.com> <550149F0.9030305@redhat.com> <5501D9DE.1050700@gmail.com> Message-ID: <5501ED1B.5000007@redhat.com> On 03/12/2015 07:24 PM, Erinn Looney-Triggs wrote: > On 03/12/2015 02:10 AM, Jan Cholasta wrote: >> Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): >>> On 03/11/2015 09:05 PM, Dmitri Pal wrote: >>>> On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: >>> ... >>>>> Third, there appears to be a behavior change from in ipalib. >>>>> I cleaned up a little inventory script for ansible, you can >>>>> take a look at it here: >>>>> https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py >>>>> >>>>> >>>>> >>>>> > Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] >>>>> on line 30 worked, now it fails: >>>>> >>>>> Traceback (most recent call last): File "./freeipa.py", line >>>>> 133, in list_groups(api) File "./freeipa.py", line >>>>> 71, in list_groups result = >>>>> api.Command.host_find()['result'] File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>>> 439, in __call__ ret = self.run(*args, **options) File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>>> 755, in run return self.forward(*args, **options) File >>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>>> 776, in forward return >>>>> self.Backend.rpcclient.forward(self.name, *args, **kw) File >>>>> "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, >>>>> in forward command = getattr(self.conn, name) File >>>>> "/usr/lib/python2.7/site-packages/ipalib/backend.py", line >>>>> 97, in __get_conn self.id, >>>>> threading.currentThread().getName()) AttributeError: no >>>>> context.rpcclient in thread 'MainThread' >>>>> >>>>> Is this expected? Is this a regression? >>>> >>>> Some things changed. I would leave for developers to take a >>>> look and provide more guidance. >>> >>> Erinn, it may help us if you share the whole sequence how you >>> bootstrap and authenticatoin the API. Honza, was there any >>> related change causing ^^^? >>> >> >> https://fedorahosted.org/freeipa/ticket/3299 >> >> There is api.Backend.xmlclient.connect() in the code, but JSON-RPC >> is now used by default. This can be fixed by calling >> api.Backend.rpcclient.connect() instead. >> > > Thanks, is this backwards compatible? Or will I need to run a check > for the IPA version? Unfortunately, I do not think this is backwards compatible. I would suggest compatibility code like: try: client = api.Backend.rpcclient except AttributeError: # Compatibility with FreeIPA < 4.0 client = api.Backend.xmlclient client.connect() Sorry for inconvenience. Martin From erinn.looneytriggs at gmail.com Thu Mar 12 19:55:06 2015 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Thu, 12 Mar 2015 13:55:06 -0600 Subject: [Freeipa-users] IPA 4.1.0 in RHEL 7.1 In-Reply-To: <5501ED1B.5000007@redhat.com> References: <4210294.jkvoj2gI6j@scrapy.abaqis.com> <5500A005.5010500@redhat.com> <55013F57.4060003@redhat.com> <550149F0.9030305@redhat.com> <5501D9DE.1050700@gmail.com> <5501ED1B.5000007@redhat.com> Message-ID: <5501EF1A.8090107@gmail.com> On 03/12/2015 01:46 PM, Martin Kosek wrote: > On 03/12/2015 07:24 PM, Erinn Looney-Triggs wrote: >> On 03/12/2015 02:10 AM, Jan Cholasta wrote: >>> Dne 12.3.2015 v 08:25 Martin Kosek napsal(a): >>>> On 03/11/2015 09:05 PM, Dmitri Pal wrote: >>>>> On 03/11/2015 03:15 PM, Erinn Looney-Triggs wrote: >>>> ... >>>>>> Third, there appears to be a behavior change from in ipalib. >>>>>> I cleaned up a little inventory script for ansible, you can >>>>>> take a look at it here: >>>>>> https://github.com/ansible/ansible/blob/devel/plugins/inventory/freeipa.py >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >> Before RHEL 7.1 the call to api.Command.hostgroup_find()['result'] >>>>>> on line 30 worked, now it fails: >>>>>> >>>>>> Traceback (most recent call last): File "./freeipa.py", line >>>>>> 133, in list_groups(api) File "./freeipa.py", line >>>>>> 71, in list_groups result = >>>>>> api.Command.host_find()['result'] File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>>>> 439, in __call__ ret = self.run(*args, **options) File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>>>> 755, in run return self.forward(*args, **options) File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line >>>>>> 776, in forward return >>>>>> self.Backend.rpcclient.forward(self.name, *args, **kw) File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/rpc.py", line 880, >>>>>> in forward command = getattr(self.conn, name) File >>>>>> "/usr/lib/python2.7/site-packages/ipalib/backend.py", line >>>>>> 97, in __get_conn self.id, >>>>>> threading.currentThread().getName()) AttributeError: no >>>>>> context.rpcclient in thread 'MainThread' >>>>>> >>>>>> Is this expected? Is this a regression? >>>>> >>>>> Some things changed. I would leave for developers to take a >>>>> look and provide more guidance. >>>> >>>> Erinn, it may help us if you share the whole sequence how you >>>> bootstrap and authenticatoin the API. Honza, was there any >>>> related change causing ^^^? >>>> >>> >>> https://fedorahosted.org/freeipa/ticket/3299 >>> >>> There is api.Backend.xmlclient.connect() in the code, but JSON-RPC >>> is now used by default. This can be fixed by calling >>> api.Backend.rpcclient.connect() instead. >>> >> >> Thanks, is this backwards compatible? Or will I need to run a check >> for the IPA version? > > Unfortunately, I do not think this is backwards compatible. I would > suggest compatibility code like: > > try: > client = api.Backend.rpcclient > except AttributeError: > # Compatibility with FreeIPA < 4.0 > client = api.Backend.xmlclient > > client.connect() > > Sorry for inconvenience. > > Martin That's fine, it happens, thanks for all the information. -Erinn From Steven.Jones at vuw.ac.nz Thu Mar 12 19:56:38 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Thu, 12 Mar 2015 19:56:38 +0000 Subject: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1) In-Reply-To: <55015644.5090800@redhat.com> References: <54FEEE44.8000207@opennms.org> <20150310133150.GM25455@redhat.com> <54FEF59A.7040109@opennms.org> <20150310140626.GN25455@redhat.com>,<55015644.5090800@redhat.com> Message-ID: <1426190043890.72489@vuw.ac.nz> Hi, Currently it seems that IPA on RHEL6.6 is broken in terms of adding a RHEL7.1 replica to it. ie following the document linked to below. Should be a BZ case on it shortly via RH support (RH case number 01290601) for an updated 389 rpm for 6.6. I assume it will be the same for Centos 7.x as your base is RHEL6.6. Unless there is an already fixed 389/6.6 package somewhere I can try? Its a test bed for the actual upgrade so if it blows no biggee, anything to get this advanced! regards Steven 8><--- >>> Are you following these instructions? >>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html 8><--- From rob.verduijn at gmail.com Thu Mar 12 20:32:25 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Thu, 12 Mar 2015 21:32:25 +0100 Subject: [Freeipa-users] OTP and cached credentials Message-ID: Hello, I was looking into otp authentication and found some articles on how to enable this in freeipa. I can't seem to figure out how this is going to deal with cashed credentials on a laptop that is not able to connect the ipa server. How is this going to work out when 'native OTP' is being used ? Or with a radius proxy ? Rob Verduijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Mar 12 20:51:58 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 12 Mar 2015 16:51:58 -0400 Subject: [Freeipa-users] Fw: Need to replace cert for ipa servers In-Reply-To: <289264466.3500514.1426186499556.JavaMail.yahoo@mail.yahoo.com> References: <903DF15B7B9D3B4D9137A06F63687859172C8A77A1@FHDP1LUMXC7V33.us.one.verizon.com> <289264466.3500514.1426186499556.JavaMail.yahoo@mail.yahoo.com> Message-ID: <5501FC6E.9040205@redhat.com> sipazzo wrote: > I do have other CAs (just not the master but it is available offline if > needed) To be clear, all IPA servers are masters, some just run more services than others. It sounds like you have at least one CA available which should be sufficient. > Directory server is running > The apache web server is running and I can get to the gui > ipa cert-show 1 works Ok. I guess the place to start is to get certs for Apache and 389-ds, then we can see about using these new certs. In the thread you showed that the IPA 389-ds doesn't have a Server-Cert nickname. You'll want to do the same for /etc/httpd/alias before running the following commands otherwise you could end up with non-functional server. These should get IPA certs for 389-ds and Apache. You'll need to edit these commands to match your environment: # ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_httpd -N CN=ipa.example.com -K HTTP/ipa.example.com at EXAMPLE.COM # ipa-getcert request -d /etc/dirsrv/slapd-EXAMPLE-COM -n Server-Cert -p /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt -C '/usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM' -N CN=ipa.example.com -K ldap/ipa.example.com at EXAMPLE.COM I'd do them one at a time and wait until the cert is issued and tracked. This will restart both Apache and 389-ds but it shouldn't affect operation because the certs won't be used yet. You then need to get the old CA cert and put it into the right places. Since it is already in the PKI-IPA NSS database let's fetch it from there. For giggles you should probably save whatever the contents of /etc/ipa/ca.crt are before-hand. # certutil -L -d /etc/dirsrv/slapd-PKI-IPA -n 'IPADOMAIN.COM IPA CA' -a > /etc/ipa/ca.crt Now add that to the Apache and 389-ds databases: # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/httpd/alias -t CT,C, -a -i /etc/ipa/ca.crt # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/dirsrv/slapd-EXAMPLE-COM -t CT,, -a -i /etc/ipa/ca.crt Next add it to /etc/pki/nssdb if it isn't already there: # certutil -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i /etc/ipa/ca.crt Next, verify that the newly issued certs are trusted: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias # certutil -V -u V -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM Both should return: certutil: certificate is valid Next is to configure the services to use the new certs. I'd stop IPA to do this: ipactl stop Edit /etc/httpd/conf.d/nss.conf and change the NSSNickname to Server-Cert Edit /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif and set nsSSLPersonalitySSL to Server-Cert Now try to start the world: ipactl start Run a few commands: # ipa user-show admin # ipa cert-show 1 Both should work. Assuming all has gone well to this point, copy /etc/ipa/ca.crt to /usr/share/ipa/html/ca.crt Finally run: ipa-ldap-updater --upgrade This should load the new CA certificate into LDAP. This has the potential to break a whole bunch of your clients. It is probably enough to just copy over the new CA cert to the right location(s) on the clients. The mechanics of this depend on the OS. > Are the TLS errors due to the mismatch in certs between slapd-PKI-CA and > slapd-NETWORKFLEET-COM? No, has nothing to do with the CA at all. The client doesn't have (or trust) the CA that issued the LDAP server cert. rob > > > -----Original Message----- > > > From: freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com > ] On Behalf Of Rob Crittenden > Sent: Wednesday, March 11, 2015 7:20 PM > To: sipazzo; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Need to replace cert for ipa servers > > sipazzo wrote: >> Thanks Rob, I apologize that error was probably not helpful. This is >> what I see when running install in debug mode: >> >> Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an >> IPA server Init LDAP connection with: >> ldap://ipa2-corp.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> >> The certificates are very confusing to me. I don't understand how >> things are working when we have a set of GoDaddy certs in >> slapd-NETWORKFLEET-COM and a set of the Dogtag certs in slapd-PKI-CA. >> The cert in /usr/share/ipa/html/ca.crt looks like the original one >> issued by the Dogtag cert system and matches the ones on the clients. >> Not to further confuse things but the original master server that >> signed all these certs was taken offline months ago due to some issues >> it was having. I do still have access to it if necessary. >> >> As far as why the godaddy certs were swapped out for the Dogtag certs >> it was originally for something as simple as the untrusted certificate >> dialogue when accessing the ipa gui. I did not swap out the certs so >> am unsure of exactly what happened. There is no real need to use the >> GoDaddy certs as far as I am concerned. I just want the best solution >> to the issues I am seeing as I am in kind of a bind with the GoDaddy >> cert being revoked and needing to be replaced and the master Dogtag >> certificate server offline. We have a mixed environment with Rhel 5, 6 >> and Solaris clients so are not using sssd in all cases. >> >> I know this is asking a lot but appreciate any help you can give. > > What is the current state of things? Does your IPA Apache server work? > Is 389-ds up and running? Do you have a working IPA CA? > > Does ipa cert-show 1 work? > > If the answer is yes to all then we should be able to generate new certs > for all the services. > > 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 > From jhrozek at redhat.com Thu Mar 12 20:59:37 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 12 Mar 2015 21:59:37 +0100 Subject: [Freeipa-users] OTP and cached credentials In-Reply-To: References: Message-ID: > On 12 Mar 2015, at 21:32, Rob Verduijn wrote: > > Hello, > > I was looking into otp authentication and found some articles on how to enable this in freeipa. > > I can't seem to figure out how this is going to deal with cashed credentials on a laptop that is not able to connect the ipa server. > > How is this going to work out when 'native OTP' is being used ? I'm sorry, but currently it doesn't as with the current (sssd-1.12.x) version we treat the long and one-time part as a single blob, so we can't cache it. In the next version, we'll work on prompting for and handling the short and long term parts of the authtok separately, so we'll be able to cache credentials. From g.fer.ordas at unicyber.co.uk Thu Mar 12 21:07:19 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Thu, 12 Mar 2015 22:07:19 +0100 Subject: [Freeipa-users] Windows AD --> LDAP (oneWay) In-Reply-To: References: Message-ID: <55020007.5060704@unicyber.co.uk> Hi I have successfully setup an AD---> freeipa Model and joining bits and pieces from 389-ds I have setup a oneWaySinc fromWindows. The issue I got for the last week is the pasword sync which does not seem to work at all, it does not matter what I do in the AD server I never get the passwords being transferred over. I went through many manual pages, different versions and I do not have clear if I need to run any ldapmodification at all! This will be a onewaySync and I do not want the passwords being replicated BACK to AD, also I read about the "reset" setting and I am not sure if every single password needs to be reset at all? has anybody got any sort of definitive guide or maybe a clear path to follow? Many thanks for all your help Gonzalo From rmeggins at redhat.com Thu Mar 12 21:13:57 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 12 Mar 2015 15:13:57 -0600 Subject: [Freeipa-users] Windows AD --> LDAP (oneWay) In-Reply-To: <55020007.5060704@unicyber.co.uk> References: <55020007.5060704@unicyber.co.uk> Message-ID: <55020195.8080501@redhat.com> On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote: > Hi > > I have successfully setup an AD---> freeipa Model and joining bits and > pieces from 389-ds I have setup a oneWaySinc fromWindows. > The issue I got for the last week is the pasword sync which does not > seem to work at all, it does not matter what I do in the AD server I > never get the passwords being transferred over. > I went through many manual pages, different versions and I do not have > clear if I need to run any ldapmodification at all! > This will be a onewaySync and I do not want the passwords being > replicated BACK to AD, also I read about the "reset" setting and I am > not sure if every single password needs to be reset at all? > > has anybody got any sort of definitive guide or maybe a clear path to > follow? http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync Note that you have to change a password in AD in order for it to be sync'd to freeipa. PassSync will not sync already existing password.s > > Many thanks for all your help > > Gonzalo > From g.fer.ordas at unicyber.co.uk Thu Mar 12 21:44:36 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Thu, 12 Mar 2015 22:44:36 +0100 Subject: [Freeipa-users] Windows AD --> LDAP (oneWay) In-Reply-To: <55020195.8080501@redhat.com> References: <55020007.5060704@unicyber.co.uk> <55020195.8080501@redhat.com> Message-ID: <550208C4.2080908@unicyber.co.uk> Thanks very much for the quick reply. And that was exactly the bit I never fully understood, till now. is it known anyway of synchronising the passwords? Any recommendations on those regards? Thanks On 12/03/2015 22:13, Rich Megginson wrote: > On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote: >> Hi >> >> I have successfully setup an AD---> freeipa Model and joining bits >> and pieces from 389-ds I have setup a oneWaySinc fromWindows. >> The issue I got for the last week is the pasword sync which does not >> seem to work at all, it does not matter what I do in the AD server I >> never get the passwords being transferred over. >> I went through many manual pages, different versions and I do not >> have clear if I need to run any ldapmodification at all! >> This will be a onewaySync and I do not want the passwords being >> replicated BACK to AD, also I read about the "reset" setting and I am >> not sure if every single password needs to be reset at all? >> >> has anybody got any sort of definitive guide or maybe a clear path to >> follow? > > http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync > > > Note that you have to change a password in AD in order for it to be > sync'd to freeipa. PassSync will not sync already existing password.s > >> >> Many thanks for all your help >> >> Gonzalo >> > From rmeggins at redhat.com Thu Mar 12 21:59:29 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Thu, 12 Mar 2015 15:59:29 -0600 Subject: [Freeipa-users] Windows AD --> LDAP (oneWay) In-Reply-To: <550208C4.2080908@unicyber.co.uk> References: <55020007.5060704@unicyber.co.uk> <55020195.8080501@redhat.com> <550208C4.2080908@unicyber.co.uk> Message-ID: <55020C41.9010902@redhat.com> On 03/12/2015 03:44 PM, Gonzalo Fernandez Ordas wrote: > > Thanks very much for the quick reply. And that was exactly the bit I > never fully understood, till now. > > is it known anyway of synchronising the passwords? No. > Any recommendations on those regards? Yes - use Trusts instead of sync. > > Thanks > > > > On 12/03/2015 22:13, Rich Megginson wrote: >> On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote: >>> Hi >>> >>> I have successfully setup an AD---> freeipa Model and joining bits >>> and pieces from 389-ds I have setup a oneWaySinc fromWindows. >>> The issue I got for the last week is the pasword sync which does not >>> seem to work at all, it does not matter what I do in the AD server I >>> never get the passwords being transferred over. >>> I went through many manual pages, different versions and I do not >>> have clear if I need to run any ldapmodification at all! >>> This will be a onewaySync and I do not want the passwords being >>> replicated BACK to AD, also I read about the "reset" setting and I >>> am not sure if every single password needs to be reset at all? >>> >>> has anybody got any sort of definitive guide or maybe a clear path >>> to follow? >> >> http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync >> >> >> Note that you have to change a password in AD in order for it to be >> sync'd to freeipa. PassSync will not sync already existing password.s >> >>> >>> Many thanks for all your help >>> >>> Gonzalo >>> >> > From dpal at redhat.com Thu Mar 12 22:26:29 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Mar 2015 18:26:29 -0400 Subject: [Freeipa-users] OTP and cached credentials In-Reply-To: References: Message-ID: <55021295.6040607@redhat.com> On 03/12/2015 04:59 PM, Jakub Hrozek wrote: >> On 12 Mar 2015, at 21:32, Rob Verduijn wrote: >> >> Hello, >> >> I was looking into otp authentication and found some articles on how to enable this in freeipa. >> >> I can't seem to figure out how this is going to deal with cashed credentials on a laptop that is not able to connect the ipa server. >> >> How is this going to work out when 'native OTP' is being used ? > I'm sorry, but currently it doesn't as with the current (sssd-1.12.x) version we treat the long and one-time part as a single blob, so we can't cache it. > > In the next version, we'll work on prompting for and handling the short and long term parts of the authtok separately, so we'll be able to cache credentials. > Yes. Please do not use current version for laptops. See the warning: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index.html#otp -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Mar 12 22:28:20 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 12 Mar 2015 18:28:20 -0400 Subject: [Freeipa-users] Windows AD --> LDAP (oneWay) In-Reply-To: <55020C41.9010902@redhat.com> References: <55020007.5060704@unicyber.co.uk> <55020195.8080501@redhat.com> <550208C4.2080908@unicyber.co.uk> <55020C41.9010902@redhat.com> Message-ID: <55021304.5020706@redhat.com> On 03/12/2015 05:59 PM, Rich Megginson wrote: > On 03/12/2015 03:44 PM, Gonzalo Fernandez Ordas wrote: >> >> Thanks very much for the quick reply. And that was exactly the bit I >> never fully understood, till now. >> >> is it known anyway of synchronising the passwords? > > No. > >> Any recommendations on those regards? > > Yes - use Trusts instead of sync. http://www.freeipa.org/page/Active_Directory_trust_setup > >> >> Thanks >> >> >> >> On 12/03/2015 22:13, Rich Megginson wrote: >>> On 03/12/2015 03:07 PM, Gonzalo Fernandez Ordas wrote: >>>> Hi >>>> >>>> I have successfully setup an AD---> freeipa Model and joining bits >>>> and pieces from 389-ds I have setup a oneWaySinc fromWindows. >>>> The issue I got for the last week is the pasword sync which does >>>> not seem to work at all, it does not matter what I do in the AD >>>> server I never get the passwords being transferred over. >>>> I went through many manual pages, different versions and I do not >>>> have clear if I need to run any ldapmodification at all! >>>> This will be a onewaySync and I do not want the passwords being >>>> replicated BACK to AD, also I read about the "reset" setting and I >>>> am not sure if every single password needs to be reset at all? >>>> >>>> has anybody got any sort of definitive guide or maybe a clear path >>>> to follow? >>> >>> http://www.port389.org/docs/389ds/howto/howto-windowssync.html#configuring-passsync >>> >>> >>> Note that you have to change a password in AD in order for it to be >>> sync'd to freeipa. PassSync will not sync already existing password.s >>> >>>> >>>> Many thanks for all your help >>>> >>>> Gonzalo >>>> >>> >> > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From mkosek at redhat.com Fri Mar 13 07:38:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 13 Mar 2015 08:38:25 +0100 Subject: [Freeipa-users] Migration from RHEL6 (3.0.0-42) to CentOS7 (3.3.3-28.0.1) In-Reply-To: <1426190043890.72489@vuw.ac.nz> References: <54FEEE44.8000207@opennms.org> <20150310133150.GM25455@redhat.com> <54FEF59A.7040109@opennms.org> <20150310140626.GN25455@redhat.com>, <55015644.5090800@redhat.com> <1426190043890.72489@vuw.ac.nz> Message-ID: <550293F1.6040207@redhat.com> On 03/12/2015 08:56 PM, Steven Jones wrote: > Hi, > > Currently it seems that IPA on RHEL6.6 is broken in terms of adding a > RHEL7.1 replica to it. ie following the document linked to below. > > Should be a BZ case on it shortly via RH support (RH case number 01290601) > for an updated 389 rpm for 6.6. > > I assume it will be the same for Centos 7.x as your base is RHEL6.6. > > Unless there is an already fixed 389/6.6 package somewhere I can try? Its > a test bed for the actual upgrade so if it blows no biggee, anything to get > this advanced! If I read your Case correctly, it already got a fresh set of RHEL-6.6 RPMs attached today morning :-) > > regards > > Steven > > 8><--- > >>>> Are you following these instructions? >>>> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/migrating-ipa-proc.html > >>>> > 8><--- > From andrew.holway at gmail.com Fri Mar 13 11:43:23 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 13 Mar 2015 12:43:23 +0100 Subject: [Freeipa-users] Saltstack and ipa-install on Centos7 failing Message-ID: Hallo I have a quite odd situation. I am using saltstack to set up freeipa servers on Centos 7 but I am getting the following error: failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1 Saltstack outputs the command it is trying to run: ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p password -n cloud.domain.de --setup-dns --unattended --no-forwarders However if I run this command manually on a clean machine it works fine. It works on Centos 6. I see this in the slapd error log: [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors 389-Directory/1.3.1.6 B2014.219.1825 freeipa-2.cloud.native-instruments.de:389 (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE) [13/Mar/2015:10:45:59 +0000] - Error - Unable to create /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape Portable Runtime error -5966 (Access Denied.) [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts with other slapd processes [13/Mar/2015:10:45:59 +0000] - Error - Unable to create /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape Portable Runtime error -5966 (Access Denied.) [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts with other slapd processes [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed s/NATIVE-INSTRUMENTS/DOMAIN/g 389-Directory/1.3.1.6 B2014.219.1825 freeipa-2.cloud.native-instruments.de:389 (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE) [13/Mar/2015:10:45:59 +0000] - Error - Unable to create /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime error -5966 (Access Denied.) [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts with other slapd processes [13/Mar/2015:10:45:59 +0000] - Error - Unable to create /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime error -5966 (Access Denied.) [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts with other slapd processes ipaserver-install.log 015-03-13T10:45:57Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:57Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2015-03-13T10:45:57Z DEBUG httpd is not configured 2015-03-13T10:45:57Z DEBUG kadmin is not configured 2015-03-13T10:45:57Z DEBUG dirsrv is not configured 2015-03-13T10:45:57Z DEBUG pki-cad is not configured 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured 2015-03-13T10:45:57Z DEBUG install is not configured 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured 2015-03-13T10:45:57Z DEBUG ntpd is not configured 2015-03-13T10:45:57Z DEBUG named is not configured 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured 2015-03-13T10:45:57Z DEBUG filestore is tracking no files 2015-03-13T10:45:57Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' 2015-03-13T10:45:57Z 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': True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax': 0, 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, 'unattended': True, 'trust_sshfp': False, 'external_ca_file': None, 'no_host_dns': False, 'http_pkcs12': None, 'realm_name': 'CLOUD.DOMAIN.DE', 'forwarders': None, 'idstart': 1544400000, 'external_ca': False, 'ip_address': None, 'conf_ssh': True, 'zonemgr': None, 'root_ca_file': None, 'setup_dns': True, 'host_name': None, 'debug': False, 'external_cert_file': None, 'uninstall': False} 2015-03-13T10:45:57Z DEBUG missing options might be asked for interactively later 2015-03-13T10:45:57Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2015-03-13T10:45:57Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:57Z DEBUG Starting external process 2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 2015-03-13T10:45:57Z DEBUG stdout=enabled 2015-03-13T10:45:57Z DEBUG stderr= 2015-03-13T10:45:57Z DEBUG Starting external process 2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration: *:8443 is a NameVirtualHost default server freeipa-2.cloud.domain.de (/etc/httpd/conf.d/nss.conf:86) port 8443 namevhost freeipa-2.cloud.domain.de (/etc/httpd/conf.d/nss.conf:86) port 8443 namevhost freeipa-2.cloud.domain.de (/etc/httpd/conf.d/nss.conf:86) 2015-03-13T10:45:57Z DEBUG stderr= 2015-03-13T10:45:57Z DEBUG Check if freeipa-2.cloud.domain.de is a primary hostname for localhost 2015-03-13T10:45:57Z DEBUG Primary hostname for localhost: freeipa-2.cloud.domain.de 2015-03-13T10:45:57Z DEBUG will use host_name: freeipa-2.cloud.domain.de 2015-03-13T10:45:57Z DEBUG Starting external process 2015-03-13T10:45:57Z DEBUG args=/sbin/ip -family inet -oneline address show 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 2015-03-13T10:45:57Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host lo\ valid_lft forever preferred_lft forever 2: eth0 inet 10.16.1.100/24 brd 10.16.1.255 scope global dynamic eth0\ valid_lft 2770sec preferred_lft 2770sec 2015-03-13T10:45:57Z DEBUG stderr= 2015-03-13T10:45:57Z DEBUG will use dns_forwarders: () 2015-03-13T10:45:57Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'... 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' 2015-03-13T10:45:57Z DEBUG Starting external process 2015-03-13T10:45:57Z DEBUG args=klist -V 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 2015-03-13T10:45:57Z DEBUG stdout=Kerberos 5 version 1.11.3 2015-03-13T10:45:57Z DEBUG stderr= 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' 2015-03-13T10:45:57Z DEBUG importing all plugin modules in '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_anonymous_aci.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' 2015-03-13T10:45:57Z DEBUG importing plugin module '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' 2015-03-13T10:45:58Z DEBUG Adding DS group dirsrv 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/groupadd -r dirsrv 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout= 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG Done adding DS group 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled chronyd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout=enabled 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active chronyd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout=active 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:58Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop chronyd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout= 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl disable chronyd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout= 2015-03-13T10:45:58Z DEBUG stderr=rm '/etc/systemd/system/multi-user.target.wants/chronyd.service' 2015-03-13T10:45:58Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:58Z DEBUG Configuring NTP daemon (ntpd) 2015-03-13T10:45:58Z DEBUG [1/4]: stopping ntpd 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=3 2015-03-13T10:45:58Z DEBUG stdout=unknown 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop ntpd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout= 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG duration: 0 seconds 2015-03-13T10:45:58Z DEBUG [2/4]: writing configuration 2015-03-13T10:45:58Z DEBUG Backing up system configuration file '/etc/ntp.conf' 2015-03-13T10:45:58Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2015-03-13T10:45:58Z DEBUG Backing up system configuration file '/etc/sysconfig/ntpd' 2015-03-13T10:45:58Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2015-03-13T10:45:58Z DEBUG duration: 0 seconds 2015-03-13T10:45:58Z DEBUG [3/4]: configuring ntpd to start on boot 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled ntpd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=1 2015-03-13T10:45:58Z DEBUG stdout=disabled 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl enable ntpd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout= 2015-03-13T10:45:58Z DEBUG stderr=ln -s '/usr/lib/systemd/system/ntpd.service' '/etc/systemd/system/multi-user.target.wants/ntpd.service' 2015-03-13T10:45:58Z DEBUG duration: 0 seconds 2015-03-13T10:45:58Z DEBUG [4/4]: starting ntpd 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl start ntpd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout= 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout=active 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG duration: 0 seconds 2015-03-13T10:45:58Z DEBUG Done configuring NTP daemon (ntpd). 2015-03-13T10:45:58Z DEBUG Loading StateFile from '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:58Z DEBUG Configuring directory server (dirsrv): Estimated time 1 minute 2015-03-13T10:45:58Z DEBUG [1/38]: creating directory server user 2015-03-13T10:45:58Z DEBUG Adding DS user dirsrv 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/useradd -g dirsrv -c DS System User -d /var/lib/dirsrv -s /sbin/nologin -M -r dirsrv 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 2015-03-13T10:45:58Z DEBUG stdout= 2015-03-13T10:45:58Z DEBUG stderr= 2015-03-13T10:45:58Z DEBUG Done adding DS user 2015-03-13T10:45:58Z DEBUG duration: 0 seconds 2015-03-13T10:45:58Z DEBUG [2/38]: creating directory server instance 2015-03-13T10:45:58Z DEBUG Saving StateFile to '/var/lib/ipa/sysrestore/sysrestore.state' 2015-03-13T10:45:58Z DEBUG Backing up system configuration file '/etc/sysconfig/dirsrv' 2015-03-13T10:45:58Z DEBUG Saving Index File to '/var/lib/ipa/sysrestore/sysrestore.index' 2015-03-13T10:45:58Z DEBUG dn: dc=cloud,dc=domain,dc=de objectClass: top objectClass: domain objectClass: pilotObject dc: cloud info: IPA V2.0 2015-03-13T10:45:58Z DEBUG writing inf template 2015-03-13T10:45:58Z DEBUG [General] FullMachineName= freeipa-2.cloud.domain.de SuiteSpotUserID= dirsrv SuiteSpotGroup= dirsrv ServerRoot= /usr/lib64/dirsrv [slapd] ServerPort= 389 ServerIdentifier= CLOUD-DOMAIN-DE Suffix= dc=cloud,dc=domain,dc=de RootDN= cn=Directory Manager InstallLdifFile= /var/lib/dirsrv/boot.ldif inst_dir= /var/lib/dirsrv/scripts-CLOUD-DOMAIN-DE 2015-03-13T10:45:58Z DEBUG calling setup-ds.pl 2015-03-13T10:45:58Z DEBUG Starting external process 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD 2015-03-13T10:45:59Z DEBUG Process finished, return code=1 2015-03-13T10:45:59Z DEBUG stdout=[15/03/13:10:45:59] - [Setup] Info Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. Output: importing data ... [13/Mar/2015:10:45:59 +0000] - Error - Unable to create /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime error -5966 (Access Denied.) [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts with other slapd processes Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. Output: importing data ... [13/Mar/2015:10:45:59 +0000] - Error - Unable to create /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime error -5966 (Access Denied.) [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts with other slapd processes [15/03/13:10:45:59] - [Setup] Fatal Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. [15/03/13:10:45:59] - [Setup] Fatal Exiting . . . Log file is '-' Exiting . . . Log file is '-' 2015-03-13T10:45:59Z DEBUG stderr= 2015-03-13T10:45:59Z CRITICAL failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1 2015-03-13T10:45:59Z DEBUG restarting ds instance 2015-03-13T10:45:59Z DEBUG Starting external process 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl --system daemon-reload 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 2015-03-13T10:45:59Z DEBUG stdout= 2015-03-13T10:45:59Z DEBUG stderr= 2015-03-13T10:45:59Z DEBUG Starting external process 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl restart dirsrv at CLOUD-DOMAIN-DE.service 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 2015-03-13T10:45:59Z DEBUG stdout= 2015-03-13T10:45:59Z DEBUG stderr= 2015-03-13T10:45:59Z DEBUG Starting external process 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl is-active dirsrv at CLOUD-DOMAIN-DE.service 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 2015-03-13T10:45:59Z DEBUG stdout=active 2015-03-13T10:45:59Z DEBUG stderr= 2015-03-13T10:45:59Z DEBUG wait_for_open_ports: localhost [389] timeout 300 2015-03-13T10:50:59Z CRITICAL Failed to restart the directory server (). See the installation log for details. 2015-03-13T10:50:59Z DEBUG done restarting ds instance 2015-03-13T10:50:59Z DEBUG duration: 301 seconds 2015-03-13T10:50:59Z DEBUG [3/38]: adding default schema 2015-03-13T10:50:59Z DEBUG duration: 0 seconds 2015-03-13T10:50:59Z DEBUG [4/38]: enabling memberof plugin 2015-03-13T10:50:59Z DEBUG wait_for_open_ports: freeipa-2.cloud.domain.de [389] timeout 10 2015-03-13T10:51:09Z DEBUG Could not connect to the Directory Server on freeipa-2.cloud.domain.de: 2015-03-13T10:51:09Z 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-server-install", line 1059, in main hbac_allow=not options.hbac_allow) File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line 323, in create_instance self.start_creation(runtime=60) 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/dsinstance.py", line 501, in __add_memberof_module self._ldap_mod("memberof-conf.ldif") File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 152, in _ldap_mod self.ldap_connect() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 99, in ldap_connect conn.do_simple_bind(bindpw=self.dm_password) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1735, in do_simple_bind self.__bind_with_wait(self.conn.simple_bind_s, timeout, binddn, bindpw) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1730, in __bind_with_wait self.__wait_for_connection(timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1719, in __wait_for_connection wait_for_open_ports(host, int(port), timeout) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1096, in wait_for_open_ports raise socket.timeout() 2015-03-13T10:51:09Z DEBUG The ipa-server-install command failed, exception: timeout: -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 13 13:15:51 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Mar 2015 09:15:51 -0400 Subject: [Freeipa-users] Saltstack and ipa-install on Centos7 failing In-Reply-To: References: Message-ID: <5502E307.4030200@redhat.com> On 03/13/2015 07:43 AM, Andrew Holway wrote: > Hallo > > I have a quite odd situation. I am using saltstack to set up freeipa > servers on Centos 7 but I am getting the following error: > > failed to create ds instance Command '/usr/sbin/setup-ds.pl > --silent --logfile - -f /tmp/tmp5witgD' returned > non-zero exit status 1 > > Saltstack outputs the command it is trying to run: > > ipa-server-install -a password --realm CLOUD.DOMAIN.DE > -P password -p password -n cloud.domain.de > --setup-dns --unattended --no-forwarders > > However if I run this command manually on a clean machine it works fine. > > It works on Centos 6. It usually means that you have different privileges and context when you are running command manually and via SaltStack. There is probably a different user and a different SELinux context. Do you see any AVC denials? It really seems that you have two DS instances going on the same machine. I suspewt that when run manually as root you sort of override the lock and things go through but when you do it via SaltStack it is different. Why do you need two DS instances? > > > > I see this in the slapd error log: > > [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors > 389-Directory/1.3.1.6 B2014.219.1825 > freeipa-2.cloud.native-instruments.de:389 > > (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE) > > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape > Portable Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape > Portable Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed > s/NATIVE-INSTRUMENTS/DOMAIN/g > 389-Directory/1.3.1.6 B2014.219.1825 > freeipa-2.cloud.native-instruments.de:389 > > (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE) > > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable > Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable > Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > > > > > > > ipaserver-install.log > > 015-03-13T10:45:57Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z DEBUG httpd is not configured > 2015-03-13T10:45:57Z DEBUG kadmin is not configured > 2015-03-13T10:45:57Z DEBUG dirsrv is not configured > 2015-03-13T10:45:57Z DEBUG pki-cad is not configured > 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured > 2015-03-13T10:45:57Z DEBUG install is not configured > 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured > 2015-03-13T10:45:57Z DEBUG ntpd is not configured > 2015-03-13T10:45:57Z DEBUG named is not configured > 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured > 2015-03-13T10:45:57Z DEBUG filestore is tracking no files > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z 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': True, 'ui_redirect': True, 'domain_name': > 'cloud.domain.de ', 'idmax': 0, 'hbac_allow': > False, 'no_reverse': False, 'dirsrv_pkcs12': None, 'unattended': True, > 'trust_sshfp': False, 'external_ca_file': None, 'no_host_dns': False, > 'http_pkcs12': None, 'realm_name': 'CLOUD.DOMAIN.DE > ', 'forwarders': None, 'idstart': 1544400000, > 'external_ca': False, 'ip_address': None, 'conf_ssh': True, 'zonemgr': > None, 'root_ca_file': None, 'setup_dns': True, 'host_name': None, > 'debug': False, 'external_cert_file': None, 'uninstall': False} > 2015-03-13T10:45:57Z DEBUG missing options might be asked for > interactively later > > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=enabled > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration: > *:8443 is a NameVirtualHost > default server freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > port 8443 namevhost freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > port 8443 namevhost freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG Check if freeipa-2.cloud.domain.de > is a primary hostname for localhost > 2015-03-13T10:45:57Z DEBUG Primary hostname for localhost: > freeipa-2.cloud.domain.de > 2015-03-13T10:45:57Z DEBUG will use host_name: > freeipa-2.cloud.domain.de > > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/sbin/ip -family inet -oneline address > show > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=1: lo inet 127.0.0.1/8 > scope host lo\ valid_lft forever > preferred_lft forever > 2: eth0 inet 10.16.1.100/24 brd 10.16.1.255 > scope global dynamic eth0\ valid_lft 2770sec preferred_lft 2770sec > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG will use dns_forwarders: () > > 2015-03-13T10:45:57Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipalib/plugins'... > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=klist -V > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=Kerberos 5 version 1.11.3 > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' > 2015-03-13T10:45:57Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_anonymous_aci.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' > 2015-03-13T10:45:58Z DEBUG Adding DS group dirsrv > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/groupadd -r dirsrv > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Done adding DS group > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=enabled > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=active > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl disable chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr=rm > '/etc/systemd/system/multi-user.target.wants/chronyd.service' > > 2015-03-13T10:45:58Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Configuring NTP daemon (ntpd) > 2015-03-13T10:45:58Z DEBUG [1/4]: stopping ntpd > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=3 > 2015-03-13T10:45:58Z DEBUG stdout=unknown > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [2/4]: writing configuration > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/ntp.conf' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/sysconfig/ntpd' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [3/4]: configuring ntpd to start on boot > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=1 > 2015-03-13T10:45:58Z DEBUG stdout=disabled > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl enable ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr=ln -s > '/usr/lib/systemd/system/ntpd.service' > '/etc/systemd/system/multi-user.target.wants/ntpd.service' > > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [4/4]: starting ntpd > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl start ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=active > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG Done configuring NTP daemon (ntpd). > 2015-03-13T10:45:58Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Configuring directory server (dirsrv): > Estimated time 1 minute > 2015-03-13T10:45:58Z DEBUG [1/38]: creating directory server user > 2015-03-13T10:45:58Z DEBUG Adding DS user dirsrv > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/useradd -g dirsrv -c DS > System User -d /var/lib/dirsrv -s /sbin/nologin -M -r dirsrv > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Done adding DS user > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [2/38]: creating directory server instance > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/sysconfig/dirsrv' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG > dn: dc=cloud,dc=domain,dc=de > objectClass: top > objectClass: domain > objectClass: pilotObject > dc: cloud > info: IPA V2.0 > > 2015-03-13T10:45:58Z DEBUG writing inf template > 2015-03-13T10:45:58Z DEBUG > [General] > FullMachineName= freeipa-2.cloud.domain.de > > SuiteSpotUserID= dirsrv > SuiteSpotGroup= dirsrv > ServerRoot= /usr/lib64/dirsrv > [slapd] > ServerPort= 389 > ServerIdentifier= CLOUD-DOMAIN-DE > Suffix= dc=cloud,dc=domain,dc=de > RootDN= cn=Directory Manager > InstallLdifFile= /var/lib/dirsrv/boot.ldif > inst_dir= /var/lib/dirsrv/scripts-CLOUD-DOMAIN-DE > > 2015-03-13T10:45:58Z DEBUG calling setup-ds.pl > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/setup-ds.pl > --silent --logfile - -f /tmp/tmp5witgD > 2015-03-13T10:45:59Z DEBUG Process finished, return code=1 > 2015-03-13T10:45:59Z DEBUG stdout=[15/03/13:10:45:59] - [Setup] Info > Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. > Output: importing data ... > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable > Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. > Output: importing data ... > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable > Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > [15/03/13:10:45:59] - [Setup] Fatal Error: Could not create directory > server instance 'CLOUD-DOMAIN-DE'. > Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. > [15/03/13:10:45:59] - [Setup] Fatal Exiting . . . > Log file is '-' > > Exiting . . . > Log file is '-' > > > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z CRITICAL failed to create ds instance Command > '/usr/sbin/setup-ds.pl --silent --logfile - -f > /tmp/tmp5witgD' returned non-zero exit status 1 > 2015-03-13T10:45:59Z DEBUG restarting ds instance > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl --system daemon-reload > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout= > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl restart > dirsrv at CLOUD-DOMAIN-DE.service > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout= > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl is-active > dirsrv at CLOUD-DOMAIN-DE.service > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout=active > > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG wait_for_open_ports: localhost [389] > timeout 300 > 2015-03-13T10:50:59Z CRITICAL Failed to restart the directory server > (). See the installation log for details. > 2015-03-13T10:50:59Z DEBUG done restarting ds instance > 2015-03-13T10:50:59Z DEBUG duration: 301 seconds > 2015-03-13T10:50:59Z DEBUG [3/38]: adding default schema > 2015-03-13T10:50:59Z DEBUG duration: 0 seconds > 2015-03-13T10:50:59Z DEBUG [4/38]: enabling memberof plugin > 2015-03-13T10:50:59Z DEBUG wait_for_open_ports: > freeipa-2.cloud.domain.de [389] > timeout 10 > 2015-03-13T10:51:09Z DEBUG Could not connect to the Directory Server > on freeipa-2.cloud.domain.de : > 2015-03-13T10:51:09Z 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-server-install", line 1059, in main > hbac_allow=not options.hbac_allow) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 323, in create_instance > self.start_creation(runtime=60) > > 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/dsinstance.py", > line 501, in __add_memberof_module > self._ldap_mod("memberof-conf.ldif") > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 152, in _ldap_mod > self.ldap_connect() > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 99, in ldap_connect > conn.do_simple_bind(bindpw=self.dm_password) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1735, in do_simple_bind > self.__bind_with_wait(self.conn.simple_bind_s, timeout, binddn, > bindpw) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1730, in __bind_with_wait > self.__wait_for_connection(timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1719, in __wait_for_connection > wait_for_open_ports(host, int(port), timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line > 1096, in wait_for_open_ports > raise socket.timeout() > > 2015-03-13T10:51:09Z DEBUG The ipa-server-install command failed, > exception: timeout: > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Fri Mar 13 14:24:23 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 13 Mar 2015 15:24:23 +0100 Subject: [Freeipa-users] Saltstack and ipa-install on Centos7 failing In-Reply-To: <5502E307.4030200@redhat.com> References: <5502E307.4030200@redhat.com> Message-ID: Hi Dimitri type=AVC msg=audit(1426243559.181:623): avc: *denied* { create } for pid=2740 comm="ns-slapd" name="imports" scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir type=AVC msg=audit(1426243559.388:625): avc: *denied* { create } for pid=2754 comm="ns-slapd" name="imports" scontext=system_u:system_r:dirsrv_t:s0 tcontext=system_u:object_r:var_lock_t:s0 tclass=dir I cant find the name of the tool that scans the audit log and proposes boolean changes. So much of this stuff seems to be GUI tools. On 13 March 2015 at 14:15, Dmitri Pal wrote: > On 03/13/2015 07:43 AM, Andrew Holway wrote: > > Hallo > > I have a quite odd situation. I am using saltstack to set up freeipa > servers on Centos 7 but I am getting the following error: > > failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent > --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1 > > Saltstack outputs the command it is trying to run: > > ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p > password -n cloud.domain.de --setup-dns --unattended --no-forwarders > > However if I run this command manually on a clean machine it works fine. > > It works on Centos 6. > > > > It usually means that you have different privileges and context when you > are running command manually and via SaltStack. > There is probably a different user and a different SELinux context. > Do you see any AVC denials? > > It really seems that you have two DS instances going on the same machine. > I suspewt that when run manually as root you sort of override the lock and > things go through but when you do it via SaltStack it is different. > > Why do you need two DS instances? > > > > > > I see this in the slapd error log: > > [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors > 389-Directory/1.3.1.6 B2014.219.1825 > freeipa-2.cloud.native-instruments.de:389 > (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE) > > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape > Portable Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape > Portable Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed > s/NATIVE-INSTRUMENTS/DOMAIN/g > 389-Directory/1.3.1.6 B2014.219.1825 > freeipa-2.cloud.native-instruments.de:389 > (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE) > > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime > error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime > error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > > > > > > > ipaserver-install.log > > 015-03-13T10:45:57Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z DEBUG httpd is not configured > 2015-03-13T10:45:57Z DEBUG kadmin is not configured > 2015-03-13T10:45:57Z DEBUG dirsrv is not configured > 2015-03-13T10:45:57Z DEBUG pki-cad is not configured > 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured > 2015-03-13T10:45:57Z DEBUG install is not configured > 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured > 2015-03-13T10:45:57Z DEBUG ntpd is not configured > 2015-03-13T10:45:57Z DEBUG named is not configured > 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured > 2015-03-13T10:45:57Z DEBUG filestore is tracking no files > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z 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': > True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax': 0, > 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, > 'unattended': True, 'trust_sshfp': False, 'external_ca_file': None, > 'no_host_dns': False, 'http_pkcs12': None, 'realm_name': 'CLOUD.DOMAIN.DE', > 'forwarders': None, 'idstart': 1544400000, 'external_ca': False, > 'ip_address': None, 'conf_ssh': True, 'zonemgr': None, 'root_ca_file': > None, 'setup_dns': True, 'host_name': None, 'debug': False, > 'external_cert_file': None, 'uninstall': False} > 2015-03-13T10:45:57Z DEBUG missing options might be asked for > interactively later > > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=enabled > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration: > *:8443 is a NameVirtualHost > default server freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > port 8443 namevhost freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > port 8443 namevhost freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG Check if freeipa-2.cloud.domain.de is a > primary hostname for localhost > 2015-03-13T10:45:57Z DEBUG Primary hostname for localhost: > freeipa-2.cloud.domain.de > 2015-03-13T10:45:57Z DEBUG will use host_name: freeipa-2.cloud.domain.de > > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/sbin/ip -family inet -oneline address show > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host > lo\ valid_lft forever preferred_lft forever > 2: eth0 inet 10.16.1.100/24 brd 10.16.1.255 scope global dynamic eth0\ > valid_lft 2770sec preferred_lft 2770sec > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG will use dns_forwarders: () > > 2015-03-13T10:45:57Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipalib/plugins'... > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=klist -V > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=Kerberos 5 version 1.11.3 > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' > 2015-03-13T10:45:57Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_anonymous_aci.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' > 2015-03-13T10:45:58Z DEBUG Adding DS group dirsrv > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/groupadd -r dirsrv > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Done adding DS group > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=enabled > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=active > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl disable chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr=rm > '/etc/systemd/system/multi-user.target.wants/chronyd.service' > > 2015-03-13T10:45:58Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Configuring NTP daemon (ntpd) > 2015-03-13T10:45:58Z DEBUG [1/4]: stopping ntpd > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=3 > 2015-03-13T10:45:58Z DEBUG stdout=unknown > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [2/4]: writing configuration > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/ntp.conf' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/sysconfig/ntpd' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [3/4]: configuring ntpd to start on boot > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=1 > 2015-03-13T10:45:58Z DEBUG stdout=disabled > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl enable ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr=ln -s > '/usr/lib/systemd/system/ntpd.service' > '/etc/systemd/system/multi-user.target.wants/ntpd.service' > > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [4/4]: starting ntpd > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl start ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=active > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG Done configuring NTP daemon (ntpd). > 2015-03-13T10:45:58Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Configuring directory server (dirsrv): > Estimated time 1 minute > 2015-03-13T10:45:58Z DEBUG [1/38]: creating directory server user > 2015-03-13T10:45:58Z DEBUG Adding DS user dirsrv > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/useradd -g dirsrv -c DS System > User -d /var/lib/dirsrv -s /sbin/nologin -M -r dirsrv > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Done adding DS user > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [2/38]: creating directory server instance > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/sysconfig/dirsrv' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG > dn: dc=cloud,dc=domain,dc=de > objectClass: top > objectClass: domain > objectClass: pilotObject > dc: cloud > info: IPA V2.0 > > 2015-03-13T10:45:58Z DEBUG writing inf template > 2015-03-13T10:45:58Z DEBUG > [General] > FullMachineName= freeipa-2.cloud.domain.de > SuiteSpotUserID= dirsrv > SuiteSpotGroup= dirsrv > ServerRoot= /usr/lib64/dirsrv > [slapd] > ServerPort= 389 > ServerIdentifier= CLOUD-DOMAIN-DE > Suffix= dc=cloud,dc=domain,dc=de > RootDN= cn=Directory Manager > InstallLdifFile= /var/lib/dirsrv/boot.ldif > inst_dir= /var/lib/dirsrv/scripts-CLOUD-DOMAIN-DE > > 2015-03-13T10:45:58Z DEBUG calling setup-ds.pl > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile > - -f /tmp/tmp5witgD > 2015-03-13T10:45:59Z DEBUG Process finished, return code=1 > 2015-03-13T10:45:59Z DEBUG stdout=[15/03/13:10:45:59] - [Setup] Info Could > not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. Output: > importing data ... > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime > error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. > Output: importing data ... > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime > error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > [15/03/13:10:45:59] - [Setup] Fatal Error: Could not create directory > server instance 'CLOUD-DOMAIN-DE'. > Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. > [15/03/13:10:45:59] - [Setup] Fatal Exiting . . . > Log file is '-' > > Exiting . . . > Log file is '-' > > > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z CRITICAL failed to create ds instance Command > '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD' returned > non-zero exit status 1 > 2015-03-13T10:45:59Z DEBUG restarting ds instance > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl --system daemon-reload > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout= > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl restart > dirsrv at CLOUD-DOMAIN-DE.service > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout= > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl is-active > dirsrv at CLOUD-DOMAIN-DE.service > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout=active > > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG wait_for_open_ports: localhost [389] timeout 300 > 2015-03-13T10:50:59Z CRITICAL Failed to restart the directory server (). > See the installation log for details. > 2015-03-13T10:50:59Z DEBUG done restarting ds instance > 2015-03-13T10:50:59Z DEBUG duration: 301 seconds > 2015-03-13T10:50:59Z DEBUG [3/38]: adding default schema > 2015-03-13T10:50:59Z DEBUG duration: 0 seconds > 2015-03-13T10:50:59Z DEBUG [4/38]: enabling memberof plugin > 2015-03-13T10:50:59Z DEBUG wait_for_open_ports: freeipa-2.cloud.domain.de > [389] timeout 10 > 2015-03-13T10:51:09Z DEBUG Could not connect to the Directory Server on > freeipa-2.cloud.domain.de: > 2015-03-13T10:51:09Z 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-server-install", line 1059, in main > hbac_allow=not options.hbac_allow) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line > 323, in create_instance > self.start_creation(runtime=60) > > 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/dsinstance.py", line > 501, in __add_memberof_module > self._ldap_mod("memberof-conf.ldif") > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 152, in _ldap_mod > self.ldap_connect() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 99, in ldap_connect > conn.do_simple_bind(bindpw=self.dm_password) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1735, in do_simple_bind > self.__bind_with_wait(self.conn.simple_bind_s, timeout, binddn, bindpw) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1730, in __bind_with_wait > self.__wait_for_connection(timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line > 1719, in __wait_for_connection > wait_for_open_ports(host, int(port), timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line > 1096, in wait_for_open_ports > raise socket.timeout() > > 2015-03-13T10:51:09Z DEBUG The ipa-server-install command failed, > exception: timeout: > > > > > -- > 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 andrew.holway at gmail.com Fri Mar 13 14:25:53 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 13 Mar 2015 15:25:53 +0100 Subject: [Freeipa-users] Saltstack and ipa-install on Centos7 failing In-Reply-To: References: <5502E307.4030200@redhat.com> Message-ID: Old bug report - https://bugzilla.redhat.com/show_bug.cgi?format=multiple&id=959953 On 13 March 2015 at 15:24, Andrew Holway wrote: > Hi Dimitri > > type=AVC msg=audit(1426243559.181:623): avc: *denied* { create } for > pid=2740 comm="ns-slapd" name="imports" > scontext=system_u:system_r:dirsrv_t:s0 > tcontext=system_u:object_r:var_lock_t:s0 tclass=dir > > type=AVC msg=audit(1426243559.388:625): avc: *denied* { create } for > pid=2754 comm="ns-slapd" name="imports" > scontext=system_u:system_r:dirsrv_t:s0 > tcontext=system_u:object_r:var_lock_t:s0 tclass=dir > I cant find the name of the tool that scans the audit log and proposes > boolean changes. So much of this stuff seems to be GUI tools. > > > On 13 March 2015 at 14:15, Dmitri Pal wrote: > >> On 03/13/2015 07:43 AM, Andrew Holway wrote: >> >> Hallo >> >> I have a quite odd situation. I am using saltstack to set up freeipa >> servers on Centos 7 but I am getting the following error: >> >> failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent >> --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1 >> >> Saltstack outputs the command it is trying to run: >> >> ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p >> password -n cloud.domain.de --setup-dns --unattended --no-forwarders >> >> However if I run this command manually on a clean machine it works fine. >> >> It works on Centos 6. >> >> >> >> It usually means that you have different privileges and context when you >> are running command manually and via SaltStack. >> There is probably a different user and a different SELinux context. >> Do you see any AVC denials? >> >> It really seems that you have two DS instances going on the same machine. >> I suspewt that when run manually as root you sort of override the lock and >> things go through but when you do it via SaltStack it is different. >> >> Why do you need two DS instances? >> >> >> >> >> >> I see this in the slapd error log: >> >> [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors >> 389-Directory/1.3.1.6 B2014.219.1825 >> freeipa-2.cloud.native-instruments.de:389 >> (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE) >> >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape >> Portable Runtime error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape >> Portable Runtime error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed >> s/NATIVE-INSTRUMENTS/DOMAIN/g >> 389-Directory/1.3.1.6 B2014.219.1825 >> freeipa-2.cloud.native-instruments.de:389 >> (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE) >> >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >> error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >> error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> >> >> >> >> >> >> >> ipaserver-install.log >> >> 015-03-13T10:45:57Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:57Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:57Z DEBUG httpd is not configured >> 2015-03-13T10:45:57Z DEBUG kadmin is not configured >> 2015-03-13T10:45:57Z DEBUG dirsrv is not configured >> 2015-03-13T10:45:57Z DEBUG pki-cad is not configured >> 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured >> 2015-03-13T10:45:57Z DEBUG install is not configured >> 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured >> 2015-03-13T10:45:57Z DEBUG ntpd is not configured >> 2015-03-13T10:45:57Z DEBUG named is not configured >> 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured >> 2015-03-13T10:45:57Z DEBUG filestore is tracking no files >> 2015-03-13T10:45:57Z DEBUG Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> 2015-03-13T10:45:57Z 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': >> True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax': 0, >> 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, >> 'unattended': True, 'trust_sshfp': False, 'external_ca_file': None, >> 'no_host_dns': False, 'http_pkcs12': None, 'realm_name': 'CLOUD.DOMAIN.DE', >> 'forwarders': None, 'idstart': 1544400000, 'external_ca': False, >> 'ip_address': None, 'conf_ssh': True, 'zonemgr': None, 'root_ca_file': >> None, 'setup_dns': True, 'host_name': None, 'debug': False, >> 'external_cert_file': None, 'uninstall': False} >> 2015-03-13T10:45:57Z DEBUG missing options might be asked for >> interactively later >> >> 2015-03-13T10:45:57Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:57Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:57Z DEBUG Starting external process >> 2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service >> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:57Z DEBUG stdout=enabled >> >> 2015-03-13T10:45:57Z DEBUG stderr= >> 2015-03-13T10:45:57Z DEBUG Starting external process >> 2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS >> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration: >> *:8443 is a NameVirtualHost >> default server freeipa-2.cloud.domain.de >> (/etc/httpd/conf.d/nss.conf:86) >> port 8443 namevhost freeipa-2.cloud.domain.de >> (/etc/httpd/conf.d/nss.conf:86) >> port 8443 namevhost freeipa-2.cloud.domain.de >> (/etc/httpd/conf.d/nss.conf:86) >> >> 2015-03-13T10:45:57Z DEBUG stderr= >> 2015-03-13T10:45:57Z DEBUG Check if freeipa-2.cloud.domain.de is a >> primary hostname for localhost >> 2015-03-13T10:45:57Z DEBUG Primary hostname for localhost: >> freeipa-2.cloud.domain.de >> 2015-03-13T10:45:57Z DEBUG will use host_name: freeipa-2.cloud.domain.de >> >> 2015-03-13T10:45:57Z DEBUG Starting external process >> 2015-03-13T10:45:57Z DEBUG args=/sbin/ip -family inet -oneline address >> show >> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:57Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host >> lo\ valid_lft forever preferred_lft forever >> 2: eth0 inet 10.16.1.100/24 brd 10.16.1.255 scope global dynamic >> eth0\ valid_lft 2770sec preferred_lft 2770sec >> >> 2015-03-13T10:45:57Z DEBUG stderr= >> 2015-03-13T10:45:57Z DEBUG will use dns_forwarders: () >> >> 2015-03-13T10:45:57Z DEBUG importing all plugin modules in >> '/usr/lib/python2.7/site-packages/ipalib/plugins'... >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' >> 2015-03-13T10:45:57Z DEBUG Starting external process >> 2015-03-13T10:45:57Z DEBUG args=klist -V >> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:57Z DEBUG stdout=Kerberos 5 version 1.11.3 >> >> 2015-03-13T10:45:57Z DEBUG stderr= >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' >> 2015-03-13T10:45:57Z DEBUG importing all plugin modules in >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_anonymous_aci.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >> 2015-03-13T10:45:58Z DEBUG Adding DS group dirsrv >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/groupadd -r dirsrv >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Done adding DS group >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled chronyd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout=enabled >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active chronyd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout=active >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop chronyd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl disable chronyd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr=rm >> '/etc/systemd/system/multi-user.target.wants/chronyd.service' >> >> 2015-03-13T10:45:58Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Configuring NTP daemon (ntpd) >> 2015-03-13T10:45:58Z DEBUG [1/4]: stopping ntpd >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=3 >> 2015-03-13T10:45:58Z DEBUG stdout=unknown >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG [2/4]: writing configuration >> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >> '/etc/ntp.conf' >> 2015-03-13T10:45:58Z DEBUG Saving Index File to >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >> '/etc/sysconfig/ntpd' >> 2015-03-13T10:45:58Z DEBUG Saving Index File to >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG [3/4]: configuring ntpd to start on boot >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=1 >> 2015-03-13T10:45:58Z DEBUG stdout=disabled >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl enable ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr=ln -s >> '/usr/lib/systemd/system/ntpd.service' >> '/etc/systemd/system/multi-user.target.wants/ntpd.service' >> >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG [4/4]: starting ntpd >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl start ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout=active >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG Done configuring NTP daemon (ntpd). >> 2015-03-13T10:45:58Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Configuring directory server (dirsrv): >> Estimated time 1 minute >> 2015-03-13T10:45:58Z DEBUG [1/38]: creating directory server user >> 2015-03-13T10:45:58Z DEBUG Adding DS user dirsrv >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/useradd -g dirsrv -c DS System >> User -d /var/lib/dirsrv -s /sbin/nologin -M -r dirsrv >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Done adding DS user >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG [2/38]: creating directory server instance >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >> '/etc/sysconfig/dirsrv' >> 2015-03-13T10:45:58Z DEBUG Saving Index File to >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:58Z DEBUG >> dn: dc=cloud,dc=domain,dc=de >> objectClass: top >> objectClass: domain >> objectClass: pilotObject >> dc: cloud >> info: IPA V2.0 >> >> 2015-03-13T10:45:58Z DEBUG writing inf template >> 2015-03-13T10:45:58Z DEBUG >> [General] >> FullMachineName= freeipa-2.cloud.domain.de >> SuiteSpotUserID= dirsrv >> SuiteSpotGroup= dirsrv >> ServerRoot= /usr/lib64/dirsrv >> [slapd] >> ServerPort= 389 >> ServerIdentifier= CLOUD-DOMAIN-DE >> Suffix= dc=cloud,dc=domain,dc=de >> RootDN= cn=Directory Manager >> InstallLdifFile= /var/lib/dirsrv/boot.ldif >> inst_dir= /var/lib/dirsrv/scripts-CLOUD-DOMAIN-DE >> >> 2015-03-13T10:45:58Z DEBUG calling setup-ds.pl >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile >> - -f /tmp/tmp5witgD >> 2015-03-13T10:45:59Z DEBUG Process finished, return code=1 >> 2015-03-13T10:45:59Z DEBUG stdout=[15/03/13:10:45:59] - [Setup] Info >> Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. >> Output: importing data ... >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >> error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> >> Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. >> Output: importing data ... >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >> error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> >> [15/03/13:10:45:59] - [Setup] Fatal Error: Could not create directory >> server instance 'CLOUD-DOMAIN-DE'. >> Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. >> [15/03/13:10:45:59] - [Setup] Fatal Exiting . . . >> Log file is '-' >> >> Exiting . . . >> Log file is '-' >> >> >> 2015-03-13T10:45:59Z DEBUG stderr= >> 2015-03-13T10:45:59Z CRITICAL failed to create ds instance Command >> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD' returned >> non-zero exit status 1 >> 2015-03-13T10:45:59Z DEBUG restarting ds instance >> 2015-03-13T10:45:59Z DEBUG Starting external process >> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl --system daemon-reload >> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:59Z DEBUG stdout= >> 2015-03-13T10:45:59Z DEBUG stderr= >> 2015-03-13T10:45:59Z DEBUG Starting external process >> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl restart >> dirsrv at CLOUD-DOMAIN-DE.service >> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:59Z DEBUG stdout= >> 2015-03-13T10:45:59Z DEBUG stderr= >> 2015-03-13T10:45:59Z DEBUG Starting external process >> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl is-active >> dirsrv at CLOUD-DOMAIN-DE.service >> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:59Z DEBUG stdout=active >> >> 2015-03-13T10:45:59Z DEBUG stderr= >> 2015-03-13T10:45:59Z DEBUG wait_for_open_ports: localhost [389] timeout >> 300 >> 2015-03-13T10:50:59Z CRITICAL Failed to restart the directory server (). >> See the installation log for details. >> 2015-03-13T10:50:59Z DEBUG done restarting ds instance >> 2015-03-13T10:50:59Z DEBUG duration: 301 seconds >> 2015-03-13T10:50:59Z DEBUG [3/38]: adding default schema >> 2015-03-13T10:50:59Z DEBUG duration: 0 seconds >> 2015-03-13T10:50:59Z DEBUG [4/38]: enabling memberof plugin >> 2015-03-13T10:50:59Z DEBUG wait_for_open_ports: freeipa-2.cloud.domain.de >> [389] timeout 10 >> 2015-03-13T10:51:09Z DEBUG Could not connect to the Directory Server on >> freeipa-2.cloud.domain.de: >> 2015-03-13T10:51:09Z 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-server-install", line 1059, in main >> hbac_allow=not options.hbac_allow) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >> 323, in create_instance >> self.start_creation(runtime=60) >> >> 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/dsinstance.py", line >> 501, in __add_memberof_module >> self._ldap_mod("memberof-conf.ldif") >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 152, in _ldap_mod >> self.ldap_connect() >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 99, in ldap_connect >> conn.do_simple_bind(bindpw=self.dm_password) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1735, in do_simple_bind >> self.__bind_with_wait(self.conn.simple_bind_s, timeout, binddn, >> bindpw) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1730, in __bind_with_wait >> self.__wait_for_connection(timeout) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1719, in __wait_for_connection >> wait_for_open_ports(host, int(port), timeout) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >> 1096, in wait_for_open_ports >> raise socket.timeout() >> >> 2015-03-13T10:51:09Z DEBUG The ipa-server-install command failed, >> exception: timeout: >> >> >> >> >> -- >> 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 mlasevich at gmail.com Fri Mar 13 14:33:08 2015 From: mlasevich at gmail.com (Michael Lasevich) Date: Fri, 13 Mar 2015 07:33:08 -0700 Subject: [Freeipa-users] Saltstack and ipa-install on Centos7 failing In-Reply-To: References: Message-ID: Is SELinux on? On Mar 13, 2015 7:46 AM, "Andrew Holway" wrote: > Hallo > > I have a quite odd situation. I am using saltstack to set up freeipa > servers on Centos 7 but I am getting the following error: > > failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent > --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1 > > Saltstack outputs the command it is trying to run: > > ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p > password -n cloud.domain.de --setup-dns --unattended --no-forwarders > > However if I run this command manually on a clean machine it works fine. > > It works on Centos 6. > > > > I see this in the slapd error log: > > [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors > 389-Directory/1.3.1.6 B2014.219.1825 > freeipa-2.cloud.native-instruments.de:389 > (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE) > > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape > Portable Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape > Portable Runtime error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed > s/NATIVE-INSTRUMENTS/DOMAIN/g > 389-Directory/1.3.1.6 B2014.219.1825 > freeipa-2.cloud.native-instruments.de:389 > (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE) > > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime > error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime > error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > > > > > > > ipaserver-install.log > > 015-03-13T10:45:57Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z DEBUG httpd is not configured > 2015-03-13T10:45:57Z DEBUG kadmin is not configured > 2015-03-13T10:45:57Z DEBUG dirsrv is not configured > 2015-03-13T10:45:57Z DEBUG pki-cad is not configured > 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured > 2015-03-13T10:45:57Z DEBUG install is not configured > 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured > 2015-03-13T10:45:57Z DEBUG ntpd is not configured > 2015-03-13T10:45:57Z DEBUG named is not configured > 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured > 2015-03-13T10:45:57Z DEBUG filestore is tracking no files > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z 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': > True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax': 0, > 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, > 'unattended': True, 'trust_sshfp': False, 'external_ca_file': None, > 'no_host_dns': False, 'http_pkcs12': None, 'realm_name': 'CLOUD.DOMAIN.DE', > 'forwarders': None, 'idstart': 1544400000, 'external_ca': False, > 'ip_address': None, 'conf_ssh': True, 'zonemgr': None, 'root_ca_file': > None, 'setup_dns': True, 'host_name': None, 'debug': False, > 'external_cert_file': None, 'uninstall': False} > 2015-03-13T10:45:57Z DEBUG missing options might be asked for > interactively later > > 2015-03-13T10:45:57Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:57Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=enabled > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration: > *:8443 is a NameVirtualHost > default server freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > port 8443 namevhost freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > port 8443 namevhost freeipa-2.cloud.domain.de > (/etc/httpd/conf.d/nss.conf:86) > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG Check if freeipa-2.cloud.domain.de is a > primary hostname for localhost > 2015-03-13T10:45:57Z DEBUG Primary hostname for localhost: > freeipa-2.cloud.domain.de > 2015-03-13T10:45:57Z DEBUG will use host_name: freeipa-2.cloud.domain.de > > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=/sbin/ip -family inet -oneline address show > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host > lo\ valid_lft forever preferred_lft forever > 2: eth0 inet 10.16.1.100/24 brd 10.16.1.255 scope global dynamic eth0\ > valid_lft 2770sec preferred_lft 2770sec > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG will use dns_forwarders: () > > 2015-03-13T10:45:57Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipalib/plugins'... > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' > 2015-03-13T10:45:57Z DEBUG Starting external process > 2015-03-13T10:45:57Z DEBUG args=klist -V > 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:57Z DEBUG stdout=Kerberos 5 version 1.11.3 > > 2015-03-13T10:45:57Z DEBUG stderr= > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' > 2015-03-13T10:45:57Z DEBUG importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_anonymous_aci.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' > 2015-03-13T10:45:57Z DEBUG importing plugin module > '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' > 2015-03-13T10:45:58Z DEBUG Adding DS group dirsrv > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/groupadd -r dirsrv > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Done adding DS group > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=enabled > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=active > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl disable chronyd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr=rm > '/etc/systemd/system/multi-user.target.wants/chronyd.service' > > 2015-03-13T10:45:58Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Configuring NTP daemon (ntpd) > 2015-03-13T10:45:58Z DEBUG [1/4]: stopping ntpd > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=3 > 2015-03-13T10:45:58Z DEBUG stdout=unknown > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [2/4]: writing configuration > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/ntp.conf' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/sysconfig/ntpd' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [3/4]: configuring ntpd to start on boot > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=1 > 2015-03-13T10:45:58Z DEBUG stdout=disabled > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl enable ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr=ln -s > '/usr/lib/systemd/system/ntpd.service' > '/etc/systemd/system/multi-user.target.wants/ntpd.service' > > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [4/4]: starting ntpd > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl start ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout=active > > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG Done configuring NTP daemon (ntpd). > 2015-03-13T10:45:58Z DEBUG Loading StateFile from > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Configuring directory server (dirsrv): > Estimated time 1 minute > 2015-03-13T10:45:58Z DEBUG [1/38]: creating directory server user > 2015-03-13T10:45:58Z DEBUG Adding DS user dirsrv > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/useradd -g dirsrv -c DS System > User -d /var/lib/dirsrv -s /sbin/nologin -M -r dirsrv > 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:58Z DEBUG stdout= > 2015-03-13T10:45:58Z DEBUG stderr= > 2015-03-13T10:45:58Z DEBUG Done adding DS user > 2015-03-13T10:45:58Z DEBUG duration: 0 seconds > 2015-03-13T10:45:58Z DEBUG [2/38]: creating directory server instance > 2015-03-13T10:45:58Z DEBUG Saving StateFile to > '/var/lib/ipa/sysrestore/sysrestore.state' > 2015-03-13T10:45:58Z DEBUG Backing up system configuration file > '/etc/sysconfig/dirsrv' > 2015-03-13T10:45:58Z DEBUG Saving Index File to > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-13T10:45:58Z DEBUG > dn: dc=cloud,dc=domain,dc=de > objectClass: top > objectClass: domain > objectClass: pilotObject > dc: cloud > info: IPA V2.0 > > 2015-03-13T10:45:58Z DEBUG writing inf template > 2015-03-13T10:45:58Z DEBUG > [General] > FullMachineName= freeipa-2.cloud.domain.de > SuiteSpotUserID= dirsrv > SuiteSpotGroup= dirsrv > ServerRoot= /usr/lib64/dirsrv > [slapd] > ServerPort= 389 > ServerIdentifier= CLOUD-DOMAIN-DE > Suffix= dc=cloud,dc=domain,dc=de > RootDN= cn=Directory Manager > InstallLdifFile= /var/lib/dirsrv/boot.ldif > inst_dir= /var/lib/dirsrv/scripts-CLOUD-DOMAIN-DE > > 2015-03-13T10:45:58Z DEBUG calling setup-ds.pl > 2015-03-13T10:45:58Z DEBUG Starting external process > 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile > - -f /tmp/tmp5witgD > 2015-03-13T10:45:59Z DEBUG Process finished, return code=1 > 2015-03-13T10:45:59Z DEBUG stdout=[15/03/13:10:45:59] - [Setup] Info Could > not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. Output: > importing data ... > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime > error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. > Output: importing data ... > [13/Mar/2015:10:45:59 +0000] - Error - Unable to create > /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime > error -5966 (Access Denied.) > [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts > with other slapd processes > > [15/03/13:10:45:59] - [Setup] Fatal Error: Could not create directory > server instance 'CLOUD-DOMAIN-DE'. > Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. > [15/03/13:10:45:59] - [Setup] Fatal Exiting . . . > Log file is '-' > > Exiting . . . > Log file is '-' > > > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z CRITICAL failed to create ds instance Command > '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD' returned > non-zero exit status 1 > 2015-03-13T10:45:59Z DEBUG restarting ds instance > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl --system daemon-reload > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout= > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl restart > dirsrv at CLOUD-DOMAIN-DE.service > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout= > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG Starting external process > 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl is-active > dirsrv at CLOUD-DOMAIN-DE.service > 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 > 2015-03-13T10:45:59Z DEBUG stdout=active > > 2015-03-13T10:45:59Z DEBUG stderr= > 2015-03-13T10:45:59Z DEBUG wait_for_open_ports: localhost [389] timeout 300 > 2015-03-13T10:50:59Z CRITICAL Failed to restart the directory server (). > See the installation log for details. > 2015-03-13T10:50:59Z DEBUG done restarting ds instance > 2015-03-13T10:50:59Z DEBUG duration: 301 seconds > 2015-03-13T10:50:59Z DEBUG [3/38]: adding default schema > 2015-03-13T10:50:59Z DEBUG duration: 0 seconds > 2015-03-13T10:50:59Z DEBUG [4/38]: enabling memberof plugin > 2015-03-13T10:50:59Z DEBUG wait_for_open_ports: freeipa-2.cloud.domain.de > [389] timeout 10 > 2015-03-13T10:51:09Z DEBUG Could not connect to the Directory Server on > freeipa-2.cloud.domain.de: > 2015-03-13T10:51:09Z 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-server-install", line 1059, in main > hbac_allow=not options.hbac_allow) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", > line 323, in create_instance > self.start_creation(runtime=60) > > 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/dsinstance.py", > line 501, in __add_memberof_module > self._ldap_mod("memberof-conf.ldif") > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 152, in _ldap_mod > self.ldap_connect() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", > line 99, in ldap_connect > conn.do_simple_bind(bindpw=self.dm_password) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1735, > in do_simple_bind > self.__bind_with_wait(self.conn.simple_bind_s, timeout, binddn, bindpw) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1730, > in __bind_with_wait > self.__wait_for_connection(timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line 1719, > in __wait_for_connection > wait_for_open_ports(host, int(port), timeout) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 1096, > in wait_for_open_ports > raise socket.timeout() > > 2015-03-13T10:51:09Z DEBUG The ipa-server-install command failed, > exception: timeout: > > -- > 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 andrew.holway at gmail.com Fri Mar 13 14:55:32 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 13 Mar 2015 15:55:32 +0100 Subject: [Freeipa-users] Saltstack and ipa-install on Centos7 failing In-Reply-To: References: Message-ID: On 13 March 2015 at 15:33, Michael Lasevich wrote: > Is SELinux on? > Yes, ipa-server-install is running in the initrc_t domain but I guess its set up to run unconfined ps -Z with ipa-server-install run from salt-stack : system_u:system_r:init_t:s0 root 1568 0.0 1.4 231308 14652 ? Ss 14:31 0:00 /bin/python2 /usr/bin/salt-minion system_u:system_r:initrc_t:s0 root 3101 1.0 4.8 222004 49232 ? S 14:47 0:01 /usr/bin/python -E /usr/sbin/ipa-server-install ps -Z with ipa-server-install run from console : unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 4503 23.7 4.8 323356 48860 pts/1 S+ 14:53 0:00 /usr/bin/python -E /sbin/ipa-server-install On Mar 13, 2015 7:46 AM, "Andrew Holway" wrote: > >> Hallo >> >> I have a quite odd situation. I am using saltstack to set up freeipa >> servers on Centos 7 but I am getting the following error: >> >> failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent >> --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1 >> >> Saltstack outputs the command it is trying to run: >> >> ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p >> password -n cloud.domain.de --setup-dns --unattended --no-forwarders >> >> However if I run this command manually on a clean machine it works fine. >> >> It works on Centos 6. >> >> >> >> I see this in the slapd error log: >> >> [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors >> 389-Directory/1.3.1.6 B2014.219.1825 >> freeipa-2.cloud.native-instruments.de:389 >> (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE) >> >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape >> Portable Runtime error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape >> Portable Runtime error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed >> s/NATIVE-INSTRUMENTS/DOMAIN/g >> 389-Directory/1.3.1.6 B2014.219.1825 >> freeipa-2.cloud.native-instruments.de:389 >> (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE) >> >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >> error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >> error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> >> >> >> >> >> >> >> ipaserver-install.log >> >> 015-03-13T10:45:57Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:57Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:57Z DEBUG httpd is not configured >> 2015-03-13T10:45:57Z DEBUG kadmin is not configured >> 2015-03-13T10:45:57Z DEBUG dirsrv is not configured >> 2015-03-13T10:45:57Z DEBUG pki-cad is not configured >> 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured >> 2015-03-13T10:45:57Z DEBUG install is not configured >> 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured >> 2015-03-13T10:45:57Z DEBUG ntpd is not configured >> 2015-03-13T10:45:57Z DEBUG named is not configured >> 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured >> 2015-03-13T10:45:57Z DEBUG filestore is tracking no files >> 2015-03-13T10:45:57Z DEBUG Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> 2015-03-13T10:45:57Z 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': >> True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax': 0, >> 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, >> 'unattended': True, 'trust_sshfp': False, 'external_ca_file': None, >> 'no_host_dns': False, 'http_pkcs12': None, 'realm_name': 'CLOUD.DOMAIN.DE', >> 'forwarders': None, 'idstart': 1544400000, 'external_ca': False, >> 'ip_address': None, 'conf_ssh': True, 'zonemgr': None, 'root_ca_file': >> None, 'setup_dns': True, 'host_name': None, 'debug': False, >> 'external_cert_file': None, 'uninstall': False} >> 2015-03-13T10:45:57Z DEBUG missing options might be asked for >> interactively later >> >> 2015-03-13T10:45:57Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:57Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:57Z DEBUG Starting external process >> 2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service >> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:57Z DEBUG stdout=enabled >> >> 2015-03-13T10:45:57Z DEBUG stderr= >> 2015-03-13T10:45:57Z DEBUG Starting external process >> 2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS >> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration: >> *:8443 is a NameVirtualHost >> default server freeipa-2.cloud.domain.de >> (/etc/httpd/conf.d/nss.conf:86) >> port 8443 namevhost freeipa-2.cloud.domain.de >> (/etc/httpd/conf.d/nss.conf:86) >> port 8443 namevhost freeipa-2.cloud.domain.de >> (/etc/httpd/conf.d/nss.conf:86) >> >> 2015-03-13T10:45:57Z DEBUG stderr= >> 2015-03-13T10:45:57Z DEBUG Check if freeipa-2.cloud.domain.de is a >> primary hostname for localhost >> 2015-03-13T10:45:57Z DEBUG Primary hostname for localhost: >> freeipa-2.cloud.domain.de >> 2015-03-13T10:45:57Z DEBUG will use host_name: freeipa-2.cloud.domain.de >> >> 2015-03-13T10:45:57Z DEBUG Starting external process >> 2015-03-13T10:45:57Z DEBUG args=/sbin/ip -family inet -oneline address >> show >> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:57Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host >> lo\ valid_lft forever preferred_lft forever >> 2: eth0 inet 10.16.1.100/24 brd 10.16.1.255 scope global dynamic >> eth0\ valid_lft 2770sec preferred_lft 2770sec >> >> 2015-03-13T10:45:57Z DEBUG stderr= >> 2015-03-13T10:45:57Z DEBUG will use dns_forwarders: () >> >> 2015-03-13T10:45:57Z DEBUG importing all plugin modules in >> '/usr/lib/python2.7/site-packages/ipalib/plugins'... >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' >> 2015-03-13T10:45:57Z DEBUG Starting external process >> 2015-03-13T10:45:57Z DEBUG args=klist -V >> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:57Z DEBUG stdout=Kerberos 5 version 1.11.3 >> >> 2015-03-13T10:45:57Z DEBUG stderr= >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' >> 2015-03-13T10:45:57Z DEBUG importing all plugin modules in >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_anonymous_aci.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >> 2015-03-13T10:45:57Z DEBUG importing plugin module >> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >> 2015-03-13T10:45:58Z DEBUG Adding DS group dirsrv >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/groupadd -r dirsrv >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Done adding DS group >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled chronyd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout=enabled >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active chronyd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout=active >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop chronyd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl disable chronyd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr=rm >> '/etc/systemd/system/multi-user.target.wants/chronyd.service' >> >> 2015-03-13T10:45:58Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Configuring NTP daemon (ntpd) >> 2015-03-13T10:45:58Z DEBUG [1/4]: stopping ntpd >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=3 >> 2015-03-13T10:45:58Z DEBUG stdout=unknown >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG [2/4]: writing configuration >> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >> '/etc/ntp.conf' >> 2015-03-13T10:45:58Z DEBUG Saving Index File to >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >> '/etc/sysconfig/ntpd' >> 2015-03-13T10:45:58Z DEBUG Saving Index File to >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG [3/4]: configuring ntpd to start on boot >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=1 >> 2015-03-13T10:45:58Z DEBUG stdout=disabled >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl enable ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr=ln -s >> '/usr/lib/systemd/system/ntpd.service' >> '/etc/systemd/system/multi-user.target.wants/ntpd.service' >> >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG [4/4]: starting ntpd >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl start ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout=active >> >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG Done configuring NTP daemon (ntpd). >> 2015-03-13T10:45:58Z DEBUG Loading StateFile from >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Configuring directory server (dirsrv): >> Estimated time 1 minute >> 2015-03-13T10:45:58Z DEBUG [1/38]: creating directory server user >> 2015-03-13T10:45:58Z DEBUG Adding DS user dirsrv >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/useradd -g dirsrv -c DS System >> User -d /var/lib/dirsrv -s /sbin/nologin -M -r dirsrv >> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:58Z DEBUG stdout= >> 2015-03-13T10:45:58Z DEBUG stderr= >> 2015-03-13T10:45:58Z DEBUG Done adding DS user >> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >> 2015-03-13T10:45:58Z DEBUG [2/38]: creating directory server instance >> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >> '/var/lib/ipa/sysrestore/sysrestore.state' >> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >> '/etc/sysconfig/dirsrv' >> 2015-03-13T10:45:58Z DEBUG Saving Index File to >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-13T10:45:58Z DEBUG >> dn: dc=cloud,dc=domain,dc=de >> objectClass: top >> objectClass: domain >> objectClass: pilotObject >> dc: cloud >> info: IPA V2.0 >> >> 2015-03-13T10:45:58Z DEBUG writing inf template >> 2015-03-13T10:45:58Z DEBUG >> [General] >> FullMachineName= freeipa-2.cloud.domain.de >> SuiteSpotUserID= dirsrv >> SuiteSpotGroup= dirsrv >> ServerRoot= /usr/lib64/dirsrv >> [slapd] >> ServerPort= 389 >> ServerIdentifier= CLOUD-DOMAIN-DE >> Suffix= dc=cloud,dc=domain,dc=de >> RootDN= cn=Directory Manager >> InstallLdifFile= /var/lib/dirsrv/boot.ldif >> inst_dir= /var/lib/dirsrv/scripts-CLOUD-DOMAIN-DE >> >> 2015-03-13T10:45:58Z DEBUG calling setup-ds.pl >> 2015-03-13T10:45:58Z DEBUG Starting external process >> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/setup-ds.pl --silent --logfile >> - -f /tmp/tmp5witgD >> 2015-03-13T10:45:59Z DEBUG Process finished, return code=1 >> 2015-03-13T10:45:59Z DEBUG stdout=[15/03/13:10:45:59] - [Setup] Info >> Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. >> Output: importing data ... >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >> error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> >> Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. >> Output: importing data ... >> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >> error -5966 (Access Denied.) >> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >> with other slapd processes >> >> [15/03/13:10:45:59] - [Setup] Fatal Error: Could not create directory >> server instance 'CLOUD-DOMAIN-DE'. >> Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. >> [15/03/13:10:45:59] - [Setup] Fatal Exiting . . . >> Log file is '-' >> >> Exiting . . . >> Log file is '-' >> >> >> 2015-03-13T10:45:59Z DEBUG stderr= >> 2015-03-13T10:45:59Z CRITICAL failed to create ds instance Command >> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD' returned >> non-zero exit status 1 >> 2015-03-13T10:45:59Z DEBUG restarting ds instance >> 2015-03-13T10:45:59Z DEBUG Starting external process >> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl --system daemon-reload >> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:59Z DEBUG stdout= >> 2015-03-13T10:45:59Z DEBUG stderr= >> 2015-03-13T10:45:59Z DEBUG Starting external process >> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl restart >> dirsrv at CLOUD-DOMAIN-DE.service >> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:59Z DEBUG stdout= >> 2015-03-13T10:45:59Z DEBUG stderr= >> 2015-03-13T10:45:59Z DEBUG Starting external process >> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl is-active >> dirsrv at CLOUD-DOMAIN-DE.service >> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >> 2015-03-13T10:45:59Z DEBUG stdout=active >> >> 2015-03-13T10:45:59Z DEBUG stderr= >> 2015-03-13T10:45:59Z DEBUG wait_for_open_ports: localhost [389] timeout >> 300 >> 2015-03-13T10:50:59Z CRITICAL Failed to restart the directory server (). >> See the installation log for details. >> 2015-03-13T10:50:59Z DEBUG done restarting ds instance >> 2015-03-13T10:50:59Z DEBUG duration: 301 seconds >> 2015-03-13T10:50:59Z DEBUG [3/38]: adding default schema >> 2015-03-13T10:50:59Z DEBUG duration: 0 seconds >> 2015-03-13T10:50:59Z DEBUG [4/38]: enabling memberof plugin >> 2015-03-13T10:50:59Z DEBUG wait_for_open_ports: freeipa-2.cloud.domain.de >> [389] timeout 10 >> 2015-03-13T10:51:09Z DEBUG Could not connect to the Directory Server on >> freeipa-2.cloud.domain.de: >> 2015-03-13T10:51:09Z 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-server-install", line 1059, in main >> hbac_allow=not options.hbac_allow) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >> 323, in create_instance >> self.start_creation(runtime=60) >> >> 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/dsinstance.py", line >> 501, in __add_memberof_module >> self._ldap_mod("memberof-conf.ldif") >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 152, in _ldap_mod >> self.ldap_connect() >> >> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >> line 99, in ldap_connect >> conn.do_simple_bind(bindpw=self.dm_password) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1735, in do_simple_bind >> self.__bind_with_wait(self.conn.simple_bind_s, timeout, binddn, >> bindpw) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1730, in __bind_with_wait >> self.__wait_for_connection(timeout) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >> 1719, in __wait_for_connection >> wait_for_open_ports(host, int(port), timeout) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >> 1096, in wait_for_open_ports >> raise socket.timeout() >> >> 2015-03-13T10:51:09Z DEBUG The ipa-server-install command failed, >> exception: timeout: >> >> -- >> 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 g.fer.ordas at unicyber.co.uk Fri Mar 13 16:45:24 2015 From: g.fer.ordas at unicyber.co.uk (g.fer.ordas at unicyber.co.uk) Date: Fri, 13 Mar 2015 16:45:24 +0000 Subject: [Freeipa-users] AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: References: <5502E307.4030200@redhat.com> Message-ID: <131d63e5c051862842579ef4efd40591@unicyber.co.uk> Hi I am going forward with a Password Sync AD (window 2013) ---- FreeIPA ipa-server-3.3.3-28.0.1.el7 on a Centos7 Box. I got the Password Sync Tool installed in the Windows2013 box and I have created a user with it's related password as I am trying to test the password changes... Looking at the access logs I can see the following related to the Sync Process: -------- [13/Mar/2015:09:22:02 -0700] conn=2 op=10 RESULT err=32 tag=101 nentries=0 etime=0 [13/Mar/2015:09:23:27 -0700] conn=13 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server [13/Mar/2015:09:23:27 -0700] conn=13 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. [13/Mar/2015:09:23:29 -0700] conn=14 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server [13/Mar/2015:09:23:29 -0700] conn=14 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. [13/Mar/2015:09:23:33 -0700] conn=15 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server [13/Mar/2015:09:23:33 -0700] conn=15 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. [13/Mar/2015:09:23:41 -0700] conn=16 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server [13/Mar/2015:09:23:41 -0700] conn=16 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. [13/Mar/2015:09:23:57 -0700] conn=17 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server [13/Mar/2015:09:23:57 -0700] conn=17 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. [13/Mar/2015:09:24:29 -0700] conn=18 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server [13/Mar/2015:09:24:29 -0700] conn=18 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. [13/Mar/2015:09:25:34 -0700] conn=19 fd=91 slot=91 SSL connection from AD.Server to FreeIPA.Server [13/Mar/2015:09:25:34 -0700] conn=19 op=-1 fd=91 closed - Peer reports incompatible or unsupported protocol version. -------- So the passwords do not seem to be copied across. Any idea why is this happening and how to troubleshoot it? Many Thanks -------------- next part -------------- An HTML attachment was scrubbed... URL: From rmeggins at redhat.com Fri Mar 13 17:00:28 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Fri, 13 Mar 2015 11:00:28 -0600 Subject: [Freeipa-users] AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: <131d63e5c051862842579ef4efd40591@unicyber.co.uk> References: <5502E307.4030200@redhat.com> <131d63e5c051862842579ef4efd40591@unicyber.co.uk> Message-ID: <550317AC.9030102@redhat.com> On 03/13/2015 10:45 AM, g.fer.ordas at unicyber.co.uk wrote: > Hi > > I am going forward with a Password Sync AD (window 2013) ---- FreeIPA > > ipa-server-3.3.3-28.0.1.el7 on a Centos7 Box. > > I got the Password Sync Tool installed in the Windows2013 box and I > have created a user with it's related password as I am trying to test > the password changes... > What version of PassSync are you using? > Looking at the access logs I can see the following related to the Sync > Process: > > -------- > > [13/Mar/2015:09:22:02 -0700] conn=2 op=10 RESULT err=32 tag=101 nentries=0 etime=0 > [13/Mar/2015:09:23:27 -0700] conn=13 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:27 -0700] conn=13 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:23:29 -0700] conn=14 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:29 -0700] conn=14 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:23:33 -0700] conn=15 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:33 -0700] conn=15 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:23:41 -0700] conn=16 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:41 -0700] conn=16 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:23:57 -0700] conn=17 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:57 -0700] conn=17 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:24:29 -0700] conn=18 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:24:29 -0700] conn=18 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:25:34 -0700] conn=19 fd=91 slot=91 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:25:34 -0700] conn=19 op=-1 fd=91 closed - Peer reports incompatible or unsupported protocol version. > -------- > > So the passwords do not seem to be copied across. > Any idea why is this happening and how to troubleshoot it? > > Many Thanks > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Fri Mar 13 17:02:45 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 13 Mar 2015 19:02:45 +0200 Subject: [Freeipa-users] AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: <131d63e5c051862842579ef4efd40591@unicyber.co.uk> References: <5502E307.4030200@redhat.com> <131d63e5c051862842579ef4efd40591@unicyber.co.uk> Message-ID: <20150313170245.GI3878@redhat.com> On Fri, 13 Mar 2015, g.fer.ordas at unicyber.co.uk wrote: > > >Hi > >I am going forward with a Password Sync AD (window 2013) ---- FreeIPA > >ipa-server-3.3.3-28.0.1.el7 on a Centos7 Box. > >I got the Password Sync Tool installed in the Windows2013 box and I have >created a user with it's related password as I am trying to test the >password changes... > >Looking at the access logs I can see the following related to the Sync >Process: > >-------- > >[13/Mar/2015:09:22:02 -0700] conn=2 op=10 RESULT err=32 tag=101 >nentries=0 etime=0 >[13/Mar/2015:09:23:27 -0700] conn=13 fd=82 slot=82 SSL connection from >AD.Server to FreeIPA.Server >[13/Mar/2015:09:23:27 -0700] conn=13 op=-1 fd=82 closed - Peer reports >incompatible or unsupported protocol version. >[13/Mar/2015:09:23:29 -0700] conn=14 fd=82 slot=82 SSL connection from >AD.Server to FreeIPA.Server >[13/Mar/2015:09:23:29 -0700] conn=14 op=-1 fd=82 closed - Peer reports >incompatible or unsupported protocol version. >[13/Mar/2015:09:23:33 -0700] conn=15 fd=82 slot=82 SSL connection from >AD.Server to FreeIPA.Server >[13/Mar/2015:09:23:33 -0700] conn=15 op=-1 fd=82 closed - Peer reports >incompatible or unsupported protocol version. >[13/Mar/2015:09:23:41 -0700] conn=16 fd=82 slot=82 SSL connection from >AD.Server to FreeIPA.Server >[13/Mar/2015:09:23:41 -0700] conn=16 op=-1 fd=82 closed - Peer reports >incompatible or unsupported protocol version. >[13/Mar/2015:09:23:57 -0700] conn=17 fd=82 slot=82 SSL connection from >AD.Server to FreeIPA.Server >[13/Mar/2015:09:23:57 -0700] conn=17 op=-1 fd=82 closed - Peer reports >incompatible or unsupported protocol version. >[13/Mar/2015:09:24:29 -0700] conn=18 fd=82 slot=82 SSL connection from >AD.Server to FreeIPA.Server >[13/Mar/2015:09:24:29 -0700] conn=18 op=-1 fd=82 closed - Peer reports >incompatible or unsupported protocol version. >[13/Mar/2015:09:25:34 -0700] conn=19 fd=91 slot=91 SSL connection from >AD.Server to FreeIPA.Server >[13/Mar/2015:09:25:34 -0700] conn=19 op=-1 fd=91 closed - Peer reports >incompatible or unsupported protocol version. >-------- > >So the passwords do not seem to be copied across. >Any idea why is this happening and how to troubleshoot it? 389-ds has disabled SSL3 and only allows TLS1.x connections. You need to configure passsync on AD side to use TLS1.1 or newer instead of SSL3. http://directory.fedoraproject.org/docs/389ds/download.html#windows-password-synchronization says that passsync 1.1.5 has no support for TLS1.1 or newer, while 1.1.6 has it. -- / Alexander Bokovoy From dpal at redhat.com Fri Mar 13 17:02:49 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Mar 2015 13:02:49 -0400 Subject: [Freeipa-users] AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: <131d63e5c051862842579ef4efd40591@unicyber.co.uk> References: <5502E307.4030200@redhat.com> <131d63e5c051862842579ef4efd40591@unicyber.co.uk> Message-ID: <55031839.9040803@redhat.com> On 03/13/2015 12:45 PM, g.fer.ordas at unicyber.co.uk wrote: > Hi > > I am going forward with a Password Sync AD (window 2013) ---- FreeIPA > > ipa-server-3.3.3-28.0.1.el7 on a Centos7 Box. > > I got the Password Sync Tool installed in the Windows2013 box and I > have created a user with it's related password as I am trying to test > the password changes... > > Looking at the access logs I can see the following related to the Sync > Process: > > -------- > > [13/Mar/2015:09:22:02 -0700] conn=2 op=10 RESULT err=32 tag=101 nentries=0 etime=0 > [13/Mar/2015:09:23:27 -0700] conn=13 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:27 -0700] conn=13 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:23:29 -0700] conn=14 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:29 -0700] conn=14 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:23:33 -0700] conn=15 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:33 -0700] conn=15 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:23:41 -0700] conn=16 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:41 -0700] conn=16 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:23:57 -0700] conn=17 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:23:57 -0700] conn=17 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:24:29 -0700] conn=18 fd=82 slot=82 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:24:29 -0700] conn=18 op=-1 fd=82 closed - Peer reports incompatible or unsupported protocol version. > [13/Mar/2015:09:25:34 -0700] conn=19 fd=91 slot=91 SSL connection from AD.Server to FreeIPA.Server > [13/Mar/2015:09:25:34 -0700] conn=19 op=-1 fd=91 closed - Peer reports incompatible or unsupported protocol version. > -------- > > So the passwords do not seem to be copied across. > Any idea why is this happening and how to troubleshoot it? > > Many Thanks > > > This might be related to the one of the vulnerabilities that was found last year. Make sure that you have the latest available versions on both sides. If you have a mismatch then the client might not talk the TLS version that server expects or vice verse. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnnydtan at gmail.com Fri Mar 13 17:47:04 2015 From: johnnydtan at gmail.com (Johnny Tan) Date: Fri, 13 Mar 2015 13:47:04 -0400 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <54F78DA0.4040801@redhat.com> References: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> <54F78DA0.4040801@redhat.com> Message-ID: On Wed, Mar 4, 2015 at 5:56 PM, Dmitri Pal wrote: > IPA does not use certs for communication between the instances. It uses > Kerberos. I am not sure the DoDaddy cert you added is even used in some way > by IPA. > Dmitri or Rob: Could you explain what the various uses of the IPA certs are, then? AFAICT, the IPA masters generate a certificate for each node in the realm. Why does it do that? I thought it was for: - Webui/api (apache) communication over https. - LDAP binding/communication over 636 (TLS). But if the certs are not utilized for communication between the instances (per statement above), what are they used for? I'm not hijacking the thread, I'm actually in the exact same position as OP. I replaced the self-signed IPA/dogtag CA root with one that was signed by our own CA and am now having problems with various cert errors during client enrollment or any other similar activity (like doing an 'ipa host-del' directly on an IPA master). I can post those details in a separate thread, but before I go down that path, I want to better understand what the purpose of the certs are so I can deterine what's the best path forward for us. As I understand it from the docs, there are three primary ways to run IPA with respect to a CA: - self-signed IPA CA, this is the default - signing the IPA CA root with an "external"/3rd-party CA - running "CA-less" and providing all certs with the external/3rd-party CA (depending on what the use/purpose of the certs are, this is increasingly becoming an attractive option but is likely also tedious in its own right) Thanks for any insight. On Wed, Mar 4, 2015 at 5:56 PM, Dmitri Pal wrote: > On 03/04/2015 04:32 PM, sipazzo wrote: > > Good afternoon, we have a freeipa 3.0.42 installation running on redhead > 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It was originally > configured with the built in dogtag certificate CA and then one of my > co-workers added our GoDaddy certificate to the certificate bundle. My > understanding is this cert is used for communication between the ipa > servers as well as the clients are also configured to trust the GoDaddy > certificate. We recently had to get a new GoDaddy cert so our old one is > revoked. I need to figure out how to either replace the existing revoked > cert with the new one or add the new one to the bundle and then remove the > revoked certificate so as not to break anything. > > Any help is appreciated. I am not strong with certificates so the more > detail you can give the better. > Thank you. > > > You say it was running with the self signed IPA CA and than GoDaddy cert > was added to the bundle. How was it added? > IPA does not use certs for communication between the instances. It uses > Kerberos. I am not sure the DoDaddy cert you added is even used in some way > by IPA. > It seems that your GoDaddy cert is an orthogonal trust so if you replaced > the main key pair then you just need to distribute your new GoDaddy cert to > the clients as you did on the first place. > > > -- > 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 g.fer.ordas at unicyber.co.uk Fri Mar 13 18:04:59 2015 From: g.fer.ordas at unicyber.co.uk (g.fer.ordas at unicyber.co.uk) Date: Fri, 13 Mar 2015 18:04:59 +0000 Subject: [Freeipa-users] AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: <55031839.9040803@redhat.com> References: <5502E307.4030200@redhat.com> <131d63e5c051862842579ef4efd40591@unicyber.co.uk> <55031839.9040803@redhat.com> Message-ID: Thanks to everyone for the replies. The installed version for the passsync is 1.1.6 and using the latest I got in RPMs form centos7 so the following: 89-ds-base-1.3.1.6-26.el7_0.x86_64 389-ds-base-libs-1.3.1.6-26.el7_0.x86_64 sssd-ipa-1.11.2-68.el7_0.6.x86_64 ipa-python-3.3.3-28.0.1.el7.centos.3.x86_64 ipa-admintools-3.3.3-28.0.1.el7.centos.3.x86_64 libipa_hbac-1.11.2-68.el7_0.6.x86_64 ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64 ipa-client-3.3.3-28.0.1.el7.centos.3.x86_64 libipa_hbac-python-1.11.2-68.el7_0.6.x86_64 I haven't installed anything manually but using the Centos' Repos... thanks!!! On 2015-03-13 17:02, Dmitri Pal wrote: > On 03/13/2015 12:45 PM, g.fer.ordas at unicyber.co.uk wrote: > >> Hi >> >> I am going forward with a Password Sync AD (window 2013) ---- >> FreeIPA >> >> ipa-server-3.3.3-28.0.1.el7 on a Centos7 Box. >> >> I got the Password Sync Tool installed in the Windows2013 box and I >> have created a user with it's related password as I am trying to >> test the password changes... >> >> Looking at the access logs I can see the following related to the >> Sync Process: >> >> -------- >> >> [13/Mar/2015:09:22:02 -0700] conn=2 op=10 RESULT err=32 tag=101 >> nentries=0 etime=0 >> [13/Mar/2015:09:23:27 -0700] conn=13 fd=82 slot=82 SSL connection >> from AD.Server to FreeIPA.Server >> [13/Mar/2015:09:23:27 -0700] conn=13 op=-1 fd=82 closed - Peer >> reports incompatible or unsupported protocol version. >> [13/Mar/2015:09:23:29 -0700] conn=14 fd=82 slot=82 SSL connection >> from AD.Server to FreeIPA.Server >> [13/Mar/2015:09:23:29 -0700] conn=14 op=-1 fd=82 closed - Peer >> reports incompatible or unsupported protocol version. >> [13/Mar/2015:09:23:33 -0700] conn=15 fd=82 slot=82 SSL connection >> from AD.Server to FreeIPA.Server >> [13/Mar/2015:09:23:33 -0700] conn=15 op=-1 fd=82 closed - Peer >> reports incompatible or unsupported protocol version. >> [13/Mar/2015:09:23:41 -0700] conn=16 fd=82 slot=82 SSL connection >> from AD.Server to FreeIPA.Server >> [13/Mar/2015:09:23:41 -0700] conn=16 op=-1 fd=82 closed - Peer >> reports incompatible or unsupported protocol version. >> [13/Mar/2015:09:23:57 -0700] conn=17 fd=82 slot=82 SSL connection >> from AD.Server to FreeIPA.Server >> [13/Mar/2015:09:23:57 -0700] conn=17 op=-1 fd=82 closed - Peer >> reports incompatible or unsupported protocol version. >> [13/Mar/2015:09:24:29 -0700] conn=18 fd=82 slot=82 SSL connection >> from AD.Server to FreeIPA.Server >> [13/Mar/2015:09:24:29 -0700] conn=18 op=-1 fd=82 closed - Peer >> reports incompatible or unsupported protocol version. >> [13/Mar/2015:09:25:34 -0700] conn=19 fd=91 slot=91 SSL connection >> from AD.Server to FreeIPA.Server >> [13/Mar/2015:09:25:34 -0700] conn=19 op=-1 fd=91 closed - Peer >> reports incompatible or unsupported protocol version. >> -------- >> >> So the passwords do not seem to be copied across. >> Any idea why is this happening and how to troubleshoot it? >> >> Many Thanks > This might be related to the one of the vulnerabilities that was > found last year. Make sure that you have the latest available versions > on both sides. If you have a mismatch then the client might not talk > the TLS version that server expects or vice verse. > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. From dpal at redhat.com Fri Mar 13 18:15:25 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Mar 2015 14:15:25 -0400 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: References: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> <54F78DA0.4040801@redhat.com> Message-ID: <5503293D.3090308@redhat.com> On 03/13/2015 01:47 PM, Johnny Tan wrote: > On Wed, Mar 4, 2015 at 5:56 PM, Dmitri Pal >wrote: > > IPA does not use certs for communication between the instances. It > uses Kerberos. I am not sure the DoDaddy cert you added is even > used in some way by IPA. > > > Dmitri or Rob: > > Could you explain what the various uses of the IPA certs are, then? > AFAICT, the IPA masters generate a certificate for each node in the > realm. Why does it do that? I thought it was for: > - Webui/api (apache) communication over https. > - LDAP binding/communication over 636 (TLS). Rob would definitely know more but IPA mostly provides certs for the infra it serves and has a limited use of the certs by itself. So here is where I know it is used: - You can issue certs for hosts and services and installer used to create certs for host automatically though these certs are not used for anything and we decided not to create them automatically any more. - You need to trust IPA in browser so that you can do a forms based authentication if you do not have a kerberos ticket. - To issue certs we use Dogtag and Dogtag understands only cert based authentication so internally the communication between the managment framework and Dogtag uses SSL. This is actually why the host-del fails. The host had a cert issued by IPA CA so as part of the del operation it tries to revoke the cert but since you reconfigured the sustem to use be CA less it can't and fails. The communication between the LDAP servers is Kerberos authenticated. > > But if the certs are not utilized for communication between the > instances (per statement above), what are they used for? > > I'm not hijacking the thread, I'm actually in the exact same position > as OP. I replaced the self-signed IPA/dogtag CA root with one that was > signed by our own CA and am now having problems with various cert > errors during client enrollment or any other similar activity (like > doing an 'ipa host-del' directly on an IPA master). We have a special tool in Freeipa 4.2 to do this. The manual procedure is cumbersome and leads to issues like this. > > I can post those details in a separate thread, but before I go down > that path, I want to better understand what the purpose of the certs > are so I can deterine what's the best path forward for us. > > As I understand it from the docs, there are three primary ways to run > IPA with respect to a CA: > - self-signed IPA CA, this is the default > - signing the IPA CA root with an "external"/3rd-party CA > - running "CA-less" and providing all certs with the > external/3rd-party CA (depending on what the use/purpose of the certs > are, this is increasingly becoming an attractive option but is likely > also tedious in its own right) > You are correct here. > Thanks for any insight. > > On Wed, Mar 4, 2015 at 5:56 PM, Dmitri Pal > wrote: > > On 03/04/2015 04:32 PM, sipazzo wrote: >> Good afternoon, we have a freeipa 3.0.42 installation running on >> redhead 6.6 with a mix of rhel 5, rhel6 and Solaris clients. It >> was originally configured with the built in dogtag certificate CA >> and then one of my co-workers added our GoDaddy certificate to >> the certificate bundle. My understanding is this cert is used for >> communication between the ipa servers as well as the clients are >> also configured to trust the GoDaddy certificate. We recently had >> to get a new GoDaddy cert so our old one is revoked. I need to >> figure out how to either replace the existing revoked cert with >> the new one or add the new one to the bundle and then remove the >> revoked certificate so as not to break anything. >> >> Any help is appreciated. I am not strong with certificates so the >> more detail you can give the better. >> Thank you. >> >> > You say it was running with the self signed IPA CA and than > GoDaddy cert was added to the bundle. How was it added? > IPA does not use certs for communication between the instances. It > uses Kerberos. I am not sure the DoDaddy cert you added is even > used in some way by IPA. > It seems that your GoDaddy cert is an orthogonal trust so if you > replaced the main key pair then you just need to distribute your > new GoDaddy cert to the clients as you did on the first place. > > > -- > 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 g.fer.ordas at unicyber.co.uk Fri Mar 13 18:23:43 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Fri, 13 Mar 2015 19:23:43 +0100 Subject: [Freeipa-users] AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: References: <5502E307.4030200@redhat.com> <131d63e5c051862842579ef4efd40591@unicyber.co.uk> <55031839.9040803@redhat.com> Message-ID: <55032B2F.80107@unicyber.co.uk> I am having a look at the documentation again.. And having version 1.1.6 of the PassSync tool means: [**] 389-PassSync-1.1.6disables SSLv3 by default. And I can see in the LDAP Info from IPA that SSLv3 and SSLv2 as OFF.. So, "theoretically", it should work as SSLv3 is disable on both? thanks! On 13/03/2015 19:04, g.fer.ordas at unicyber.co.uk wrote: > > Thanks to everyone for the replies. > > The installed version for the passsync is 1.1.6 and using the latest > I got in RPMs form centos7 so the following: > 89-ds-base-1.3.1.6-26.el7_0.x86_64 > 389-ds-base-libs-1.3.1.6-26.el7_0.x86_64 > sssd-ipa-1.11.2-68.el7_0.6.x86_64 > ipa-python-3.3.3-28.0.1.el7.centos.3.x86_64 > ipa-admintools-3.3.3-28.0.1.el7.centos.3.x86_64 > libipa_hbac-1.11.2-68.el7_0.6.x86_64 > ipa-server-3.3.3-28.0.1.el7.centos.3.x86_64 > ipa-client-3.3.3-28.0.1.el7.centos.3.x86_64 > libipa_hbac-python-1.11.2-68.el7_0.6.x86_64 > > I haven't installed anything manually but using the Centos' Repos... > > thanks!!! > > > > > On 2015-03-13 17:02, Dmitri Pal wrote: >> On 03/13/2015 12:45 PM, g.fer.ordas at unicyber.co.uk wrote: >> >>> Hi >>> >>> I am going forward with a Password Sync AD (window 2013) ---- >>> FreeIPA >>> >>> ipa-server-3.3.3-28.0.1.el7 on a Centos7 Box. >>> >>> I got the Password Sync Tool installed in the Windows2013 box and I >>> have created a user with it's related password as I am trying to >>> test the password changes... >>> >>> Looking at the access logs I can see the following related to the >>> Sync Process: >>> >>> -------- >>> >>> [13/Mar/2015:09:22:02 -0700] conn=2 op=10 RESULT err=32 tag=101 >>> nentries=0 etime=0 >>> [13/Mar/2015:09:23:27 -0700] conn=13 fd=82 slot=82 SSL connection >>> from AD.Server to FreeIPA.Server >>> [13/Mar/2015:09:23:27 -0700] conn=13 op=-1 fd=82 closed - Peer >>> reports incompatible or unsupported protocol version. >>> [13/Mar/2015:09:23:29 -0700] conn=14 fd=82 slot=82 SSL connection >>> from AD.Server to FreeIPA.Server >>> [13/Mar/2015:09:23:29 -0700] conn=14 op=-1 fd=82 closed - Peer >>> reports incompatible or unsupported protocol version. >>> [13/Mar/2015:09:23:33 -0700] conn=15 fd=82 slot=82 SSL connection >>> from AD.Server to FreeIPA.Server >>> [13/Mar/2015:09:23:33 -0700] conn=15 op=-1 fd=82 closed - Peer >>> reports incompatible or unsupported protocol version. >>> [13/Mar/2015:09:23:41 -0700] conn=16 fd=82 slot=82 SSL connection >>> from AD.Server to FreeIPA.Server >>> [13/Mar/2015:09:23:41 -0700] conn=16 op=-1 fd=82 closed - Peer >>> reports incompatible or unsupported protocol version. >>> [13/Mar/2015:09:23:57 -0700] conn=17 fd=82 slot=82 SSL connection >>> from AD.Server to FreeIPA.Server >>> [13/Mar/2015:09:23:57 -0700] conn=17 op=-1 fd=82 closed - Peer >>> reports incompatible or unsupported protocol version. >>> [13/Mar/2015:09:24:29 -0700] conn=18 fd=82 slot=82 SSL connection >>> from AD.Server to FreeIPA.Server >>> [13/Mar/2015:09:24:29 -0700] conn=18 op=-1 fd=82 closed - Peer >>> reports incompatible or unsupported protocol version. >>> [13/Mar/2015:09:25:34 -0700] conn=19 fd=91 slot=91 SSL connection >>> from AD.Server to FreeIPA.Server >>> [13/Mar/2015:09:25:34 -0700] conn=19 op=-1 fd=91 closed - Peer >>> reports incompatible or unsupported protocol version. >>> -------- >>> >>> So the passwords do not seem to be copied across. >>> Any idea why is this happening and how to troubleshoot it? >>> >>> Many Thanks >> This might be related to the one of the vulnerabilities that was >> found last year. Make sure that you have the latest available versions >> on both sides. If you have a mismatch then the client might not talk >> the TLS version that server expects or vice verse. >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From johnnydtan at gmail.com Fri Mar 13 18:51:20 2015 From: johnnydtan at gmail.com (Johnny Tan) Date: Fri, 13 Mar 2015 14:51:20 -0400 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <5503293D.3090308@redhat.com> References: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> <54F78DA0.4040801@redhat.com> <5503293D.3090308@redhat.com> Message-ID: On Fri, Mar 13, 2015 at 2:15 PM, Dmitri Pal wrote: > Rob would definitely know more but IPA mostly provides certs for the > infra it serves and has a limited use of the certs by itself. > So here is where I know it is used: > - You can issue certs for hosts and services and installer used to create > certs for host automatically though these certs are not used for anything > and we decided not to create them automatically any more. > - You need to trust IPA in browser so that you can do a forms based > authentication if you do not have a kerberos ticket. > - To issue certs we use Dogtag and Dogtag understands only cert based > authentication so internally the communication between the managment > framework and Dogtag uses SSL. This is actually why the host-del fails. The > host had a cert issued by IPA CA so as part of the del operation it tries > to revoke the cert but since you reconfigured the sustem to use be CA less > it can't and fails. > > The communication between the LDAP servers is Kerberos authenticated. > I'll wait for Rob to weigh in, but wow, this would actually be huge for us and probably a lot of other users. Because if the above is true (and complete, I guess), then we could actually just run a CA-less FreeIPA setup, and then generate certs specifically and only for the web (apache) side, which is easy enough and we do it already for all other internal web services. That limits cert-related stuff to just one web SSL cert per IPA master. > We have a special tool in Freeipa 4.2 to do this. The manual procedure is > cumbersome and leads to issues like this. > Yeah, I saw that, but we are still doing 3.0 on CentOS6.6, which is why we had to go down the manual path. Thanks, johnny -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 13 19:42:16 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Mar 2015 15:42:16 -0400 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: References: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> <54F78DA0.4040801@redhat.com> <5503293D.3090308@redhat.com> Message-ID: <55033D98.7090707@redhat.com> On 03/13/2015 02:51 PM, Johnny Tan wrote: > On Fri, Mar 13, 2015 at 2:15 PM, Dmitri Pal > wrote: > > Rob would definitely know more but IPA mostly provides certs for > the infra it serves and has a limited use of the certs by itself. > So here is where I know it is used: > - You can issue certs for hosts and services and installer used to > create certs for host automatically though these certs are not > used for anything and we decided not to create them automatically > any more. > - You need to trust IPA in browser so that you can do a forms > based authentication if you do not have a kerberos ticket. > - To issue certs we use Dogtag and Dogtag understands only cert > based authentication so internally the communication between the > managment framework and Dogtag uses SSL. This is actually why the > host-del fails. The host had a cert issued by IPA CA so as part of > the del operation it tries to revoke the cert but since you > reconfigured the sustem to use be CA less it can't and fails. > > The communication between the LDAP servers is Kerberos authenticated. > > > I'll wait for Rob to weigh in, but wow, this would actually be huge > for us and probably a lot of other users. Because if the above is true > (and complete, I guess), then we could actually just run a CA-less > FreeIPA setup, and then generate certs specifically and only for the > web (apache) side, which is easy enough and we do it already for all > other internal web services. That limits cert-related stuff to just > one web SSL cert per IPA master. This is up to you but that means you would not be able to deal with SSL for some other use cases down the road. IPA 4.2 has a lot of new functionality to make it easier to issue and manage certificates for different use cases like: system provisioning, VPN, devices, wireless, PaaS/IaaS stacks that use certs for SSL internally etc. Going CA-less will prevent you from leveraging these capabilities once you realize they are needed down the road. May be you would not need them but I would encourage you to look at this in a longer perspective than just immediate needs. > We have a special tool in Freeipa 4.2 to do this. The manual > procedure is cumbersome and leads to issues like this. > And to be correct it is in 4.1 and already released. Sorry for typo. > > Yeah, I saw that, but we are still doing 3.0 on CentOS6.6, which is > why we had to go down the manual path. > Thanks, > johnny > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Fri Mar 13 20:19:23 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Fri, 13 Mar 2015 16:19:23 -0400 Subject: [Freeipa-users] New Trust - AD id's not resolving Message-ID: I followed the directions from https://access.redhat.com/solutions/1354543 pretty much to the letter. Everything was successful and seems to work well aside from the last step of trying to resolve an AD user with the ID command on an IPA client. [gould at mid-ipa-vp02 ~]$ id farus at test.osuwmc id: farus at test.osuwmc: no such user I enabled debugging in sssd. Here?s what I saw in the lookup for ?id farus at test.osuwmc?. It looks like the AD is returning no match when the account exists. (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=farus] (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [ipa_idmap_check_posix_child] (0x0080): No forest available for domain [S-1-5-21-226267946-722566613-1883572810]. (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [ipa_idmap_get_ranges_from_sysdb] (0x0040): ipa_idmap_check_posix_child failed. (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not add new domain for sid [S-1-5-21-226267946-722566613-1883572810] (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'test.osuwmc' (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [be_resolve_server_process] (0x0200): Found address for server svr-addc-vt02.test.osuwmc: [10.80.5.240] TTL 3600 (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [4] (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'test.osuwmc' (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [be_resolve_server_process] (0x0200): Found address for server svr-addc-vt02.test.osuwmc: [10.80.5.240] TTL 3600 (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [child_sig_handler] (0x0100): child [4587] finished successfully. (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: host/mid-ipa-vp01.unix.test.osuwmc (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [fo_set_port_status] (0x0100): Marking port 389 of server 'svr-addc-vt02.test.osuwmc' as 'working' (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [set_server_common_status] (0x0100): Marking server 'svr-addc-vt02.test.osuwmc' as 'working' (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [sdap_get_users_done] (0x0040): Failed to retrieve users (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [ipa_get_ad_acct_ad_part_done] (0x0080): Object not found, ending request (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success The trust looks good. [gould at mid-ipa-vp01 ~]$ kinit admin Password for admin at UNIX.TEST.OSUWMC: [gould at mid-ipa-vp01 ~]$ ipa trust-show Realm name: TEST.OSUWMC Realm name: test.osuwmc Domain NetBIOS name: TEST Domain Security Identifier: S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX Trust direction: Two-way trust Trust type: Active Directory domain [gould at mid-ipa-vp01 ~]$ Any idea why it can?t find the match? Also, we?re curious why it tries to resolve POSIX when we added the trust with --range-type=ipa-ad-trust and not --range-type=ipa-ad-trust-posix. Other question is how do you set or default to a one way trust when installing instead of a two way? We know how to modify the trust in IPA and AD, but are a bit leery since we?re not sure what all might break or if we?re modifying all that truly needs to be modified in IPA. Joshua From sipazzo at yahoo.com Fri Mar 13 20:32:27 2015 From: sipazzo at yahoo.com (sipazzo) Date: Fri, 13 Mar 2015 20:32:27 +0000 (UTC) Subject: [Freeipa-users] Fw: Need to replace cert for ipa servers In-Reply-To: <903DF15B7B9D3B4D9137A06F63687859172CC3185D@FHDP1LUMXC7V33.us.one.verizon.com> References: <903DF15B7B9D3B4D9137A06F63687859172CC3185D@FHDP1LUMXC7V33.us.one.verizon.com> Message-ID: <499575904.4226305.1426278747223.JavaMail.yahoo@mail.yahoo.com> This environment is over 350 servers, many of which are in production so I may have to wait a bit for change management approval to attempt to resolve this issue, particularly if you think it might break something.? I will keep you updated on my progress. Thank you much. From: sipazzo To: Rob Crittenden Cc: "freeipa-users at redhat.com" Sent: Friday, March 13, 2015 9:21 AM Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden Sent: Thursday, March 12, 2015 1:52 PM To: sipazzo; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers sipazzo wrote: > I do have other CAs (just not the master but it is available offline > if > needed) To be clear, all IPA servers are masters, some just run more services than others. It sounds like you have at least one CA available which should be sufficient. > Directory server is running > The apache web server is running and I can get to the gui ipa > cert-show 1 works Ok. I guess the place to start is to get certs for Apache and 389-ds, then we can see about using these new certs. In the thread you showed that the IPA 389-ds doesn't have a Server-Cert nickname. You'll want to do the same for /etc/httpd/alias before running the following commands otherwise you could end up with non-functional server. These should get IPA certs for 389-ds and Apache. You'll need to edit these commands to match your environment: # ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_httpd -N CN=ipa.example.com -K HTTP/ipa.example.com at EXAMPLE.COM # ipa-getcert request -d /etc/dirsrv/slapd-EXAMPLE-COM -n Server-Cert -p /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt -C '/usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM' -N CN=ipa.example.com -K ldap/ipa.example.com at EXAMPLE.COM I'd do them one at a time and wait until the cert is issued and tracked. This will restart both Apache and 389-ds but it shouldn't affect operation because the certs won't be used yet. You then need to get the old CA cert and put it into the right places. Since it is already in the PKI-IPA NSS database let's fetch it from there. For giggles you should probably save whatever the contents of /etc/ipa/ca.crt are before-hand. # certutil -L -d /etc/dirsrv/slapd-PKI-IPA -n 'IPADOMAIN.COM IPA CA' -a > /etc/ipa/ca.crt Now add that to the Apache and 389-ds databases: # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/httpd/alias -t CT,C, -a -i /etc/ipa/ca.crt # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/dirsrv/slapd-EXAMPLE-COM -t CT,, -a -i /etc/ipa/ca.crt Next add it to /etc/pki/nssdb if it isn't already there: # certutil -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i /etc/ipa/ca.crt Next, verify that the newly issued certs are trusted: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias # certutil -V -u V -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM Both should return: certutil: certificate is valid Next is to configure the services to use the new certs. I'd stop IPA to do this: ipactl stop Edit /etc/httpd/conf.d/nss.conf and change the NSSNickname to Server-Cert Edit /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif and set nsSSLPersonalitySSL to Server-Cert Now try to start the world: ipactl start Run a few commands: # ipa user-show admin # ipa cert-show 1 Both should work. Assuming all has gone well to this point, copy /etc/ipa/ca.crt to /usr/share/ipa/html/ca.crt Finally run: ipa-ldap-updater --upgrade This should load the new CA certificate into LDAP. This has the potential to break a whole bunch of your clients. It is probably enough to just copy over the new CA cert to the right location(s) on the clients. The mechanics of this depend on the OS. > Are the TLS errors due to the mismatch in certs between slapd-PKI-CA > and slapd-NETWORKFLEET-COM? No, has nothing to do with the CA at all. The client doesn't have (or trust) the CA that issued the LDAP server cert. rob > > > -----Original Message----- > > > From: freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com > ] On Behalf Of Rob Crittenden > Sent: Wednesday, March 11, 2015 7:20 PM > To: sipazzo; freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] Need to replace cert for ipa servers > > sipazzo wrote: >> Thanks Rob, I apologize that error was probably not helpful. This is >> what I see when running install in debug mode: >> >> Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an >> IPA server Init LDAP connection with: >> ldap://ipa2-corp.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> >> The certificates are very confusing to me. I don't understand how >> things are working when we have a set of GoDaddy certs in >> slapd-NETWORKFLEET-COM and a set of the Dogtag certs in slapd-PKI-CA. >> The cert in /usr/share/ipa/html/ca.crt looks like the original one >> issued by the Dogtag cert system and matches the ones on the clients. >> Not to further confuse things but the original master server that >> signed all these certs was taken offline months ago due to some >> issues it was having. I do still have access to it if necessary. >> >> As far as why the godaddy certs were swapped out for the Dogtag certs >> it was originally for something as simple as the untrusted >> certificate dialogue when accessing the ipa gui. I did not swap out >> the certs so am unsure of exactly what happened. There is no real >> need to use the GoDaddy certs as far as I am concerned. I just want >> the best solution to the issues I am seeing as I am in kind of a bind >> with the GoDaddy cert being revoked and needing to be replaced and >> the master Dogtag certificate server offline. We have a mixed >> environment with Rhel 5, 6 and Solaris clients so are not using sssd in all cases. >> >> I know this is asking a lot but appreciate any help you can give. > > What is the current state of things? Does your IPA Apache server work? > Is 389-ds up and running? Do you have a working IPA CA? > > Does ipa cert-show 1 work? > > If the answer is yes to all then we should be able to generate new > certs for all the services. > > 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 > -- 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 Fri Mar 13 20:44:07 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 13 Mar 2015 16:44:07 -0400 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: References: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> <54F78DA0.4040801@redhat.com> <5503293D.3090308@redhat.com> Message-ID: <55034C17.7070209@redhat.com> Johnny Tan wrote: > On Fri, Mar 13, 2015 at 2:15 PM, Dmitri Pal > wrote: > > Rob would definitely know more but IPA mostly provides certs for the > infra it serves and has a limited use of the certs by itself. > So here is where I know it is used: > - You can issue certs for hosts and services and installer used to > create certs for host automatically though these certs are not used > for anything and we decided not to create them automatically any more. > - You need to trust IPA in browser so that you can do a forms based > authentication if you do not have a kerberos ticket. > - To issue certs we use Dogtag and Dogtag understands only cert > based authentication so internally the communication between the > managment framework and Dogtag uses SSL. This is actually why the > host-del fails. The host had a cert issued by IPA CA so as part of > the del operation it tries to revoke the cert but since you > reconfigured the sustem to use be CA less it can't and fails. > > The communication between the LDAP servers is Kerberos authenticated. > > > I'll wait for Rob to weigh in, but wow, this would actually be huge for > us and probably a lot of other users. Because if the above is true (and > complete, I guess), then we could actually just run a CA-less FreeIPA > setup, and then generate certs specifically and only for the web > (apache) side, which is easy enough and we do it already for all other > internal web services. That limits cert-related stuff to just one web > SSL cert per IPA master. > > > We have a special tool in Freeipa 4.2 to do this. The manual > procedure is cumbersome and leads to issues like this. > > > Yeah, I saw that, but we are still doing 3.0 on CentOS6.6, which is why > we had to go down the manual path. The CA-less install was improved in IPA 3.3. It can sorta work in 3.0 but it will be bumpy. A number of bugs were fixed in ipa-server-certinstall, the tool used to replace the IPA certs with user-provided certs. Or you can pass in PKCS#12 files during the install but the root CA is implicit in that case so you need to be careful in creating the file. You still need an SSL cert for LDAP as well. SSL is used to bootstrap replication when a new master is set up. When that is done the agreement is converted to using GSSAPI. The clients (depending on version) will still ask for a host cert on install but it is generally treated as a non-fatal error if one isn't obtained. Otherwise it should work, but as Dmitri points out you are limiting yourself upgrade-wise. The only migration paths from one version of IPA to another is replication, in which case you still wouldn't be able to add a CA, or via the LDAP migration routines which only migrate users and groups currently. rob From dpal at redhat.com Fri Mar 13 20:49:14 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 13 Mar 2015 16:49:14 -0400 Subject: [Freeipa-users] New Trust - AD id's not resolving In-Reply-To: References: Message-ID: <55034D4A.9030406@redhat.com> On 03/13/2015 04:19 PM, Gould, Joshua wrote: > I followed the directions from https://access.redhat.com/solutions/1354543 > pretty much to the letter. > > Everything was successful and seems to work well aside from the last step > of trying to resolve an AD user with the ID command on an IPA client. > > [gould at mid-ipa-vp02 ~]$ id farus at test.osuwmc > id: farus at test.osuwmc: no such user > > I enabled debugging in sssd. Here?s what I saw in the lookup for ?id > farus at test.osuwmc?. It looks like the AD is returning no match when the > account exists. > > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [be_get_account_info] (0x0200): Got request for [0x1001][1][name=farus] > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [ipa_idmap_check_posix_child] (0x0080): No forest available for domain > [S-1-5-21-226267946-722566613-1883572810]. > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [ipa_idmap_get_ranges_from_sysdb] (0x0040): ipa_idmap_check_posix_child > failed. > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not add new > domain for sid [S-1-5-21-226267946-722566613-1883572810] > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'test.osuwmc' > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [resolve_srv_send] > (0x0200): The status of SRV lookup is resolved > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [be_resolve_server_process] (0x0200): Found address for server > svr-addc-vt02.test.osuwmc: [10.80.5.240] TTL 3600 > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility > level to [4] > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'test.osuwmc' > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [resolve_srv_send] > (0x0200): The status of SRV lookup is resolved > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [be_resolve_server_process] (0x0200): Found address for server > svr-addc-vt02.test.osuwmc: [10.80.5.240] TTL 3600 > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [child_sig_handler] (0x0100): child [4587] finished successfully. > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [sdap_cli_auth_step] (0x0100): expire timeout is 900 > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] [sasl_bind_send] > (0x0100): Executing sasl bind mech: gssapi, user: > host/mid-ipa-vp01.unix.test.osuwmc > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [fo_set_port_status] (0x0100): Marking port 389 of server > 'svr-addc-vt02.test.osuwmc' as 'working' > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [set_server_common_status] (0x0100): Marking server > 'svr-addc-vt02.test.osuwmc' as 'working' > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [sdap_get_users_done] (0x0040): Failed to retrieve users > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [ipa_get_ad_acct_ad_part_done] (0x0080): Object not found, ending request > (Fri Mar 13 15:13:24 2015) [sssd[be[unix.test.osuwmc]]] > [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success > > The trust looks good. > > [gould at mid-ipa-vp01 ~]$ kinit admin > Password for admin at UNIX.TEST.OSUWMC: > [gould at mid-ipa-vp01 ~]$ ipa trust-show > Realm name: TEST.OSUWMC > Realm name: test.osuwmc > Domain NetBIOS name: TEST > Domain Security Identifier: S-1-5-21-XXXXXXXXX-XXXXXXXXX-XXXXXXXXX > Trust direction: Two-way trust > Trust type: Active Directory domain > [gould at mid-ipa-vp01 ~]$ > > > Any idea why it can?t find the match? > > Also, we?re curious why it tries to resolve POSIX when we added the trust > with --range-type=ipa-ad-trust and not --range-type=ipa-ad-trust-posix. I would leave to AD trust gurus to reply to the above. Here are the upstream pointers may be there is somethign that will give you a hint http://www.freeipa.org/page/Active_Directory_trust_setup > > Other question is how do you set or default to a one way trust when > installing instead of a two way? We know how to modify the trust in IPA > and AD, but are a bit leery since we?re not sure what all might break or > if we?re modifying all that truly needs to be modified in IPA. There is no way to turn the trust off in the current version however there is no harm in that because IPA users would not be authorized to do anything in the AD domain. They can authenticate but can not really do anything with any AD resources because those would try to get user resolved to SID to check the ACLs and IPA does not have global catalog support yet to respond to those queries. We are working to make one way trusts possible before providing global catalog service in IPA. > > > Joshua > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From johnnydtan at gmail.com Fri Mar 13 21:06:14 2015 From: johnnydtan at gmail.com (Johnny Tan) Date: Fri, 13 Mar 2015 17:06:14 -0400 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <55034C17.7070209@redhat.com> References: <1500209899.2950539.1425504749785.JavaMail.yahoo@mail.yahoo.com> <54F78DA0.4040801@redhat.com> <5503293D.3090308@redhat.com> <55034C17.7070209@redhat.com> Message-ID: On Fri, Mar 13, 2015 at 4:44 PM, Rob Crittenden wrote: > The CA-less install was improved in IPA 3.3. It can sorta work in 3.0 > but it will be bumpy. A number of bugs were fixed in > ipa-server-certinstall, the tool used to replace the IPA certs with > user-provided certs. Or you can pass in PKCS#12 files during the install > but the root CA is implicit in that case so you need to be careful in > creating the file. > > You still need an SSL cert for LDAP as well. SSL is used to bootstrap > replication when a new master is set up. When that is done the agreement > is converted to using GSSAPI. > Aha, I was about to ask about this since a CA-less install still requires dirsrv cert. Thanks. > The clients (depending on version) will still ask for a host cert on > install but it is generally treated as a non-fatal error if one isn't > obtained. > Was also going to ask about this since the v3 CA-less wiki page mentions the need to obtain host certs but is not very clear about what it was used for. > Otherwise it should work, but as Dmitri points out you are limiting > yourself upgrade-wise. The only migration paths from one version of IPA > to another is replication, in which case you still wouldn't be able to > add a CA, or via the LDAP migration routines which only migrate users > and groups currently. > Not being able to do the upgrade easily will definitely be a showstopper. Ok, I'm going to go back to attempting to sign the IPA CA with our own, then, and I'll open a separate thread if that doesn't work. I may just start from scratch with that. Thank you Dmitri and Rob for the clear/concise info. johnny -------------- next part -------------- An HTML attachment was scrubbed... URL: From rob.verduijn at gmail.com Sat Mar 14 09:50:30 2015 From: rob.verduijn at gmail.com (Rob Verduijn) Date: Sat, 14 Mar 2015 10:50:30 +0100 Subject: [Freeipa-users] OTP and cached credentials In-Reply-To: <55021295.6040607@redhat.com> References: <55021295.6040607@redhat.com> Message-ID: For which sssd release is this feature targetted ? Rob Verduijn 2015-03-12 23:26 GMT+01:00 Dmitri Pal : > On 03/12/2015 04:59 PM, Jakub Hrozek wrote: > >> On 12 Mar 2015, at 21:32, Rob Verduijn wrote: >>> >>> Hello, >>> >>> I was looking into otp authentication and found some articles on how to >>> enable this in freeipa. >>> >>> I can't seem to figure out how this is going to deal with cashed >>> credentials on a laptop that is not able to connect the ipa server. >>> >>> How is this going to work out when 'native OTP' is being used ? >>> >> I'm sorry, but currently it doesn't as with the current (sssd-1.12.x) >> version we treat the long and one-time part as a single blob, so we can't >> cache it. >> >> In the next version, we'll work on prompting for and handling the short >> and long term parts of the authtok separately, so we'll be able to cache >> credentials. >> >> Yes. Please do not use current version for laptops. > See the warning: https://access.redhat.com/documentation/en-US/Red_Hat_ > Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index. > html#otp > > -- > 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 dpal at redhat.com Sat Mar 14 15:56:11 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 14 Mar 2015 11:56:11 -0400 Subject: [Freeipa-users] OTP and cached credentials In-Reply-To: References: <55021295.6040607@redhat.com> Message-ID: <55045A1B.4030402@redhat.com> On 03/14/2015 05:50 AM, Rob Verduijn wrote: > For which sssd release is this feature targetted ? The ability to use OTP with laptops is targeted to the 1.13 release. > > Rob Verduijn > > 2015-03-12 23:26 GMT+01:00 Dmitri Pal >: > > On 03/12/2015 04:59 PM, Jakub Hrozek wrote: > > On 12 Mar 2015, at 21:32, Rob Verduijn > > > wrote: > > Hello, > > I was looking into otp authentication and found some > articles on how to enable this in freeipa. > > I can't seem to figure out how this is going to deal with > cashed credentials on a laptop that is not able to connect > the ipa server. > > How is this going to work out when 'native OTP' is being > used ? > > I'm sorry, but currently it doesn't as with the current > (sssd-1.12.x) version we treat the long and one-time part as a > single blob, so we can't cache it. > > In the next version, we'll work on prompting for and handling > the short and long term parts of the authtok separately, so > we'll be able to cache credentials. > > Yes. Please do not use current version for laptops. > See the warning: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/System-Level_Authentication_Guide/index.html#otp > > -- > 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 bentech4you at gmail.com Sun Mar 15 08:31:21 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 15 Mar 2015 11:31:21 +0300 Subject: [Freeipa-users] solaris to free IPA user issue Message-ID: HI i am using free ipa 4.1.2 on centos 7. from root user, i can able to switch to IPA user : "su ben" but from any other user if i try that, it's asking for password. if i gave the correct passord also, its not accepting .This is what i am getting bash-3.2$ su jude Password: su: Sorry and on log : Mar 15 11:21:05 kwtpocpbis02.solaris.local su: [ID 810491 auth.crit] 'su jude' failed for root on /dev/pts/1 please help me to fic this issue.. Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Sun Mar 15 10:01:30 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 15 Mar 2015 13:01:30 +0300 Subject: [Freeipa-users] solaris 10 ad authentication happening with only one user Message-ID: Hi LIst, i have successfully configured my solaris 10 with AD through IPA 4.1.2 the issue i am facing is,only one AD user can able to solaris here is the getent passwd: nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: *ben at infra.com:x:531001104:531001104:ben:/home/infra.com/ben :* auth:x:643400008:643400008:auth auth:/home/auth:/bin/sh shyam:x:643400007:643400007:shyam A:/export/home/shyam:/bin/bash jude:x:643400006:643400006:jude joseph:/export/home/jude:/bin/bash admin:x:643400000:643400000:Administrator:/home/admin:/bin/bash user ben is from AD and can able to su to that user.i have tried with other users and it's not happening. here is my configuration file: pam.conf # 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 sufficient pam_krb5.so.1 login auth required pam_unix_cred.so.1 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 sufficient pam_rhosts_auth.so.1 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 sufficient pam_rhosts_auth.so.1 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 other auth required pam_dhkeys.so.1 other auth required pam_unix_cred.so.1 other auth sufficient pam_krb5.so.1 other auth required pam_unix_auth.so.1 other auth sufficient pam_ldap.so.1 # 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 other account required pam_unix_account.so.1 other account required pam_krb5.so.1 other account sufficient pam_ldap.so.1 # # Default definition for Session management # Used when service name is not explicitly mentioned for session management # 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 # Password construction requirements apply to all users. # Remove force_check to have the traditional authorized administrator # bypass of construction requirements. other password requisite pam_authtok_check.so.1 force_check other password sufficient pam_krb5.so.1 other password required pam_authtok_store.so.1 ldap_client_file: # # Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead. # NS_LDAP_FILE_VERSION= 2.0 NS_LDAP_SERVERS= 172.16.107.244 NS_LDAP_SEARCH_BASEDN= dc=solaris,dc=local NS_LDAP_AUTH= simple NS_LDAP_CACHETTL= 0 NS_LDAP_CREDENTIAL_LEVEL= proxy NS_LDAP_SERVICE_SEARCH_DESC= group:cn=groups,cn=compat,dc=solaris,dc=local NS_LDAP_SERVICE_SEARCH_DESC= passwd:cn=users,cn=compat,dc=solaris,dc=local NS_LDAP_OBJECTCLASSMAP= shadow:shadowAccount=posixAccount nsswitch.conf: # the following two lines obviate the "+" entry in /etc/passwd and /etc/group. passwd: files ldap [NOTFOUND=return] group: files ldap [NOTFOUND=return] # consult /etc "files" only if ldap is down. hosts: dns files AD authentication is working some level and it restricted to only one user. *ben at infra.com:x:531001104:531001104:ben:/home/infra.com/ben :* auth:x:643400008:643400008:auth auth:/home/auth:/bin/sh shyam:x:643400007:643400007:shyam A:/export/home/shyam:/bin/bash jude:x:643400006:643400006:jude joseph:/export/home/jude:/bin/bash admin:x:643400000:643400000:Administrator:/home/admin:/bin/bash other than user "ben" all other users are local IPA users. how can i troubleshot this issue -------------- next part -------------- An HTML attachment was scrubbed... URL: From baghery.jone at gmail.com Sun Mar 15 13:06:48 2015 From: baghery.jone at gmail.com (alireza baghery) Date: Sun, 15 Mar 2015 16:36:48 +0330 Subject: [Freeipa-users] problem with sssd in centos 6.5 Message-ID: hi i install centos 6.5 (sssd client 1.9) when i execute any command process sssd_be on 100 percentage and when sssd_client update 1.11 ipa-client do not work how to solve this problem -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianluca.cecchi at gmail.com Sun Mar 15 16:14:08 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Sun, 15 Mar 2015 17:14:08 +0100 Subject: [Freeipa-users] solaris 10 ad authentication happening with only one user In-Reply-To: References: Message-ID: Il 15/Mar/2015 11:04 "Ben .T.George" ha scritto: > > here is the getent passwd: > > > nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: > ben at infra.com:x:531001104:531001104:ben:/home/infra.com/ben: > auth:x:643400008:643400008:auth auth:/home/auth:/bin/sh > shyam:x:643400007:643400007:shyam A:/export/home/shyam:/bin/bash > jude:x:643400006:643400006:jude joseph:/export/home/jude:/bin/bash > admin:x:643400000:643400000:Administrator:/home/admin:/bin/bash > > user ben is from AD and can able to su to that user.i have tried with other users and it's not happening. > AD authentication is working some level and it restricted to only one user. > > ben at infra.com:x:531001104:531001104:ben:/home/infra.com/ben: > auth:x:643400008:643400008:auth auth:/home/auth:/bin/sh > shyam:x:643400007:643400007:shyam A:/export/home/shyam:/bin/bash > jude:x:643400006:643400006:jude joseph:/export/home/jude:/bin/bash > admin:x:643400000:643400000:Administrator:/home/admin:/bin/bash > > other than user "ben" all other users are local IPA users. > > how can i troubleshot this issue > To be able to login, the user needs to have a shell that is the last field of the passed line that in your case is empty for Ben Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Sun Mar 15 19:30:33 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 15 Mar 2015 20:30:33 +0100 Subject: [Freeipa-users] problem with sssd in centos 6.5 In-Reply-To: References: Message-ID: <20150315193033.GB8211@Jakubs-MacBook-Pro.local> On Sun, Mar 15, 2015 at 04:36:48PM +0330, alireza baghery wrote: > hi > i install centos 6.5 (sssd client 1.9) > when i execute any command process sssd_be on 100 percentage > and when sssd_client update 1.11 ipa-client do not work > how to solve this problem I'm sorry, there's not enough information. What command does trigger sssd_be spinning up? Can you attach logs? What error do you get when updating to 1.11. How do you update to 1.11, just with yum upgrade? From Steven.Jones at vuw.ac.nz Sun Mar 15 20:04:42 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Sun, 15 Mar 2015 20:04:42 +0000 Subject: [Freeipa-users] OTP and cached credentials In-Reply-To: <55045A1B.4030402@redhat.com> References: <55021295.6040607@redhat.com> , <55045A1B.4030402@redhat.com> Message-ID: <1426449721692.30301@vuw.ac.nz> "The ability to use OTP with laptops is targeted to the 1.13 release." For my background reference, which version of RHEL will that "probably" be please? regards Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Mon Mar 16 05:57:05 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Mon, 16 Mar 2015 08:57:05 +0300 Subject: [Freeipa-users] solaris 10 ad authentication happening with only one user In-Reply-To: References: Message-ID: HI the user Ben is from Ad, how can i assign shell to that user.? Regards, Ben On Sun, Mar 15, 2015 at 7:14 PM, Gianluca Cecchi wrote: > > Il 15/Mar/2015 11:04 "Ben .T.George" ha scritto: > > > > > here is the getent passwd: > > > > > > nobody4:x:65534:65534:SunOS 4.x NFS Anonymous Access User:/: > > ben at infra.com:x:531001104:531001104:ben:/home/infra.com/ben: > > auth:x:643400008:643400008:auth auth:/home/auth:/bin/sh > > shyam:x:643400007:643400007:shyam A:/export/home/shyam:/bin/bash > > jude:x:643400006:643400006:jude joseph:/export/home/jude:/bin/bash > > admin:x:643400000:643400000:Administrator:/home/admin:/bin/bash > > > > user ben is from AD and can able to su to that user.i have tried with > other users and it's not happening. > > > AD authentication is working some level and it restricted to only one > user. > > > > ben at infra.com:x:531001104:531001104:ben:/home/infra.com/ben: > > auth:x:643400008:643400008:auth auth:/home/auth:/bin/sh > > shyam:x:643400007:643400007:shyam A:/export/home/shyam:/bin/bash > > jude:x:643400006:643400006:jude joseph:/export/home/jude:/bin/bash > > admin:x:643400000:643400000:Administrator:/home/admin:/bin/bash > > > > other than user "ben" all other users are local IPA users. > > > > how can i troubleshot this issue > > > To be able to login, the user needs to have a shell that is the last field > of the passed line that in your case is empty for Ben > > Gianluca > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gianluca.cecchi at gmail.com Mon Mar 16 07:07:37 2015 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Mon, 16 Mar 2015 08:07:37 +0100 Subject: [Freeipa-users] solaris 10 ad authentication happening with only one user In-Reply-To: References: Message-ID: On Mon, Mar 16, 2015 at 6:57 AM, Ben .T.George wrote: > HI > > the user Ben is from Ad, how can i assign shell to that user.? > > Regards, > Ben > > > Yes I know. I have not administered it so I have nt experience from a configuration point of view, but I think you have to extend your Active Directory with Identity Management for Unix, so that you can assign the necessary attributes for granting login access to Unix systems for your AD users. See here for an input... http://www.chriscowley.me.uk/blog/2013/12/16/integrating-rhel-with-active-directory/ Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Mar 16 08:55:55 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 16 Mar 2015 09:55:55 +0100 Subject: [Freeipa-users] solaris to free IPA user issue In-Reply-To: References: Message-ID: <55069A9B.6040800@redhat.com> On 03/15/2015 09:31 AM, Ben .T.George wrote: > HI > > i am using free ipa 4.1.2 on centos 7. > > from root user, i can able to switch to IPA user : "su ben" > > but from any other user if i try that, it's asking for password. if i gave > the correct passord also, its not accepting .This is what i am getting > > bash-3.2$ su jude > Password: > su: Sorry > > and on log : > > Mar 15 11:21:05 kwtpocpbis02.solaris.local su: [ID 810491 auth.crit] 'su > jude' failed for root on /dev/pts/1 > > > please help me to fic this issue.. It looks like getting the identity for those users work, while authentication does not. I think people here would need more information how to help with it, e.g. how did you set the FreeIPA integration up, given Solaris does not have standard ipa-client-install. I cannot advise myself as I am not experienced with Solaris, but I know there are several active users here on this list who are. From jhrozek at redhat.com Mon Mar 16 09:03:28 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 16 Mar 2015 10:03:28 +0100 Subject: [Freeipa-users] solaris to free IPA user issue In-Reply-To: <55069A9B.6040800@redhat.com> References: <55069A9B.6040800@redhat.com> Message-ID: <20150316090328.GC9563@hendrix.arn.redhat.com> On Mon, Mar 16, 2015 at 09:55:55AM +0100, Martin Kosek wrote: > On 03/15/2015 09:31 AM, Ben .T.George wrote: > > HI > > > > i am using free ipa 4.1.2 on centos 7. > > > > from root user, i can able to switch to IPA user : "su ben" > > > > but from any other user if i try that, it's asking for password. if i gave > > the correct passord also, its not accepting .This is what i am getting > > > > bash-3.2$ su jude > > Password: > > su: Sorry > > > > and on log : > > > > Mar 15 11:21:05 kwtpocpbis02.solaris.local su: [ID 810491 auth.crit] 'su > > jude' failed for root on /dev/pts/1 > > > > > > please help me to fic this issue.. > > It looks like getting the identity for those users work, while authentication > does not. I think people here would need more information how to help with it, > e.g. how did you set the FreeIPA integration up, given Solaris does not have > standard ipa-client-install. > > I cannot advise myself as I am not experienced with Solaris, but I know there > are several active users here on this list who are. The first step would be checking if "getent passwd" works on Solaris. We have a kind of best-effort guide: http://www.freeipa.org/page/ConfiguringUnixClients But as Rob pointed out the other day, we really don't have the experience with != Linux.. From dpal at redhat.com Mon Mar 16 12:34:19 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Mar 2015 08:34:19 -0400 Subject: [Freeipa-users] OTP and cached credentials In-Reply-To: <1426449721692.30301@vuw.ac.nz> References: <55021295.6040607@redhat.com> , <55045A1B.4030402@redhat.com> <1426449721692.30301@vuw.ac.nz> Message-ID: <5506CDCB.6050601@redhat.com> On 03/15/2015 04:04 PM, Steven Jones wrote: > "The ability to use OTP with laptops is targeted to the 1.13 release." > > For my background reference, which version of RHEL will that > "probably" be please? > > > > > regards > > Steven > > Probably 7.2 -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Mon Mar 16 16:21:10 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 16 Mar 2015 17:21:10 +0100 Subject: [Freeipa-users] Saltstack and ipa-install on Centos7 failing In-Reply-To: References: Message-ID: Hi, I think this is perhaps a bug? Thanks, Andrew On 13 March 2015 at 15:55, Andrew Holway wrote: > > > On 13 March 2015 at 15:33, Michael Lasevich wrote: > >> Is SELinux on? >> > Yes, > > ipa-server-install is running in the initrc_t domain but I guess its set > up to run unconfined > > > ps -Z with ipa-server-install run from salt-stack : > > system_u:system_r:init_t:s0 root 1568 0.0 1.4 231308 14652 ? > Ss 14:31 0:00 /bin/python2 /usr/bin/salt-minion > > system_u:system_r:initrc_t:s0 root 3101 1.0 4.8 222004 49232 ? > S 14:47 0:01 /usr/bin/python -E /usr/sbin/ipa-server-install > > ps -Z with ipa-server-install run from console : > > unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 4503 23.7 4.8 > 323356 48860 pts/1 S+ 14:53 0:00 /usr/bin/python -E > /sbin/ipa-server-install > > > On Mar 13, 2015 7:46 AM, "Andrew Holway" wrote: >> >>> Hallo >>> >>> I have a quite odd situation. I am using saltstack to set up freeipa >>> servers on Centos 7 but I am getting the following error: >>> >>> failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent >>> --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1 >>> >>> Saltstack outputs the command it is trying to run: >>> >>> ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p >>> password -n cloud.domain.de --setup-dns --unattended --no-forwarders >>> >>> However if I run this command manually on a clean machine it works fine. >>> >>> It works on Centos 6. >>> >>> >>> >>> I see this in the slapd error log: >>> >>> [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors >>> 389-Directory/1.3.1.6 B2014.219.1825 >>> freeipa-2.cloud.native-instruments.de:389 >>> (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE) >>> >>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>> /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape >>> Portable Runtime error -5966 (Access Denied.) >>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>> with other slapd processes >>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>> /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape >>> Portable Runtime error -5966 (Access Denied.) >>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>> with other slapd processes >>> [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed >>> s/NATIVE-INSTRUMENTS/DOMAIN/g >>> 389-Directory/1.3.1.6 B2014.219.1825 >>> freeipa-2.cloud.native-instruments.de:389 >>> (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE) >>> >>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >>> error -5966 (Access Denied.) >>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>> with other slapd processes >>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >>> error -5966 (Access Denied.) >>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>> with other slapd processes >>> >>> >>> >>> >>> >>> >>> >>> ipaserver-install.log >>> >>> 015-03-13T10:45:57Z DEBUG Loading StateFile from >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:57Z DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2015-03-13T10:45:57Z DEBUG httpd is not configured >>> 2015-03-13T10:45:57Z DEBUG kadmin is not configured >>> 2015-03-13T10:45:57Z DEBUG dirsrv is not configured >>> 2015-03-13T10:45:57Z DEBUG pki-cad is not configured >>> 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured >>> 2015-03-13T10:45:57Z DEBUG install is not configured >>> 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured >>> 2015-03-13T10:45:57Z DEBUG ntpd is not configured >>> 2015-03-13T10:45:57Z DEBUG named is not configured >>> 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured >>> 2015-03-13T10:45:57Z DEBUG filestore is tracking no files >>> 2015-03-13T10:45:57Z DEBUG Loading Index file from >>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>> 2015-03-13T10:45:57Z 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': >>> True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax': >>> 0, 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, >>> 'unattended': True, 'trust_sshfp': False, 'external_ca_file': None, >>> 'no_host_dns': False, 'http_pkcs12': None, 'realm_name': ' >>> CLOUD.DOMAIN.DE', 'forwarders': None, 'idstart': 1544400000, >>> 'external_ca': False, 'ip_address': None, 'conf_ssh': True, 'zonemgr': >>> None, 'root_ca_file': None, 'setup_dns': True, 'host_name': None, 'debug': >>> False, 'external_cert_file': None, 'uninstall': False} >>> 2015-03-13T10:45:57Z DEBUG missing options might be asked for >>> interactively later >>> >>> 2015-03-13T10:45:57Z DEBUG Loading Index file from >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2015-03-13T10:45:57Z DEBUG Loading StateFile from >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:57Z DEBUG Starting external process >>> 2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service >>> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:57Z DEBUG stdout=enabled >>> >>> 2015-03-13T10:45:57Z DEBUG stderr= >>> 2015-03-13T10:45:57Z DEBUG Starting external process >>> 2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS >>> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration: >>> *:8443 is a NameVirtualHost >>> default server freeipa-2.cloud.domain.de >>> (/etc/httpd/conf.d/nss.conf:86) >>> port 8443 namevhost freeipa-2.cloud.domain.de >>> (/etc/httpd/conf.d/nss.conf:86) >>> port 8443 namevhost freeipa-2.cloud.domain.de >>> (/etc/httpd/conf.d/nss.conf:86) >>> >>> 2015-03-13T10:45:57Z DEBUG stderr= >>> 2015-03-13T10:45:57Z DEBUG Check if freeipa-2.cloud.domain.de is a >>> primary hostname for localhost >>> 2015-03-13T10:45:57Z DEBUG Primary hostname for localhost: >>> freeipa-2.cloud.domain.de >>> 2015-03-13T10:45:57Z DEBUG will use host_name: freeipa-2.cloud.domain.de >>> >>> 2015-03-13T10:45:57Z DEBUG Starting external process >>> 2015-03-13T10:45:57Z DEBUG args=/sbin/ip -family inet -oneline address >>> show >>> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:57Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host >>> lo\ valid_lft forever preferred_lft forever >>> 2: eth0 inet 10.16.1.100/24 brd 10.16.1.255 scope global dynamic >>> eth0\ valid_lft 2770sec preferred_lft 2770sec >>> >>> 2015-03-13T10:45:57Z DEBUG stderr= >>> 2015-03-13T10:45:57Z DEBUG will use dns_forwarders: () >>> >>> 2015-03-13T10:45:57Z DEBUG importing all plugin modules in >>> '/usr/lib/python2.7/site-packages/ipalib/plugins'... >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' >>> 2015-03-13T10:45:57Z DEBUG Starting external process >>> 2015-03-13T10:45:57Z DEBUG args=klist -V >>> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:57Z DEBUG stdout=Kerberos 5 version 1.11.3 >>> >>> 2015-03-13T10:45:57Z DEBUG stderr= >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' >>> 2015-03-13T10:45:57Z DEBUG importing all plugin modules in >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_anonymous_aci.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >>> 2015-03-13T10:45:58Z DEBUG Adding DS group dirsrv >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/groupadd -r dirsrv >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout= >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG Done adding DS group >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled chronyd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout=enabled >>> >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active chronyd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout=active >>> >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop chronyd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout= >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl disable chronyd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout= >>> 2015-03-13T10:45:58Z DEBUG stderr=rm >>> '/etc/systemd/system/multi-user.target.wants/chronyd.service' >>> >>> 2015-03-13T10:45:58Z DEBUG Loading StateFile from >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:58Z DEBUG Configuring NTP daemon (ntpd) >>> 2015-03-13T10:45:58Z DEBUG [1/4]: stopping ntpd >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=3 >>> 2015-03-13T10:45:58Z DEBUG stdout=unknown >>> >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop ntpd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout= >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>> 2015-03-13T10:45:58Z DEBUG [2/4]: writing configuration >>> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >>> '/etc/ntp.conf' >>> 2015-03-13T10:45:58Z DEBUG Saving Index File to >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >>> '/etc/sysconfig/ntpd' >>> 2015-03-13T10:45:58Z DEBUG Saving Index File to >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>> 2015-03-13T10:45:58Z DEBUG [3/4]: configuring ntpd to start on boot >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled ntpd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=1 >>> 2015-03-13T10:45:58Z DEBUG stdout=disabled >>> >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl enable ntpd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout= >>> 2015-03-13T10:45:58Z DEBUG stderr=ln -s >>> '/usr/lib/systemd/system/ntpd.service' >>> '/etc/systemd/system/multi-user.target.wants/ntpd.service' >>> >>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>> 2015-03-13T10:45:58Z DEBUG [4/4]: starting ntpd >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl start ntpd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout= >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout=active >>> >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>> 2015-03-13T10:45:58Z DEBUG Done configuring NTP daemon (ntpd). >>> 2015-03-13T10:45:58Z DEBUG Loading StateFile from >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:58Z DEBUG Configuring directory server (dirsrv): >>> Estimated time 1 minute >>> 2015-03-13T10:45:58Z DEBUG [1/38]: creating directory server user >>> 2015-03-13T10:45:58Z DEBUG Adding DS user dirsrv >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/useradd -g dirsrv -c DS System >>> User -d /var/lib/dirsrv -s /sbin/nologin -M -r dirsrv >>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:58Z DEBUG stdout= >>> 2015-03-13T10:45:58Z DEBUG stderr= >>> 2015-03-13T10:45:58Z DEBUG Done adding DS user >>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>> 2015-03-13T10:45:58Z DEBUG [2/38]: creating directory server instance >>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>> '/var/lib/ipa/sysrestore/sysrestore.state' >>> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >>> '/etc/sysconfig/dirsrv' >>> 2015-03-13T10:45:58Z DEBUG Saving Index File to >>> '/var/lib/ipa/sysrestore/sysrestore.index' >>> 2015-03-13T10:45:58Z DEBUG >>> dn: dc=cloud,dc=domain,dc=de >>> objectClass: top >>> objectClass: domain >>> objectClass: pilotObject >>> dc: cloud >>> info: IPA V2.0 >>> >>> 2015-03-13T10:45:58Z DEBUG writing inf template >>> 2015-03-13T10:45:58Z DEBUG >>> [General] >>> FullMachineName= freeipa-2.cloud.domain.de >>> SuiteSpotUserID= dirsrv >>> SuiteSpotGroup= dirsrv >>> ServerRoot= /usr/lib64/dirsrv >>> [slapd] >>> ServerPort= 389 >>> ServerIdentifier= CLOUD-DOMAIN-DE >>> Suffix= dc=cloud,dc=domain,dc=de >>> RootDN= cn=Directory Manager >>> InstallLdifFile= /var/lib/dirsrv/boot.ldif >>> inst_dir= /var/lib/dirsrv/scripts-CLOUD-DOMAIN-DE >>> >>> 2015-03-13T10:45:58Z DEBUG calling setup-ds.pl >>> 2015-03-13T10:45:58Z DEBUG Starting external process >>> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/setup-ds.pl --silent >>> --logfile - -f /tmp/tmp5witgD >>> 2015-03-13T10:45:59Z DEBUG Process finished, return code=1 >>> 2015-03-13T10:45:59Z DEBUG stdout=[15/03/13:10:45:59] - [Setup] Info >>> Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. >>> Output: importing data ... >>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >>> error -5966 (Access Denied.) >>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>> with other slapd processes >>> >>> Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. >>> Output: importing data ... >>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >>> error -5966 (Access Denied.) >>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>> with other slapd processes >>> >>> [15/03/13:10:45:59] - [Setup] Fatal Error: Could not create directory >>> server instance 'CLOUD-DOMAIN-DE'. >>> Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. >>> [15/03/13:10:45:59] - [Setup] Fatal Exiting . . . >>> Log file is '-' >>> >>> Exiting . . . >>> Log file is '-' >>> >>> >>> 2015-03-13T10:45:59Z DEBUG stderr= >>> 2015-03-13T10:45:59Z CRITICAL failed to create ds instance Command >>> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD' returned >>> non-zero exit status 1 >>> 2015-03-13T10:45:59Z DEBUG restarting ds instance >>> 2015-03-13T10:45:59Z DEBUG Starting external process >>> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl --system daemon-reload >>> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:59Z DEBUG stdout= >>> 2015-03-13T10:45:59Z DEBUG stderr= >>> 2015-03-13T10:45:59Z DEBUG Starting external process >>> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl restart >>> dirsrv at CLOUD-DOMAIN-DE.service >>> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:59Z DEBUG stdout= >>> 2015-03-13T10:45:59Z DEBUG stderr= >>> 2015-03-13T10:45:59Z DEBUG Starting external process >>> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl is-active >>> dirsrv at CLOUD-DOMAIN-DE.service >>> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >>> 2015-03-13T10:45:59Z DEBUG stdout=active >>> >>> 2015-03-13T10:45:59Z DEBUG stderr= >>> 2015-03-13T10:45:59Z DEBUG wait_for_open_ports: localhost [389] timeout >>> 300 >>> 2015-03-13T10:50:59Z CRITICAL Failed to restart the directory server (). >>> See the installation log for details. >>> 2015-03-13T10:50:59Z DEBUG done restarting ds instance >>> 2015-03-13T10:50:59Z DEBUG duration: 301 seconds >>> 2015-03-13T10:50:59Z DEBUG [3/38]: adding default schema >>> 2015-03-13T10:50:59Z DEBUG duration: 0 seconds >>> 2015-03-13T10:50:59Z DEBUG [4/38]: enabling memberof plugin >>> 2015-03-13T10:50:59Z DEBUG wait_for_open_ports: >>> freeipa-2.cloud.domain.de [389] timeout 10 >>> 2015-03-13T10:51:09Z DEBUG Could not connect to the Directory Server on >>> freeipa-2.cloud.domain.de: >>> 2015-03-13T10:51:09Z 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-server-install", line 1059, in main >>> hbac_allow=not options.hbac_allow) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >>> 323, in create_instance >>> self.start_creation(runtime=60) >>> >>> 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/dsinstance.py", line >>> 501, in __add_memberof_module >>> self._ldap_mod("memberof-conf.ldif") >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 152, in _ldap_mod >>> self.ldap_connect() >>> >>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>> line 99, in ldap_connect >>> conn.do_simple_bind(bindpw=self.dm_password) >>> >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1735, in do_simple_bind >>> self.__bind_with_wait(self.conn.simple_bind_s, timeout, binddn, >>> bindpw) >>> >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1730, in __bind_with_wait >>> self.__wait_for_connection(timeout) >>> >>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>> 1719, in __wait_for_connection >>> wait_for_open_ports(host, int(port), timeout) >>> >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >>> 1096, in wait_for_open_ports >>> raise socket.timeout() >>> >>> 2015-03-13T10:51:09Z DEBUG The ipa-server-install command failed, >>> exception: timeout: >>> >>> -- >>> 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 ranger at opennms.org Mon Mar 16 19:01:50 2015 From: ranger at opennms.org (Benjamin Reed) Date: Mon, 16 Mar 2015 15:01:50 -0400 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) Message-ID: <5507289E.2000703@opennms.org> So given my RHEL6 machine started on an older FreeIPA 3.0, was a self-signed cert, and has gone through all kinds of hell and I'm having an impossible time setting up new master(s), I've decided to start over. I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the latest would give me the best chance at migrating. I did the following: --- 8< --- ipa-server-install ipa config-mod --enable-migration=true ipa-compat-manage disable service ipa restart # ipa-compat-manage wants a restart ipa migrate-ds \ --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \ --user-container=cn=users,cn=accounts \ --group-container=cn=groups,cn=accounts \ --group-overwrite-gid \ ldap://XXX:389 ipa-compat-manage enable ipa-config-mod --enable-mogration=false service ipa restart --- 8< --- It all seems to have (kinda) worked, I can log in to the UI as admin and see all of my users and groups. There are a couple of snags. 1. When the migration completed, it said: > Passwords have been migrated in pre-hashed format. > IPA is unable to generate Kerberos keys unless provided > with clear text passwords. All migrated users need to > login at https://your.domain/ipa/migration/ before they > can use their Kerberos accounts. If I try to actually do this as a regular user, the web UI just says: > The password or username you entered is incorrect. Please try again > (make sure your caps lock is off). > If the problem persists, contact your administrator. I'm not sure where to look in the logs to figure out what's going on, but nothing in the kerberos logs jump out at me. The dirsrv log has these: > [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should > be added before the CoS Definition. > [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should > be added before the CoS Definition. ...which seems fishy. 2. If I manually reset my user's password in the UI and then try to log in as that user, it does work, but I'd like to avoid having to hand-reset every single user's account for obvious reasons. When I *do* log in as my reset user, I always get this on the shell: > id: cannot find name for group ID 18600003 That gid is the `ipausers` GID from the old server. It appears that modern FreeIPA doesn't assign a GID to `ipausers` which is fine, but I can't figure out how to *remove* the old GID from existing users and have everything be correct. I've tried adding a group and forcing its GID to match the missing GID and deleting it again, but now it just seems to have cached it... when I do an `id` on my user, it still shows my user's GID as being 18600003(temp) even though the "temp" group has been removed. Any ideas how to do this migration properly? Thanks, Ben -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From erinn.looneytriggs at gmail.com Mon Mar 16 19:07:25 2015 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 16 Mar 2015 13:07:25 -0600 Subject: [Freeipa-users] IPA Trusts Message-ID: <2931690.KRXyViMBoP@scrapy.abaqis.com> Reading through the RHEL 7.1 documents on setting up a trust between IPA and AD I came across a note that IPA had to be managing DNS in order for this to work. Why is this? Is there any way around this? At this point the DNS IPA would manage is DNSSEC signed and as such can't be managed by IPA, it must be managed separately. Thanks, -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From abokovoy at redhat.com Mon Mar 16 19:13:56 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 16 Mar 2015 21:13:56 +0200 Subject: [Freeipa-users] IPA Trusts In-Reply-To: <2931690.KRXyViMBoP@scrapy.abaqis.com> References: <2931690.KRXyViMBoP@scrapy.abaqis.com> Message-ID: <20150316191356.GM3878@redhat.com> On Mon, 16 Mar 2015, Erinn Looney-Triggs wrote: >Reading through the RHEL 7.1 documents on setting up a trust between IPA and >AD I came across a note that IPA had to be managing DNS in order for this to >work. Why is this? Is there any way around this? At this point the DNS IPA >would manage is DNSSEC signed and as such can't be managed by IPA, it must be >managed separately. It is unfortunate that documentation turns recommendations into a mandatory statements. IPA deployment depends heavily on properly configured DNS and we provide means to maintain DNS server with IPA tools. This, however, doesn't mean DNS is required to be maintained by IPA only. Instead, a properly maintained DNS setup is required, not that it is set up and controlled by IPA means. It is easier in many cases to use IPA-managed DNS but if you know what you are doing, all we ask is to have proper DNS entries in your DNS infrastructure prior to using IPA commands which require these entries to exist (or be created, had the DNS infrastructure been managed by IPA). -- / Alexander Bokovoy From erinn.looneytriggs at gmail.com Mon Mar 16 19:16:34 2015 From: erinn.looneytriggs at gmail.com (Erinn Looney-Triggs) Date: Mon, 16 Mar 2015 13:16:34 -0600 Subject: [Freeipa-users] IPA Trusts In-Reply-To: <20150316191356.GM3878@redhat.com> References: <2931690.KRXyViMBoP@scrapy.abaqis.com> <20150316191356.GM3878@redhat.com> Message-ID: <1502500.QDS9otydpT@scrapy.abaqis.com> On Monday, March 16, 2015 09:13:56 PM Alexander Bokovoy wrote: > On Mon, 16 Mar 2015, Erinn Looney-Triggs wrote: > >Reading through the RHEL 7.1 documents on setting up a trust between IPA > >and AD I came across a note that IPA had to be managing DNS in order for > >this to work. Why is this? Is there any way around this? At this point the > >DNS IPA would manage is DNSSEC signed and as such can't be managed by IPA, > >it must be managed separately. > > It is unfortunate that documentation turns recommendations into a > mandatory statements. IPA deployment depends heavily on properly > configured DNS and we provide means to maintain DNS server with IPA > tools. This, however, doesn't mean DNS is required to be maintained by > IPA only. Instead, a properly maintained DNS setup is required, not that > it is set up and controlled by IPA means. > > It is easier in many cases to use IPA-managed DNS but if you know what > you are doing, all we ask is to have proper DNS entries in your DNS > infrastructure prior to using IPA commands which require these entries > to exist (or be created, had the DNS infrastructure been managed by > IPA). Ok thanks, I sort of figured that was probably the case, but I wanted to check to make sure. -Erinn -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: This is a digitally signed message part. URL: From Steven.Jones at vuw.ac.nz Mon Mar 16 19:49:18 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Mon, 16 Mar 2015 19:49:18 +0000 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <5507289E.2000703@opennms.org> References: <5507289E.2000703@opennms.org> Message-ID: <1426535196387.41363@vuw.ac.nz> Hi, Our present IPA started on RHEL6.2 (I think) and has a self-signed cert which has the wrong encoding. I am just replacing it now, its preventing RHEL7.1 joining/working/replicating. Now I am waiting on a BZ, so upgrading to RHEL7.1 isnt easy or quick. regards Steven ________________________________________ From: freeipa-users-bounces at redhat.com on behalf of Benjamin Reed Sent: Tuesday, 17 March 2015 8:01 a.m. To: freeipa-users at redhat.com Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) So given my RHEL6 machine started on an older FreeIPA 3.0, was a self-signed cert, and has gone through all kinds of hell and I'm having an impossible time setting up new master(s), I've decided to start over. I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the latest would give me the best chance at migrating. I did the following: --- 8< --- ipa-server-install ipa config-mod --enable-migration=true ipa-compat-manage disable service ipa restart # ipa-compat-manage wants a restart ipa migrate-ds \ --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \ --user-container=cn=users,cn=accounts \ --group-container=cn=groups,cn=accounts \ --group-overwrite-gid \ ldap://XXX:389 ipa-compat-manage enable ipa-config-mod --enable-mogration=false service ipa restart --- 8< --- It all seems to have (kinda) worked, I can log in to the UI as admin and see all of my users and groups. There are a couple of snags. 1. When the migration completed, it said: > Passwords have been migrated in pre-hashed format. > IPA is unable to generate Kerberos keys unless provided > with clear text passwords. All migrated users need to > login at https://your.domain/ipa/migration/ before they > can use their Kerberos accounts. If I try to actually do this as a regular user, the web UI just says: > The password or username you entered is incorrect. Please try again > (make sure your caps lock is off). > If the problem persists, contact your administrator. I'm not sure where to look in the logs to figure out what's going on, but nothing in the kerberos logs jump out at me. The dirsrv log has these: > [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should > be added before the CoS Definition. > [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password > Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should > be added before the CoS Definition. ...which seems fishy. 2. If I manually reset my user's password in the UI and then try to log in as that user, it does work, but I'd like to avoid having to hand-reset every single user's account for obvious reasons. When I *do* log in as my reset user, I always get this on the shell: > id: cannot find name for group ID 18600003 That gid is the `ipausers` GID from the old server. It appears that modern FreeIPA doesn't assign a GID to `ipausers` which is fine, but I can't figure out how to *remove* the old GID from existing users and have everything be correct. I've tried adding a group and forcing its GID to match the missing GID and deleting it again, but now it just seems to have cached it... when I do an `id` on my user, it still shows my user's GID as being 18600003(temp) even though the "temp" group has been removed. Any ideas how to do this migration properly? Thanks, Ben -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ From ranger at opennms.org Mon Mar 16 20:02:40 2015 From: ranger at opennms.org (Benjamin Reed) Date: Mon, 16 Mar 2015 16:02:40 -0400 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <1426535196387.41363@vuw.ac.nz> References: <5507289E.2000703@opennms.org> <1426535196387.41363@vuw.ac.nz> Message-ID: <550736E0.5020909@opennms.org> On 3/16/15 3:49 PM, Steven Jones wrote: > Our present IPA started on RHEL6.2 (I think) and has a self-signed cert which has the wrong encoding. I am just replacing it now, its preventing RHEL7.1 joining/working/replicating. Yeah, my server had the bug described here: https://bugzilla.redhat.com/show_bug.cgi?id=918262 But the `ldapdelete` fix in comment 4 fixed that for me. Even still, I'm unable to replicate. That's why I'm now attempting *not* replicating and putting together a whole new IPA setup, using "ipa migrate-ds" to move the old accounts over. The problem is, *that* doesn't work either. It appears I'm stuck with a working but un-replicatable, un-migratable FreeIPA server that's a ticking time bomb. -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ ipa-replica-manage del ipa2.opennms.com -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From nathan at nathanpeters.com Mon Mar 16 20:21:35 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Mon, 16 Mar 2015 13:21:35 -0700 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <20150305062644.GI25455@redhat.com> <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> <20150305191343.GQ25455@redhat.com> <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> Message-ID: <21287b309a10be4abc03aa6747a6b7c1.squirrel@webmail.nathanpeters.com> >and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) >into /var/ldap's database with certutil: > # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap Ok, following your advice I installed the SUNWtlsu package (prepares rant about how the top 3 pages of google results didn't tell me which darn package certutil was actually in) and now I have certutil on the system. I copied the ca.crt file from my FreeIPA controller to the /tmp directory on Solaris, and then ran #certutil -A -a -i /tmp/ca.crt -n CA -t CT -d /var/ldap It worked! The difference was that running that certutil command creates /var/ldap/secmod.db. secmod.db is required for tls to work. Without secmod.db existing, you can use simple, but not tls:simple. So I can now login with both AD and FreeIPA users on this machine, get the correct shell, correct home directory, and the ability to sudo. However... I can only do this through SSH. I have run into some really strange Solaris behavior when I try to login through console. I added the following entries to my /etc/pam.conf login auth sufficient pam_ldap.so.1 login auth sufficient pam_krb5.so.1 Apparently, Solaris has a total name limit of 31 characters, that only applies to the [login] section and not to the [other] section. So if I ssh I can login with a user named 'someusernames at subdomain1.topleveldom.net' (AD user) However, if I console login, my pam logs indicate that it is being chopped down to 'someusernames at subdomain1.toplev' before being passed onto ldap. This causes ldap to throw the following error: /usr/lib/security/pam_ldap.so.1 returned System error I created a really short AD username called 'abc at subdomain1.topleveldom.net' which just barely fit in 31 characters and it could login fine. So my next question is (and I know you guys are not Solaris experts, but any help is appreciated) : Is there a way to set the default domain so that AD users do not have to type their domain suffix? Currently, it is backward and ipa users can login as 'ipauser1' without a suffix, but AD users have to type their suffix. I know this can be done in Linux with sssd.conf and I have that working for Linux clients, but with no sssd on Solaris, I'm pulling my hair out trying to figure out how to do this. I have already tried setting the default_domain and default_realm flags in /etc/krb5/krb5.conf but that doesn't work at all because AD users are authenticated through LDAP. I also tried the ldapclient init with ' -a domainName=addomain.net' but that did not work either. Is there even a way to do this in Solaris for LDAP users? Without the ability to skip the domain name for AD users, I am stuck with either no console login for AD for having all AD users with only 3 character names due to the length of the fqdn. From nhosoi at redhat.com Mon Mar 16 20:05:54 2015 From: nhosoi at redhat.com (Noriko Hosoi) Date: Mon, 16 Mar 2015 13:05:54 -0700 Subject: [Freeipa-users] Fwd: Re: AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: <3bccb84836c1afa05d3e78e01c30bbde@unicyber.co.uk> References: <55032968.5010500@redhat.com> <55032FE4.5030208@redhat.com> <55034397.4030008@unicyber.co.uk> <550345FF.9040407@redhat.com> <55035011.9080507@redhat.com> <98c0441da909fe42d1e266c3c46b3949@unicyber.co.uk> <3bccb84836c1afa05d3e78e01c30bbde@unicyber.co.uk> Message-ID: <550737A2.10807@redhat.com> Hello, Gonzalo, Any progress on your Password Synchronization? Let me double check a couple of things. You wrote you installed PassSync on Windows 2013 (which could be a typo?) We support Windows Server 2008 R2 and 2012 R2. We also confirmed it works on Windows Server 2003 R2. > On 03/13/2015 12:45 PM,g.fer.ordas at unicyber.co.uk wrote: >> I got the Password Sync Tool installed in the Windows2013 box You can find the doc on PassSync here. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#windows-pass-sync The doc is on PassSync 1.1.5, but 1.1.6 remains intact except the default SSL version to connect to the 389 Directory Server (as we discussed before). We had a dicussion regarding the PassSync user you had to create: uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com FreeIPA is supposed to generate a PassSync user by running ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also man ipa-replica-manage)./ > there must some problem as FreeIPA > creates own Passsync user in "cn=sysaccounts,cn=etc," also sets it's DN > as passSyncManagersDNs in ipa_pwd_extop plugin to avoid it creating expired > passwords. So there is no need to create > "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" manually. Please see the above doc regarding the user creation. * The username of the system user which Active Directory uses to connect to the IdM machine. This account is configured automatically when sync is configured on the IdM server. The default account is |uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com|. * The password set in the |--passsync| option when the sync agreement was created. I'm sending this response to freeipa-users to share the info and request for more suggestions. Thanks, --noriko On 03/13/2015 02:48 PM, g.fer.ordas at unicyber.co.uk wrote: > I forgot to attach the search command now: > # passsync, users, accounts, corp.company.com > dn: uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com > cn: passsync > displayName: passsync > krbLastFailedAuth: 20150313211546Z > krbLoginFailedCount: 1 > krbExtraData:: AALUUQNVcm9vdC9hZG1pbkBDT1JQLkhPT1RTVUlURU1FRElBLkNPTQA= > memberOf: cn=ipausers,cn=groups,cn=accounts,dc=corp,dc=company,dc=com > krbLastPwdChange: 20150313210836Z > krbPasswordExpiration: 20150611210836Z > mepManagedEntry: cn=passsync,cn=groups,cn=accounts,dc=corp,dc=company,d > c=com > objectClass: top > objectClass: person > objectClass: organizationalperson > objectClass: inetorgperson > objectClass: inetuser > objectClass: posixaccount > objectClass: krbprincipalaux > objectClass: krbticketpolicyaux > objectClass: ipaobject > objectClass: ipasshuser > objectClass: ipaSshGroupOfPubKeys > objectClass: mepOriginEntry > loginShell: /bin/bash > gecos: pass sync > sn: sync > homeDirectory: /home/passsync > uid: passsync > mail: passsync at corp.company.com > krbPrincipalName: passsync at CORP.company.COM > givenName: pass > initials: ps > userPassword:: zxxxxxxxx= > = > ipaUniqueID: 1d76b14a-c9c5-11e4-93f4-12d2e19d1e3c > uidNumber: 1481000829 > gidNumber: 1481000829 > krbPrincipalKey:: dfrerererer > > # search result > search: 2 > > > On 2015-03-13 21:39, g.fer.ordas at unicyber.co.uk wrote: >> Hi >> >> I had to manually create the user!! For some reason I thought the sync >> Agreement task was also creating that entry for the DS! >> >> So now I got: >> >> [13/Mar/2015:14:27:30 -0700] conn=66 op=4 SRCH >> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >> scope=0 filter="(objectClass=*)" attrs="telephoneNumber uid title >> loginShell uidNumber gidNumber sn homeDirectory mail ou givenName >> nsAccountLock" >> [13/Mar/2015:14:27:30 -0700] conn=66 op=4 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [13/Mar/2015:14:27:30 -0700] conn=66 op=5 SRCH >> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >> scope=0 filter="(userPassword=*)" attrs="userPassword" >> [13/Mar/2015:14:27:30 -0700] conn=66 op=5 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [13/Mar/2015:14:27:30 -0700] conn=66 op=6 SRCH >> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >> scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey" >> [13/Mar/2015:14:27:30 -0700] conn=66 op=6 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [13/Mar/2015:14:27:30 -0700] conn=66 op=7 SRCH >> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >> scope=0 filter="(objectClass=*)" attrs="ipaSshPubKey" >> [13/Mar/2015:14:27:30 -0700] conn=66 op=7 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [13/Mar/2015:14:27:30 -0700] conn=66 op=8 UNBIND >> [13/Mar/2015:14:27:30 -0700] conn=66 op=8 fd=103 closed - U1 >> [13/Mar/2015:14:27:33 -0700] conn=48 op=20 RESULT err=0 tag=101 >> nentries=828 etime=90 notes=U >> [13/Mar/2015:14:27:33 -0700] conn=48 op=21 ABANDON targetop=NOTFOUND >> msgid=16 >> [13/Mar/2015:14:27:33 -0700] conn=48 op=22 SRCH >> base="cn=users,cn=accounts,dc=corp,dc=company,dc=com" scope=0 >> filter="(objectClass=*)" attrs="* aci" >> [13/Mar/2015:14:27:33 -0700] conn=48 op=22 RESULT err=0 tag=101 >> nentries=1 etime=0 >> [13/Mar/2015:14:27:33 -0700] conn=48 op=23 ABANDON targetop=NOTFOUND >> msgid=18 >> [13/Mar/2015:14:27:42 -0700] conn=67 fd=103 slot=103 connection from >> ::1 to ::1 >> [13/Mar/2015:14:27:42 -0700] conn=67 op=0 BIND dn="cn=directory >> manager" method=128 version=3 >> [13/Mar/2015:14:27:42 -0700] conn=67 op=0 RESULT err=0 tag=97 >> nentries=0 etime=0 dn="cn=directory manager" >> [13/Mar/2015:14:27:42 -0700] conn=67 op=1 SRCH >> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >> scope=2 filter="(objectClass=*)" attrs=ALL >> [13/Mar/2015:14:27:42 -0700] conn=67 op=1 RESULT err=0 tag=101 >> nentries=1 etime=0 notes=U >> [13/Mar/2015:14:27:42 -0700] conn=67 op=2 UNBIND >> [13/Mar/2015:14:27:42 -0700] conn=67 op=2 fd=103 closed - U1 >> >> And target not found??? what else I might be missing ? >> >> Thanks! >> >> >> On 2015-03-13 21:01, Noriko Hosoi wrote: >>> On 03/13/2015 01:49 PM, g.fer.ordas at unicyber.co.uk wrote: >>>> Hi >>>> >>>> Restarted... And I also have re-initiated the replica just in case.... >>>> >>>> I can see the following: >>>> --- >>>> 3/Mar/2015:13:41:35 -0700] conn=34 op=329 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [13/Mar/2015:13:41:36 -0700] conn=35 fd=84 slot=84 SSL connection >>>> from AD.SERVER to IPA.SERVER >>>> [13/Mar/2015:13:41:36 -0700] conn=35 SSL 128-bit AES >>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 BIND >>>> dn="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> method=128 version=3 >>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 RESULT err=32 tag=97 >>>> nentries=0 etime=0 >>> Error 32 is LDAP_NO_SUCH_OBJECT. >>> Do you have a user >>> "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" in your >>> Directory Server? >>> >>> On the host/VM where your Direcotry Server is running, please run this >>> command line search. Does it return the entry? >>> ldapsearch -x -h localhost -p 389 -D 'cn=directory manager' -W -b >>> "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=1 SRCH >>>> base="cn=users,cn=accounts,dc=corp,dc=company,dc=com" scope=2 >>>> filter="(ntUserDomainId=john.test)" attrs=ALL >>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=1 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [13/Mar/2015:13:41:36 -0700] conn=34 op=330 SRCH >>>> base="cn=meTohqdc1.corp.company.com,cn=replica,cn=dc\3Dcorp\2Cdc\3Dcompany\2Cdc\3Dcom,cn=mapping >>>> tree,cn=config" scope=0 filter="(objectClass=*)" >>>> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >>>> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >>>> nsds5replicaLastInitEnd" >>>> [13/Mar/2015:13:41:36 -0700] conn=34 op=330 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [13/Mar/2015:13:41:36 -0700] conn=36 fd=101 slot=101 SSL connection >>>> from AD.SERVER to IPA.SERVER >>>> [13/Mar/2015:13:41:36 -0700] conn=36 SSL 128-bit AES >>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=0 BIND >>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> method=128 version=3 >>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=0 RESULT err=48 tag=97 >>>> nentries=0 etime=0 >>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=1 UNBIND >>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=1 fd=101 closed - U1 >>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=2 MOD >>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=2 RESULT err=50 tag=103 >>>> nentries=0 etime=0 >>> Since the above bind failed, your PassSync has no right to update the >>> password on the Directory Server and the modify attempt failed with >>> LDAP_INSUFFICIENT_ACCESS. >>> >>> Thanks, >>> --noriko >>>> [13/Mar/2015:13:41:37 -0700] conn=35 op=3 UNBIND >>>> [13/Mar/2015:13:41:37 -0700] conn=35 op=3 fd=84 closed - U1 >>>> >>>> -- >>>> >>>> Note there are 2 errors there: >>>> dn="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> method=128 version=3 >>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 RESULT err=32 tag=97 >>>> nentries=0 etime=0 >>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> method=128 version=3 >>>> >>>> ipa user-show John.Test >>>> >>>> User login: john.test >>>> >>>> First name: John >>>> >>>> Last name: Test >>>> >>>> Home directory: /home/john.test >>>> >>>> Login shell: /bin/bash >>>> >>>> UID: 1481000790 >>>> >>>> GID: 1481000790 >>>> >>>> Account disabled: False >>>> >>>> Password: False >>>> >>>> Kerberos keys available: False >>>> >>>> >>>> the password is still set as False >>>> The PassSync Tool got defined as base search: >>>> >>>> cn=users,cn=accounts,dc=corp,dc=company,dc=com .. Which should be >>>> all right >>>> >>>> Thanks for all your help! >>>> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Mon Mar 16 20:56:43 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Mon, 16 Mar 2015 16:56:43 -0400 Subject: [Freeipa-users] IPA Trusts In-Reply-To: <1502500.QDS9otydpT@scrapy.abaqis.com> References: <2931690.KRXyViMBoP@scrapy.abaqis.com> <20150316191356.GM3878@redhat.com> <1502500.QDS9otydpT@scrapy.abaqis.com> Message-ID: FWIW, we have IPA working with AD managed DNS. As Alexander mentioned, you?ll need to have DNS properly configured. What I?ve found is the most critical is having the SRV records properly defined for the AD domain and the IPA domains. I kind of wish the docs were a bit clearer on which of the SRV records were needed. Ex. They list ldap but I didn?t see any mention of kerberos SRV records. On 3/16/15, 3:16 PM, "Erinn Looney-Triggs" wrote: >On Monday, March 16, 2015 09:13:56 PM Alexander Bokovoy wrote: >> On Mon, 16 Mar 2015, Erinn Looney-Triggs wrote: >> >Reading through the RHEL 7.1 documents on setting up a trust between >>IPA >> >and AD I came across a note that IPA had to be managing DNS in order >>for >> >this to work. Why is this? Is there any way around this? At this point >>the >> >DNS IPA would manage is DNSSEC signed and as such can't be managed by >>IPA, >> >it must be managed separately. >> >> It is unfortunate that documentation turns recommendations into a >> mandatory statements. IPA deployment depends heavily on properly >> configured DNS and we provide means to maintain DNS server with IPA >> tools. This, however, doesn't mean DNS is required to be maintained by >> IPA only. Instead, a properly maintained DNS setup is required, not that >> it is set up and controlled by IPA means. >> >> It is easier in many cases to use IPA-managed DNS but if you know what >> you are doing, all we ask is to have proper DNS entries in your DNS >> infrastructure prior to using IPA commands which require these entries >> to exist (or be created, had the DNS infrastructure been managed by >> IPA). > >Ok thanks, I sort of figured that was probably the case, but I wanted to >check >to make sure. > >-Erinn From andreas at superblock.se Mon Mar 16 21:03:39 2015 From: andreas at superblock.se (Andreas Skarmutsos Lindh) Date: Mon, 16 Mar 2015 22:03:39 +0100 Subject: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA Message-ID: Hi everyone, After upgrading (using rpm, yum upgrade) I can no longer login to my machines using ssh. Before the upgrade everything was working fine. Some loose facts: - I'm installing IPA packages from the RHEL repositories onto RHEL systems, so I'm not sure if this is the right mailing list to ask for assistance - I have a basic setup of IPA with minimum rules (deleted HBAC rules to single that out), using SSSD+PAM. - Both other machines that are upgraded to a more recent version of sssd and it's fellow packages and servers which was not yum upgraded are affected by the issue, thus, everything seems to point at IPA. - I'm able to obtain a kerberos ticket via kinit - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 SSH returns (adding -vvv hardly tells me anything useful): Connection closed by UNKNOWN I think that I have boiled down the issue to the following.. Both clients with upgraded sssd (1.12.2-58) and non upgraded clients (1.11.2-65) give me the following output in sssd_.log: (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync Managers Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][domain.com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][domain.com] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], ldap[0x7f571108d0e0] (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! I'm happy to attach more logs if needed. I would very much like to avoid rolling back to an older IPA version by reinstalling everything from scratch. Any and all help would be very much appreciated. Thanks in advance, Andreas -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Mar 16 21:37:16 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 16 Mar 2015 22:37:16 +0100 Subject: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA In-Reply-To: References: Message-ID: > On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh wrote: > > Hi everyone, > > After upgrading (using rpm, yum upgrade) I can no longer login to my machines using ssh. Before the upgrade everything was working fine. > > Some loose facts: > - I'm installing IPA packages from the RHEL repositories onto RHEL systems, so I'm not sure if this is the right mailing list to ask for assistance > - I have a basic setup of IPA with minimum rules (deleted HBAC rules to single that out), using SSSD+PAM. > - Both other machines that are upgraded to a more recent version of sssd and it's fellow packages and servers which was not yum upgraded are affected by the issue, thus, everything seems to point at IPA. > - I'm able to obtain a kerberos ticket via kinit > - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 > > SSH returns (adding -vvv hardly tells me anything useful): > Connection closed by UNKNOWN > > I think that I have boiled down the issue to the following.. > Both clients with upgraded sssd (1.12.2-58) and non upgraded clients (1.11.2-65) give me the following output in sssd_.log: > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync Managers Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][domain.com] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][domain.com] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], ldap[0x7f571108d0e0] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > This is a combination of a broken replication on the server side and too strict SSSD processing which can't handle unexpected entries. The broken replication has yielded entries like: cn=Modify PassSync Managers Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] note the nsUniqueID. As I learned today, entries with nsUniqueID in the RDN are relicts of broken replication. Dan Lavu (CC) has helped another setup with the same symtoms recently, maybe he can help here as well? The SSSD should just skip malformed entries if no DENY rules are used. That is tracked by SSSD ticket #2603. I have local patches for that one and I'll send them out to the list tomorrow. > I'm happy to attach more logs if needed. > I would very much like to avoid rolling back to an older IPA version by reinstalling everything from scratch. > Any and all help would be very much appreciated. > > Thanks in advance, > Andreas > -- > 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 Mon Mar 16 22:07:36 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Mar 2015 18:07:36 -0400 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <1426535196387.41363@vuw.ac.nz> References: <5507289E.2000703@opennms.org> <1426535196387.41363@vuw.ac.nz> Message-ID: <55075428.40606@redhat.com> On 03/16/2015 03:49 PM, Steven Jones wrote: > Hi, > > Our present IPA started on RHEL6.2 (I think) and has a self-signed cert which has the wrong encoding. I am just replacing it now, its preventing RHEL7.1 joining/working/replicating. > > Now I am waiting on a BZ, so upgrading to RHEL7.1 isnt easy or quick. > > regards > > Steven > ________________________________________ > From: freeipa-users-bounces at redhat.com on behalf of Benjamin Reed > Sent: Tuesday, 17 March 2015 8:01 a.m. > To: freeipa-users at redhat.com > Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) > > So given my RHEL6 machine started on an older FreeIPA 3.0, was a > self-signed cert, and has gone through all kinds of hell and I'm having > an impossible time setting up new master(s), I've decided to start over. > > I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the > latest would give me the best chance at migrating. > > I did the following: > > --- 8< --- > ipa-server-install > ipa config-mod --enable-migration=true > ipa-compat-manage disable > service ipa restart # ipa-compat-manage wants a restart > ipa migrate-ds \ > --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \ > --user-container=cn=users,cn=accounts \ > --group-container=cn=groups,cn=accounts \ > --group-overwrite-gid \ > ldap://XXX:389 > ipa-compat-manage enable > ipa-config-mod --enable-mogration=false > service ipa restart > --- 8< --- > > It all seems to have (kinda) worked, I can log in to the UI as admin and > see all of my users and groups. There are a couple of snags. > > 1. When the migration completed, it said: > >> Passwords have been migrated in pre-hashed format. >> IPA is unable to generate Kerberos keys unless provided >> with clear text passwords. All migrated users need to >> login at https://your.domain/ipa/migration/ before they >> can use their Kerberos accounts. > If I try to actually do this as a regular user, the web UI just says: > >> The password or username you entered is incorrect. Please try again >> (make sure your caps lock is off). >> If the problem persists, contact your administrator. > I'm not sure where to look in the logs to figure out what's going on, > but nothing in the kerberos logs jump out at me. The dirsrv log has these: Do not turn the migration off using ipa-config-mod --enable-mogration=false until your users migrated their passwords. The migration UI would not work if migration mode is turned off. > >> [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should >> be added before the CoS Definition. >> [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should >> be added before the CoS Definition. > ...which seems fishy. This is something for the team to take a look at. I can't say whether is an issue or a red herring. > > 2. If I manually reset my user's password in the UI and then try to log > in as that user, it does work, but I'd like to avoid having to > hand-reset every single user's account for obvious reasons. When I *do* > log in as my reset user, I always get this on the shell: > >> id: cannot find name for group ID 18600003 Did you clean the SSSD cache on the client? > That gid is the `ipausers` GID from the old server. It appears that > modern FreeIPA doesn't assign a GID to `ipausers` which is fine, but I > can't figure out how to *remove* the old GID from existing users and > have everything be correct. I've tried adding a group and forcing its > GID to match the missing GID and deleting it again, but now it just > seems to have cached it... when I do an `id` on my user, it still shows > my user's GID as being 18600003(temp) even though the "temp" group has > been removed. > > Any ideas how to do this migration properly? You want to flush caches on the clients for thing to work properly after such migration. These recommendations will get you further, let us know if you see any other issues. > > Thanks, > Ben > > -- > Benjamin Reed > The OpenNMS Group > http://www.opennms.org/ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Mar 16 22:14:51 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 16 Mar 2015 18:14:51 -0400 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <21287b309a10be4abc03aa6747a6b7c1.squirrel@webmail.nathanpeters.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <20150305062644.GI25455@redhat.com> <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> <20150305191343.GQ25455@redhat.com> <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> <21287b309a10be4abc03aa6747a6b7c1.squirrel@webmail.nathanpeters.com> Message-ID: <550755DB.5090202@redhat.com> On 03/16/2015 04:21 PM, nathan at nathanpeters.com wrote: >> and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) >> into /var/ldap's database with certutil: >> # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap > Ok, following your advice I installed the SUNWtlsu package (prepares rant > about how the top 3 pages of google results didn't tell me which darn > package certutil was actually in) and now I have certutil on the system. > I copied the ca.crt file from my FreeIPA controller to the /tmp directory > on Solaris, and then ran > #certutil -A -a -i /tmp/ca.crt -n CA -t CT -d /var/ldap > > It worked! The difference was that running that certutil command creates > /var/ldap/secmod.db. secmod.db is required for tls to work. Without > secmod.db existing, you can use simple, but not tls:simple. > > So I can now login with both AD and FreeIPA users on this machine, get the > correct shell, correct home directory, and the ability to sudo. > > However... > > I can only do this through SSH. I have run into some really strange > Solaris behavior when I try to login through console. I added the > following entries to my /etc/pam.conf > > login auth sufficient pam_ldap.so.1 > login auth sufficient pam_krb5.so.1 > > Apparently, Solaris has a total name limit of 31 characters, that only > applies to the [login] section and not to the [other] section. > > So if I ssh I can login with a user named > 'someusernames at subdomain1.topleveldom.net' (AD user) > > However, if I console login, my pam logs indicate that it is being chopped > down to 'someusernames at subdomain1.toplev' before being passed onto ldap. > This causes ldap to throw the following error: > > /usr/lib/security/pam_ldap.so.1 returned System error > > I created a really short AD username called > 'abc at subdomain1.topleveldom.net' which just barely fit in 31 characters > and it could login fine. > > So my next question is (and I know you guys are not Solaris experts, but > any help is appreciated) : Is there a way to set the default domain so > that AD users do not have to type their domain suffix? Currently, it is > backward and ipa users can login as 'ipauser1' without a suffix, but AD > users have to type their suffix. > > I know this can be done in Linux with sssd.conf and I have that working > for Linux clients, but with no sssd on Solaris, I'm pulling my hair out > trying to figure out how to do this. > > I have already tried setting the default_domain and default_realm flags in > /etc/krb5/krb5.conf but that doesn't work at all because AD users are > authenticated through LDAP. I also tried the ldapclient init with ' -a > domainName=addomain.net' but that did not work either. > > Is there even a way to do this in Solaris for LDAP users? Without the > ability to skip the domain name for AD users, I am stuck with either no > console login for AD for having all AD users with only 3 character names > due to the length of the fqdn. > > The only hack that comes to mind is to add a new attribute in the compatibility tree (cn=compat) via slapi-nis plugin that will expose short names and then point your Solaris box to that attribute as uid. This is a hack because: - you will have duplicates and this is up to you how to deal with them - you would have to figure out how to do this transformation with slapi-nis using its stock capabilities (I think it is possible but would require some research) - you would have to change the configuration on all replicas you have in the similar way May be others have better ideas. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From abokovoy at redhat.com Tue Mar 17 04:25:11 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Mar 2015 06:25:11 +0200 Subject: [Freeipa-users] AD trust users cannot login to Solaris In-Reply-To: <21287b309a10be4abc03aa6747a6b7c1.squirrel@webmail.nathanpeters.com> References: <6626850d5128a156c1859e39a84c2867.squirrel@webmail.nathanpeters.com> <20150305062644.GI25455@redhat.com> <4eaff85893c5a56af817193ddbd55bff.squirrel@webmail.nathanpeters.com> <20150305191343.GQ25455@redhat.com> <6939fc6115c4ea706633d610a4c5ede3.squirrel@webmail.nathanpeters.com> <21287b309a10be4abc03aa6747a6b7c1.squirrel@webmail.nathanpeters.com> Message-ID: <20150317042511.GN3878@redhat.com> On Mon, 16 Mar 2015, nathan at nathanpeters.com wrote: >>and put IPA's ca.crt (available on any IPA machine at /etc/ipa/ca.crt) >>into /var/ldap's database with certutil: >> # certutil -A -a -i ca.crt -n CA -t CT -d /var/ldap > >Ok, following your advice I installed the SUNWtlsu package (prepares rant >about how the top 3 pages of google results didn't tell me which darn >package certutil was actually in) and now I have certutil on the system. >I copied the ca.crt file from my FreeIPA controller to the /tmp directory >on Solaris, and then ran >#certutil -A -a -i /tmp/ca.crt -n CA -t CT -d /var/ldap > >It worked! The difference was that running that certutil command creates >/var/ldap/secmod.db. secmod.db is required for tls to work. Without >secmod.db existing, you can use simple, but not tls:simple. > >So I can now login with both AD and FreeIPA users on this machine, get the >correct shell, correct home directory, and the ability to sudo. > >However... > >I can only do this through SSH. I have run into some really strange >Solaris behavior when I try to login through console. I added the >following entries to my /etc/pam.conf > >login auth sufficient pam_ldap.so.1 >login auth sufficient pam_krb5.so.1 > >Apparently, Solaris has a total name limit of 31 characters, that only >applies to the [login] section and not to the [other] section. > >So if I ssh I can login with a user named >'someusernames at subdomain1.topleveldom.net' (AD user) > >However, if I console login, my pam logs indicate that it is being chopped >down to 'someusernames at subdomain1.toplev' before being passed onto ldap. >This causes ldap to throw the following error: > >/usr/lib/security/pam_ldap.so.1 returned System error > >I created a really short AD username called >'abc at subdomain1.topleveldom.net' which just barely fit in 31 characters >and it could login fine. > >So my next question is (and I know you guys are not Solaris experts, but >any help is appreciated) : Is there a way to set the default domain so >that AD users do not have to type their domain suffix? Currently, it is >backward and ipa users can login as 'ipauser1' without a suffix, but AD >users have to type their suffix. > >I know this can be done in Linux with sssd.conf and I have that working >for Linux clients, but with no sssd on Solaris, I'm pulling my hair out >trying to figure out how to do this. > >I have already tried setting the default_domain and default_realm flags in >/etc/krb5/krb5.conf but that doesn't work at all because AD users are >authenticated through LDAP. I also tried the ldapclient init with ' -a >domainName=addomain.net' but that did not work either. > >Is there even a way to do this in Solaris for LDAP users? Without the >ability to skip the domain name for AD users, I am stuck with either no >console login for AD for having all AD users with only 3 character names >due to the length of the fqdn. The best collection of Solaris bug numbers in this area is this blog post by Casper Dik who is member of Solaris engineering team: https://blogs.oracle.com/casper/entry/solaris_11_2_no_limits We don't have much space in the compat tree here to handle name aliases because in SSSD case there is SSSD at the client that can unwrap the name to its fully qualified form before asking IPA master for the name resolution. In the compat tree we get what we get from a client in the form of an LDAP request. Theoretically there is possibility that short names would work with FreeIPA 4.1 where we have support for ID views -- one could define ID override for AD user in a solaris-specific ID view but this is only possible in RHEL7.1 and Fedora 21. -- / Alexander Bokovoy From mkosek at redhat.com Tue Mar 17 07:31:14 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Mar 2015 08:31:14 +0100 Subject: [Freeipa-users] Saltstack and ipa-install on Centos7 failing In-Reply-To: References: Message-ID: <5507D842.30507@redhat.com> Looks like a bug, yes. I am just not sure whether in missing Saltstack SELinux module or the actual SELinux policy. You can try filing a bug to SELinux policy. Looking at SaltStack Troubleshooting guide, would switching to rpm_script_t help? http://docs.saltstack.com/en/latest/topics/troubleshooting/#salt-and-selinux On 03/16/2015 05:21 PM, Andrew Holway wrote: > Hi, > > I think this is perhaps a bug? > > Thanks, > > Andrew > > On 13 March 2015 at 15:55, Andrew Holway wrote: > >> >> >> On 13 March 2015 at 15:33, Michael Lasevich wrote: >> >>> Is SELinux on? >>> >> Yes, >> >> ipa-server-install is running in the initrc_t domain but I guess its set >> up to run unconfined >> >> >> ps -Z with ipa-server-install run from salt-stack : >> >> system_u:system_r:init_t:s0 root 1568 0.0 1.4 231308 14652 ? >> Ss 14:31 0:00 /bin/python2 /usr/bin/salt-minion >> >> system_u:system_r:initrc_t:s0 root 3101 1.0 4.8 222004 49232 ? >> S 14:47 0:01 /usr/bin/python -E /usr/sbin/ipa-server-install >> >> ps -Z with ipa-server-install run from console : >> >> unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023 root 4503 23.7 4.8 >> 323356 48860 pts/1 S+ 14:53 0:00 /usr/bin/python -E >> /sbin/ipa-server-install >> >> >> On Mar 13, 2015 7:46 AM, "Andrew Holway" wrote: >>> >>>> Hallo >>>> >>>> I have a quite odd situation. I am using saltstack to set up freeipa >>>> servers on Centos 7 but I am getting the following error: >>>> >>>> failed to create ds instance Command '/usr/sbin/setup-ds.pl --silent >>>> --logfile - -f /tmp/tmp5witgD' returned non-zero exit status 1 >>>> >>>> Saltstack outputs the command it is trying to run: >>>> >>>> ipa-server-install -a password --realm CLOUD.DOMAIN.DE -P password -p >>>> password -n cloud.domain.de --setup-dns --unattended --no-forwarders >>>> >>>> However if I run this command manually on a clean machine it works fine. >>>> >>>> It works on Centos 6. >>>> >>>> >>>> >>>> I see this in the slapd error log: >>>> >>>> [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors >>>> 389-Directory/1.3.1.6 B2014.219.1825 >>>> freeipa-2.cloud.native-instruments.de:389 >>>> (/etc/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE) >>>> >>>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>>> /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape >>>> Portable Runtime error -5966 (Access Denied.) >>>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>>> with other slapd processes >>>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>>> /var/lock/dirsrv/slapd-CLOUD-NATIVE-INSTRUMENTS-DE/imports, Netscape >>>> Portable Runtime error -5966 (Access Denied.) >>>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>>> with other slapd processes >>>> [root at freeipa-2 slapd-CLOUD-NATIVE-INSTRUMENTS-DE]# cat errors | sed >>>> s/NATIVE-INSTRUMENTS/DOMAIN/g >>>> 389-Directory/1.3.1.6 B2014.219.1825 >>>> freeipa-2.cloud.native-instruments.de:389 >>>> (/etc/dirsrv/slapd-CLOUD-DOMAIN-DE) >>>> >>>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>>> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >>>> error -5966 (Access Denied.) >>>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>>> with other slapd processes >>>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>>> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >>>> error -5966 (Access Denied.) >>>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>>> with other slapd processes >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> ipaserver-install.log >>>> >>>> 015-03-13T10:45:57Z DEBUG Loading StateFile from >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:57Z DEBUG Loading Index file from >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2015-03-13T10:45:57Z DEBUG httpd is not configured >>>> 2015-03-13T10:45:57Z DEBUG kadmin is not configured >>>> 2015-03-13T10:45:57Z DEBUG dirsrv is not configured >>>> 2015-03-13T10:45:57Z DEBUG pki-cad is not configured >>>> 2015-03-13T10:45:57Z DEBUG pki-tomcatd is not configured >>>> 2015-03-13T10:45:57Z DEBUG install is not configured >>>> 2015-03-13T10:45:57Z DEBUG krb5kdc is not configured >>>> 2015-03-13T10:45:57Z DEBUG ntpd is not configured >>>> 2015-03-13T10:45:57Z DEBUG named is not configured >>>> 2015-03-13T10:45:57Z DEBUG ipa_memcached is not configured >>>> 2015-03-13T10:45:57Z DEBUG filestore is tracking no files >>>> 2015-03-13T10:45:57Z DEBUG Loading Index file from >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>> 2015-03-13T10:45:57Z 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': >>>> True, 'ui_redirect': True, 'domain_name': 'cloud.domain.de', 'idmax': >>>> 0, 'hbac_allow': False, 'no_reverse': False, 'dirsrv_pkcs12': None, >>>> 'unattended': True, 'trust_sshfp': False, 'external_ca_file': None, >>>> 'no_host_dns': False, 'http_pkcs12': None, 'realm_name': ' >>>> CLOUD.DOMAIN.DE', 'forwarders': None, 'idstart': 1544400000, >>>> 'external_ca': False, 'ip_address': None, 'conf_ssh': True, 'zonemgr': >>>> None, 'root_ca_file': None, 'setup_dns': True, 'host_name': None, 'debug': >>>> False, 'external_cert_file': None, 'uninstall': False} >>>> 2015-03-13T10:45:57Z DEBUG missing options might be asked for >>>> interactively later >>>> >>>> 2015-03-13T10:45:57Z DEBUG Loading Index file from >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2015-03-13T10:45:57Z DEBUG Loading StateFile from >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:57Z DEBUG Starting external process >>>> 2015-03-13T10:45:57Z DEBUG args=/bin/systemctl is-enabled chronyd.service >>>> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:57Z DEBUG stdout=enabled >>>> >>>> 2015-03-13T10:45:57Z DEBUG stderr= >>>> 2015-03-13T10:45:57Z DEBUG Starting external process >>>> 2015-03-13T10:45:57Z DEBUG args=/usr/sbin/httpd -t -D DUMP_VHOSTS >>>> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:57Z DEBUG stdout=VirtualHost configuration: >>>> *:8443 is a NameVirtualHost >>>> default server freeipa-2.cloud.domain.de >>>> (/etc/httpd/conf.d/nss.conf:86) >>>> port 8443 namevhost freeipa-2.cloud.domain.de >>>> (/etc/httpd/conf.d/nss.conf:86) >>>> port 8443 namevhost freeipa-2.cloud.domain.de >>>> (/etc/httpd/conf.d/nss.conf:86) >>>> >>>> 2015-03-13T10:45:57Z DEBUG stderr= >>>> 2015-03-13T10:45:57Z DEBUG Check if freeipa-2.cloud.domain.de is a >>>> primary hostname for localhost >>>> 2015-03-13T10:45:57Z DEBUG Primary hostname for localhost: >>>> freeipa-2.cloud.domain.de >>>> 2015-03-13T10:45:57Z DEBUG will use host_name: freeipa-2.cloud.domain.de >>>> >>>> 2015-03-13T10:45:57Z DEBUG Starting external process >>>> 2015-03-13T10:45:57Z DEBUG args=/sbin/ip -family inet -oneline address >>>> show >>>> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:57Z DEBUG stdout=1: lo inet 127.0.0.1/8 scope host >>>> lo\ valid_lft forever preferred_lft forever >>>> 2: eth0 inet 10.16.1.100/24 brd 10.16.1.255 scope global dynamic >>>> eth0\ valid_lft 2770sec preferred_lft 2770sec >>>> >>>> 2015-03-13T10:45:57Z DEBUG stderr= >>>> 2015-03-13T10:45:57Z DEBUG will use dns_forwarders: () >>>> >>>> 2015-03-13T10:45:57Z DEBUG importing all plugin modules in >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins'... >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' >>>> 2015-03-13T10:45:57Z DEBUG Starting external process >>>> 2015-03-13T10:45:57Z DEBUG args=klist -V >>>> 2015-03-13T10:45:57Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:57Z DEBUG stdout=Kerberos 5 version 1.11.3 >>>> >>>> 2015-03-13T10:45:57Z DEBUG stderr= >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipalib/plugins/xmlclient.py' >>>> 2015-03-13T10:45:57Z DEBUG importing all plugin modules in >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins'... >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/adtrust.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/baseupdate.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/dns.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/fix_replica_agreements.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/rename_managed.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_anonymous_aci.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_idranges.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_pacs.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/update_services.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/updateclient.py' >>>> 2015-03-13T10:45:57Z DEBUG importing plugin module >>>> '/usr/lib/python2.7/site-packages/ipaserver/install/plugins/upload_cacrt.py' >>>> 2015-03-13T10:45:58Z DEBUG Adding DS group dirsrv >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/groupadd -r dirsrv >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout= >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG Done adding DS group >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled chronyd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout=enabled >>>> >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active chronyd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout=active >>>> >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop chronyd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout= >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl disable chronyd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout= >>>> 2015-03-13T10:45:58Z DEBUG stderr=rm >>>> '/etc/systemd/system/multi-user.target.wants/chronyd.service' >>>> >>>> 2015-03-13T10:45:58Z DEBUG Loading StateFile from >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:58Z DEBUG Configuring NTP daemon (ntpd) >>>> 2015-03-13T10:45:58Z DEBUG [1/4]: stopping ntpd >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=3 >>>> 2015-03-13T10:45:58Z DEBUG stdout=unknown >>>> >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl stop ntpd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout= >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>>> 2015-03-13T10:45:58Z DEBUG [2/4]: writing configuration >>>> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >>>> '/etc/ntp.conf' >>>> 2015-03-13T10:45:58Z DEBUG Saving Index File to >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >>>> '/etc/sysconfig/ntpd' >>>> 2015-03-13T10:45:58Z DEBUG Saving Index File to >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>>> 2015-03-13T10:45:58Z DEBUG [3/4]: configuring ntpd to start on boot >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-enabled ntpd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=1 >>>> 2015-03-13T10:45:58Z DEBUG stdout=disabled >>>> >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl enable ntpd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout= >>>> 2015-03-13T10:45:58Z DEBUG stderr=ln -s >>>> '/usr/lib/systemd/system/ntpd.service' >>>> '/etc/systemd/system/multi-user.target.wants/ntpd.service' >>>> >>>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>>> 2015-03-13T10:45:58Z DEBUG [4/4]: starting ntpd >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl start ntpd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout= >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/bin/systemctl is-active ntpd.service >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout=active >>>> >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>>> 2015-03-13T10:45:58Z DEBUG Done configuring NTP daemon (ntpd). >>>> 2015-03-13T10:45:58Z DEBUG Loading StateFile from >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:58Z DEBUG Configuring directory server (dirsrv): >>>> Estimated time 1 minute >>>> 2015-03-13T10:45:58Z DEBUG [1/38]: creating directory server user >>>> 2015-03-13T10:45:58Z DEBUG Adding DS user dirsrv >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/useradd -g dirsrv -c DS System >>>> User -d /var/lib/dirsrv -s /sbin/nologin -M -r dirsrv >>>> 2015-03-13T10:45:58Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:58Z DEBUG stdout= >>>> 2015-03-13T10:45:58Z DEBUG stderr= >>>> 2015-03-13T10:45:58Z DEBUG Done adding DS user >>>> 2015-03-13T10:45:58Z DEBUG duration: 0 seconds >>>> 2015-03-13T10:45:58Z DEBUG [2/38]: creating directory server instance >>>> 2015-03-13T10:45:58Z DEBUG Saving StateFile to >>>> '/var/lib/ipa/sysrestore/sysrestore.state' >>>> 2015-03-13T10:45:58Z DEBUG Backing up system configuration file >>>> '/etc/sysconfig/dirsrv' >>>> 2015-03-13T10:45:58Z DEBUG Saving Index File to >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2015-03-13T10:45:58Z DEBUG >>>> dn: dc=cloud,dc=domain,dc=de >>>> objectClass: top >>>> objectClass: domain >>>> objectClass: pilotObject >>>> dc: cloud >>>> info: IPA V2.0 >>>> >>>> 2015-03-13T10:45:58Z DEBUG writing inf template >>>> 2015-03-13T10:45:58Z DEBUG >>>> [General] >>>> FullMachineName= freeipa-2.cloud.domain.de >>>> SuiteSpotUserID= dirsrv >>>> SuiteSpotGroup= dirsrv >>>> ServerRoot= /usr/lib64/dirsrv >>>> [slapd] >>>> ServerPort= 389 >>>> ServerIdentifier= CLOUD-DOMAIN-DE >>>> Suffix= dc=cloud,dc=domain,dc=de >>>> RootDN= cn=Directory Manager >>>> InstallLdifFile= /var/lib/dirsrv/boot.ldif >>>> inst_dir= /var/lib/dirsrv/scripts-CLOUD-DOMAIN-DE >>>> >>>> 2015-03-13T10:45:58Z DEBUG calling setup-ds.pl >>>> 2015-03-13T10:45:58Z DEBUG Starting external process >>>> 2015-03-13T10:45:58Z DEBUG args=/usr/sbin/setup-ds.pl --silent >>>> --logfile - -f /tmp/tmp5witgD >>>> 2015-03-13T10:45:59Z DEBUG Process finished, return code=1 >>>> 2015-03-13T10:45:59Z DEBUG stdout=[15/03/13:10:45:59] - [Setup] Info >>>> Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. >>>> Output: importing data ... >>>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>>> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >>>> error -5966 (Access Denied.) >>>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>>> with other slapd processes >>>> >>>> Could not import LDIF file '/var/lib/dirsrv/boot.ldif'. Error: 256. >>>> Output: importing data ... >>>> [13/Mar/2015:10:45:59 +0000] - Error - Unable to create >>>> /var/lock/dirsrv/slapd-CLOUD-DOMAIN-DE/imports, Netscape Portable Runtime >>>> error -5966 (Access Denied.) >>>> [13/Mar/2015:10:45:59 +0000] - Shutting down due to possible conflicts >>>> with other slapd processes >>>> >>>> [15/03/13:10:45:59] - [Setup] Fatal Error: Could not create directory >>>> server instance 'CLOUD-DOMAIN-DE'. >>>> Error: Could not create directory server instance 'CLOUD-DOMAIN-DE'. >>>> [15/03/13:10:45:59] - [Setup] Fatal Exiting . . . >>>> Log file is '-' >>>> >>>> Exiting . . . >>>> Log file is '-' >>>> >>>> >>>> 2015-03-13T10:45:59Z DEBUG stderr= >>>> 2015-03-13T10:45:59Z CRITICAL failed to create ds instance Command >>>> '/usr/sbin/setup-ds.pl --silent --logfile - -f /tmp/tmp5witgD' returned >>>> non-zero exit status 1 >>>> 2015-03-13T10:45:59Z DEBUG restarting ds instance >>>> 2015-03-13T10:45:59Z DEBUG Starting external process >>>> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl --system daemon-reload >>>> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:59Z DEBUG stdout= >>>> 2015-03-13T10:45:59Z DEBUG stderr= >>>> 2015-03-13T10:45:59Z DEBUG Starting external process >>>> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl restart >>>> dirsrv at CLOUD-DOMAIN-DE.service >>>> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:59Z DEBUG stdout= >>>> 2015-03-13T10:45:59Z DEBUG stderr= >>>> 2015-03-13T10:45:59Z DEBUG Starting external process >>>> 2015-03-13T10:45:59Z DEBUG args=/bin/systemctl is-active >>>> dirsrv at CLOUD-DOMAIN-DE.service >>>> 2015-03-13T10:45:59Z DEBUG Process finished, return code=0 >>>> 2015-03-13T10:45:59Z DEBUG stdout=active >>>> >>>> 2015-03-13T10:45:59Z DEBUG stderr= >>>> 2015-03-13T10:45:59Z DEBUG wait_for_open_ports: localhost [389] timeout >>>> 300 >>>> 2015-03-13T10:50:59Z CRITICAL Failed to restart the directory server (). >>>> See the installation log for details. >>>> 2015-03-13T10:50:59Z DEBUG done restarting ds instance >>>> 2015-03-13T10:50:59Z DEBUG duration: 301 seconds >>>> 2015-03-13T10:50:59Z DEBUG [3/38]: adding default schema >>>> 2015-03-13T10:50:59Z DEBUG duration: 0 seconds >>>> 2015-03-13T10:50:59Z DEBUG [4/38]: enabling memberof plugin >>>> 2015-03-13T10:50:59Z DEBUG wait_for_open_ports: >>>> freeipa-2.cloud.domain.de [389] timeout 10 >>>> 2015-03-13T10:51:09Z DEBUG Could not connect to the Directory Server on >>>> freeipa-2.cloud.domain.de: >>>> 2015-03-13T10:51:09Z 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-server-install", line 1059, in main >>>> hbac_allow=not options.hbac_allow) >>>> >>>> File >>>> "/usr/lib/python2.7/site-packages/ipaserver/install/dsinstance.py", line >>>> 323, in create_instance >>>> self.start_creation(runtime=60) >>>> >>>> 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/dsinstance.py", line >>>> 501, in __add_memberof_module >>>> self._ldap_mod("memberof-conf.ldif") >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 152, in _ldap_mod >>>> self.ldap_connect() >>>> >>>> File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", >>>> line 99, in ldap_connect >>>> conn.do_simple_bind(bindpw=self.dm_password) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1735, in do_simple_bind >>>> self.__bind_with_wait(self.conn.simple_bind_s, timeout, binddn, >>>> bindpw) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1730, in __bind_with_wait >>>> self.__wait_for_connection(timeout) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipaldap.py", line >>>> 1719, in __wait_for_connection >>>> wait_for_open_ports(host, int(port), timeout) >>>> >>>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line >>>> 1096, in wait_for_open_ports >>>> raise socket.timeout() >>>> >>>> 2015-03-13T10:51:09Z DEBUG The ipa-server-install command failed, >>>> exception: timeout: >>>> >>>> -- >>>> 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 Tue Mar 17 07:34:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Mar 2015 08:34:01 +0100 Subject: [Freeipa-users] IPA Trusts In-Reply-To: References: <2931690.KRXyViMBoP@scrapy.abaqis.com> <20150316191356.GM3878@redhat.com> <1502500.QDS9otydpT@scrapy.abaqis.com> Message-ID: <5507D8E9.9030208@redhat.com> Joshua or Erinn, can either of you please help us improve the docs and file a bug for the Windows integration guide, about the section you are concerned with? This is a direct link: https://bugzilla.redhat.com/enter_bug.cgi?product=Red%20Hat%20Enterprise%20Linux%207&component=doc-Windows_Integration_Guide Thank you! Martin On 03/16/2015 09:56 PM, Gould, Joshua wrote: > FWIW, we have IPA working with AD managed DNS. As Alexander mentioned, > you?ll need to have DNS properly configured. What I?ve found is the most > critical is having the SRV records properly defined for the AD domain and > the IPA domains. I kind of wish the docs were a bit clearer on which of > the SRV records were needed. Ex. They list ldap but I didn?t see any > mention of kerberos SRV records. > > On 3/16/15, 3:16 PM, "Erinn Looney-Triggs" > wrote: > >> On Monday, March 16, 2015 09:13:56 PM Alexander Bokovoy wrote: >>> On Mon, 16 Mar 2015, Erinn Looney-Triggs wrote: >>>> Reading through the RHEL 7.1 documents on setting up a trust between >>> IPA >>>> and AD I came across a note that IPA had to be managing DNS in order >>> for >>>> this to work. Why is this? Is there any way around this? At this point >>> the >>>> DNS IPA would manage is DNSSEC signed and as such can't be managed by >>> IPA, >>>> it must be managed separately. >>> >>> It is unfortunate that documentation turns recommendations into a >>> mandatory statements. IPA deployment depends heavily on properly >>> configured DNS and we provide means to maintain DNS server with IPA >>> tools. This, however, doesn't mean DNS is required to be maintained by >>> IPA only. Instead, a properly maintained DNS setup is required, not that >>> it is set up and controlled by IPA means. >>> >>> It is easier in many cases to use IPA-managed DNS but if you know what >>> you are doing, all we ask is to have proper DNS entries in your DNS >>> infrastructure prior to using IPA commands which require these entries >>> to exist (or be created, had the DNS infrastructure been managed by >>> IPA). >> >> Ok thanks, I sort of figured that was probably the case, but I wanted to >> check >> to make sure. >> >> -Erinn > > > From bentech4you at gmail.com Tue Mar 17 08:37:24 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 11:37:24 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server Message-ID: HI List i was following this link : http://www.freeipa.org/page/Active_Directory_trust_setup#Assumptions to setup IPA server my IPA version is 4.1.2 every setps in this tutorials was passed without any error even "*Allow access for users from AD domain to protected resources*" went successfully my current issue is only one user called ben can able to login to ipa server.please check below: [root at kwtpocpbis01 ~]# getent passwd ben at infra.com ben at infra.com:*:531001104:531001104:ben:/home/infra.com/ben: [root at kwtpocpbis01 ~]# getent passwd bobby at infra.com [root at kwtpocpbis01 ~]# getent passwd administrator at infra.com [root at kwtpocpbis01 ~]# the users ben & bobby are on same group (Domain users). but bobby cannot able to login to IPA and not getting any information while querying please help me to fix this issue. i don't know where i need to troubleshoot this issue. thanks & Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Mar 17 09:09:22 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Mar 2015 10:09:22 +0100 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: Message-ID: <20150317090922.GL9563@hendrix.arn.redhat.com> On Tue, Mar 17, 2015 at 11:37:24AM +0300, Ben .T.George wrote: > HI List > > i was following this link : > http://www.freeipa.org/page/Active_Directory_trust_setup#Assumptions > to setup IPA server > > my IPA version is 4.1.2 > > every setps in this tutorials was passed without any error > > even "*Allow access for users from AD domain to protected resources*" > went successfully > my current issue is only one user called ben can able to login to ipa > server.please check below: > > [root at kwtpocpbis01 ~]# getent passwd ben at infra.com > ben at infra.com:*:531001104:531001104:ben:/home/infra.com/ben: > [root at kwtpocpbis01 ~]# getent passwd bobby at infra.com > [root at kwtpocpbis01 ~]# getent passwd administrator at infra.com > [root at kwtpocpbis01 ~]# > > the users ben & bobby are on same group (Domain users). but bobby cannot > able to login to IPA and not getting any information while querying > please help me to fix this issue. i don't know where i need to troubleshoot > this issue. Can you increase debug_level in both [nss] and [domain] sections on the server and paste the logs here? From bentech4you at gmail.com Tue Mar 17 09:57:27 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 12:57:27 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: <20150317090922.GL9563@hendrix.arn.redhat.com> References: <20150317090922.GL9563@hendrix.arn.redhat.com> Message-ID: HI i have enabled debug here is my sssd.conf [root at kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf [domain/solaris.local] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = solaris.local id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = kwtpocpbis01.solaris.local chpass_provider = ipa ipa_server = kwtpocpbis01.solaris.local ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = solaris.local debug_level = 6 [nss] homedir_substring = /home debug_level = 6 [pam] [sudo] [autofs] [ssh] [pac] [ifp] LOGS: sssd.log: (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging solaris.local (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging nss (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging sudo (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging pam (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging pac (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service nss replied to ping (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service sudo replied to ping (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service pam replied to ping (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service ssh replied to ping (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service solaris.local replied to ping (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service pac replied to ping error_log: [root at kwtpocpbis01 ~]# tail -f /var/log/httpd/error_log [Tue Mar 17 11:26:25.458878 2015] [:error] [pid 15175] ipa: INFO: *** PROCESS START *** [Tue Mar 17 11:26:25.603536 2015] [:error] [pid 15176] ipa: DEBUG: session_auth_duration: 0:20:00 [Tue Mar 17 11:26:25.609112 2015] [:error] [pid 15176] ipa: DEBUG: session_auth_duration: 0:20:00 [Tue Mar 17 11:26:25.655477 2015] [:error] [pid 15176] ipa: DEBUG: Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos' [Tue Mar 17 11:26:25.655597 2015] [:error] [pid 15176] ipa: DEBUG: session_auth_duration: 0:20:00 [Tue Mar 17 11:26:25.681652 2015] [:error] [pid 15176] ipa: DEBUG: Mounting ipaserver.rpcserver.login_password() at '/session/login_password' [Tue Mar 17 11:26:25.681849 2015] [:error] [pid 15176] ipa: DEBUG: session_auth_duration: 0:20:00 [Tue Mar 17 11:26:25.754351 2015] [:error] [pid 15176] ipa: INFO: *** PROCESS START *** p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute [Tue Mar 17 11:26:28.847563 2015] [:warn] [pid 15377] NSSProtocol: Unknown protocol 'tlsv1.2' not supported secure: [root at kwtpocpbis01 log]# tail -f secure Mar 17 12:35:41 kwtpocpbis01 sshd[15714]: subsystem request for sftp by user root Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: Accepted password for root from 10.18.2.130 port 64141 ssh2 Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: pam_unix(sshd:session): session opened for user root by (uid=0) Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: subsystem request for sftp by user root Mar 17 12:39:12 kwtpocpbis01 sshd[14507]: pam_unix(sshd:session): session closed for user root Mar 17 12:40:57 kwtpocpbis01 sshd[15816]: Invalid user bobby at infra.com from 10.18.2.130 Mar 17 12:40:57 kwtpocpbis01 sshd[15816]: input_userauth_request: invalid user bobby at infra.com [preauth] Mar 17 12:41:02 kwtpocpbis01 sshd[15816]: pam_unix(sshd:auth): check pass; user unknown Mar 17 12:41:02 kwtpocpbis01 sshd[15816]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.18.2.130 Mar 17 12:41:04 kwtpocpbis01 sshd[15816]: Failed password for invalid user bobby at infra.com from 10.18.2.130 port 64470 ssh2 Mar 17 12:44:56 kwtpocpbis01 sshd[15840]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.18.2.130 user=ben at infra.com Mar 17 12:44:57 kwtpocpbis01 sshd[15840]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.18.2.130 user=ben at infra.com Mar 17 12:44:57 kwtpocpbis01 sshd[15840]: Accepted password for ben at infra.com from 10.18.2.130 port 64782 ssh2 Mar 17 12:44:59 kwtpocpbis01 sshd[15840]: pam_unix(sshd:session): session opened for user ben at infra.com by (uid=0) On Tue, Mar 17, 2015 at 12:09 PM, Jakub Hrozek wrote: > On Tue, Mar 17, 2015 at 11:37:24AM +0300, Ben .T.George wrote: > > HI List > > > > i was following this link : > > http://www.freeipa.org/page/Active_Directory_trust_setup#Assumptions > > to setup IPA server > > > > my IPA version is 4.1.2 > > > > every setps in this tutorials was passed without any error > > > > even "*Allow access for users from AD domain to protected resources*" > > went successfully > > my current issue is only one user called ben can able to login to ipa > > server.please check below: > > > > [root at kwtpocpbis01 ~]# getent passwd ben at infra.com > > ben at infra.com:*:531001104:531001104:ben:/home/infra.com/ben: > > [root at kwtpocpbis01 ~]# getent passwd bobby at infra.com > > [root at kwtpocpbis01 ~]# getent passwd administrator at infra.com > > [root at kwtpocpbis01 ~]# > > > > the users ben & bobby are on same group (Domain users). but bobby cannot > > able to login to IPA and not getting any information while querying > > please help me to fix this issue. i don't know where i need to > troubleshoot > > this issue. > > Can you increase debug_level in both [nss] and [domain] sections on the > server and paste the logs here? > > -- > 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 bentech4you at gmail.com Tue Mar 17 10:06:43 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 13:06:43 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: <20150317090922.GL9563@hendrix.arn.redhat.com> Message-ID: another thing i notice is: [root at kwtpocpbis01 ~]# kinit admin Password for admin at SOLARIS.LOCAL: [root at kwtpocpbis01 ~]# ipa trust-fetch-domains infra.com ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'... ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idviews.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otpconfig.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' ipa: DEBUG: Starting external process ipa: DEBUG: args='klist' '-V' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=Kerberos 5 version 1.12.2 ipa: DEBUG: stderr= ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:admin at SOLARIS.LOCAL' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=35095713 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'pipe' '35095713' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 10:23:58 GMT; Secure; HttpOnly ipa: DEBUG: stderr= ipa: DEBUG: found session_cookie in persistent storage for principal 'admin at SOLARIS.LOCAL', cookie: 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 10:23:58 GMT; Secure; HttpOnly' ipa: DEBUG: setting session_cookie into context 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570;' ipa: INFO: trying https://kwtpocpbis01.solaris.local/ipa/session/json ipa: DEBUG: Created connection context.rpcclient ipa: DEBUG: raw: trust_fetch_domains(u'infra.com', rights=False, all=False, raw=False, version=u'2.113') ipa: DEBUG: trust_fetch_domains(u'infra.com', rights=False, all=False, raw=False, version=u'2.113') ipa: INFO: Forwarding 'trust_fetch_domains' to json server ' https://kwtpocpbis01.solaris.local/ipa/session/json' ipa: DEBUG: NSSConnection init kwtpocpbis01.solaris.local ipa: DEBUG: Connecting: 172.16.107.244:0 ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False Data: Version: 3 (0x2) Serial Number: 9 (0x9) Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=SOLARIS.LOCAL Validity: Not Before: Wed Mar 04 16:08:30 2015 UTC Not After: Sat Mar 04 16:08:30 2017 UTC Subject: CN=kwtpocpbis01.solaris.local,O=SOLARIS.LOCAL Subject Public Key Info: Public Key Algorithm: Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b7:bd:18:57:5f:27:23:87:78:32:51:25:25:2f:32:eb: b7:d7:7e:3d:91:e0:58:26:24:92:3c:c7:f3:f9:88:b6: e6:d1:61:b7:d3:f7:30:61:4e:d7:59:70:bd:62:86:a3: 51:ae:8e:ed:bc:7e:df:4d:5f:40:89:82:50:ad:a7:76: 8a:2c:83:a7:51:41:8d:d9:0f:06:6e:f9:a8:f3:7c:38: bc:af:28:14:cb:d1:ee:49:75:a0:07:c0:45:44:81:b1: 48:3d:ab:be:69:12:d2:e1:07:c7:e8:62:32:ac:88:19: 22:c5:4c:04:f8:b8:c1:57:71:c2:fc:13:fd:51:67:6d: 2a:6a:1e:f6:4a:28:95:b2:90:83:9f:f9:ca:f8:0e:10: aa:49:a4:00:76:1a:22:16:25:91:f2:d1:c7:f4:23:a5: da:40:f6:e4:5a:b3:17:56:aa:e3:3c:74:d5:30:85:1c: 54:99:0d:dc:1e:62:46:cf:a9:dc:96:82:06:08:8d:92: 56:5d:02:fe:de:00:f2:5f:c7:07:e3:ee:1c:51:32:73: f4:5c:94:c1:6d:04:ae:6d:2c:f4:4d:21:c2:da:42:db: 76:fe:f0:01:6d:69:94:25:20:68:54:20:16:be:11:51: 00:3b:2f:d8:e8:5a:6b:b8:91:ec:41:e1:8f:f6:14:eb Exponent: 65537 (0x10001) Signed Extensions: (6 total) Name: Certificate Authority Key Identifier Critical: False Key ID: 52:ae:39:5b:0b:ea:85:4d:5e:11:08:7e:55:49:c9:1c: 04:e8:76:ea Serial Number: None General Names: [0 total] Name: Authority Information Access Critical: False Authority Information Access: [1 total] Info [1]: Method: PKIX Online Certificate Status Protocol Location: URI: http://ipa-ca.solaris.local/ca/ocsp Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage Critical: False Usages: TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: CRL Distribution Points Critical: False CRL Distribution Points: [1 total] Point [1]: General Names: [1 total] http://ipa-ca.solaris.local/ipa/crl/MasterCRL.bin Issuer: Directory Name: CN=Certificate Authority,O=ipaca Reasons: () Name: Certificate Subject Key ID Critical: False Data: 29:0f:9e:4d:a1:62:bf:ae:67:ca:82:f1:c2:6b:18:20: fb:40:db:c9 Signature: Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: b7:76:76:ab:bf:ca:b0:4a:a3:7b:db:a8:fd:b3:15:4f: b6:6a:28:b5:e9:1b:55:2d:e2:f6:dc:f1:16:ee:4d:8e: b6:5b:5c:fc:0d:32:5f:07:69:92:92:01:45:f5:c5:e0: 15:b7:30:62:d2:46:c0:d7:2f:74:e8:9a:5c:99:ba:01: dc:a2:fb:02:f8:3f:31:9f:15:51:87:c0:38:c2:86:5b: 1e:dc:ab:10:a2:93:6b:88:b2:31:35:9d:ac:09:38:1b: d8:ad:19:67:96:e4:55:8e:f6:9e:e3:99:be:cd:28:16: 69:16:3d:57:b4:23:43:79:f4:22:6d:a7:07:55:59:6e: a0:b7:23:99:7c:4d:28:55:fb:88:88:e8:24:f0:67:af: 4a:f5:b8:60:b6:d1:5d:42:10:6f:9f:83:c0:9c:db:d2: 12:4d:ac:18:d0:17:c1:e3:77:83:c7:14:13:1f:73:d0: f3:ee:25:bb:72:cb:6d:bb:da:4b:ca:fc:25:ea:09:0a: 09:5f:6e:51:3d:e2:5e:63:9c:0f:d5:4f:cb:d8:88:be: 4c:e6:b2:05:74:ed:2e:25:72:c4:0a:c7:84:47:97:28: 79:a5:a0:1d:6d:b4:86:55:e7:61:3f:df:db:1c:cc:37: 24:a7:3e:40:35:12:f9:45:08:d6:3f:ca:74:34:51:ee Fingerprint (MD5): 73:b9:df:20:b1:f5:b7:29:55:de:88:88:9f:8b:ab:e7 Fingerprint (SHA1): 91:83:4b:fa:2f:c0:dc:3e:cc:e4:35:bf:69:f3:db:6c: 7f:ca:1b:21 ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server ipa: DEBUG: cert valid True for "CN=kwtpocpbis01.solaris.local,O=SOLARIS.LOCAL" ipa: DEBUG: handshake complete, peer = 172.16.107.244:443 ipa: DEBUG: received Set-Cookie 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 10:24:32 GMT; Secure; HttpOnly' ipa: DEBUG: storing cookie 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 10:24:32 GMT; Secure; HttpOnly' for principal admin at SOLARIS.LOCAL ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:admin at SOLARIS.LOCAL' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=35095713 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:admin at SOLARIS.LOCAL' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=35095713 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'pupdate' '35095713' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: DEBUG: Destroyed connection context.rpcclient ipa: ERROR: Insufficient access: CIFS server denied your credentials and it accepting password for admin and i can able to see tickets: [root at kwtpocpbis01 ~]# klist Ticket cache: KEYRING:persistent:0:0 Default principal: admin at SOLARIS.LOCAL Valid starting Expires Service principal 03/17/2015 13:04:29 03/18/2015 13:04:26 krbtgt/SOLARIS.LOCAL at SOLARIS.LOCAL On Tue, Mar 17, 2015 at 12:57 PM, Ben .T.George wrote: > HI > > i have enabled debug > > here is my sssd.conf > > [root at kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf > [domain/solaris.local] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = solaris.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = kwtpocpbis01.solaris.local > chpass_provider = ipa > ipa_server = kwtpocpbis01.solaris.local > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > > domains = solaris.local > debug_level = 6 > [nss] > homedir_substring = /home > debug_level = 6 > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] > > > LOGS: > > sssd.log: > > (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging > solaris.local > (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging nss > (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging > sudo > (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging pam > (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh > (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging pac > (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service nss > replied to ping > (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service sudo > replied to ping > (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service pam > replied to ping > (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service ssh > replied to ping > (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service > solaris.local replied to ping > (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service pac > replied to ping > > > error_log: > > [root at kwtpocpbis01 ~]# tail -f /var/log/httpd/error_log > [Tue Mar 17 11:26:25.458878 2015] [:error] [pid 15175] ipa: INFO: *** > PROCESS START *** > [Tue Mar 17 11:26:25.603536 2015] [:error] [pid 15176] ipa: DEBUG: > session_auth_duration: 0:20:00 > [Tue Mar 17 11:26:25.609112 2015] [:error] [pid 15176] ipa: DEBUG: > session_auth_duration: 0:20:00 > [Tue Mar 17 11:26:25.655477 2015] [:error] [pid 15176] ipa: DEBUG: > Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos' > [Tue Mar 17 11:26:25.655597 2015] [:error] [pid 15176] ipa: DEBUG: > session_auth_duration: 0:20:00 > [Tue Mar 17 11:26:25.681652 2015] [:error] [pid 15176] ipa: DEBUG: > Mounting ipaserver.rpcserver.login_password() at '/session/login_password' > [Tue Mar 17 11:26:25.681849 2015] [:error] [pid 15176] ipa: DEBUG: > session_auth_duration: 0:20:00 > [Tue Mar 17 11:26:25.754351 2015] [:error] [pid 15176] ipa: INFO: *** > PROCESS START *** > p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute > [Tue Mar 17 11:26:28.847563 2015] [:warn] [pid 15377] NSSProtocol: > Unknown protocol 'tlsv1.2' not supported > > secure: > [root at kwtpocpbis01 log]# tail -f secure > Mar 17 12:35:41 kwtpocpbis01 sshd[15714]: subsystem request for sftp by > user root > Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: Accepted password for root from > 10.18.2.130 port 64141 ssh2 > Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: pam_unix(sshd:session): session > opened for user root by (uid=0) > Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: subsystem request for sftp by > user root > Mar 17 12:39:12 kwtpocpbis01 sshd[14507]: pam_unix(sshd:session): session > closed for user root > Mar 17 12:40:57 kwtpocpbis01 sshd[15816]: Invalid user bobby at infra.com > from 10.18.2.130 > Mar 17 12:40:57 kwtpocpbis01 sshd[15816]: input_userauth_request: invalid > user bobby at infra.com [preauth] > Mar 17 12:41:02 kwtpocpbis01 sshd[15816]: pam_unix(sshd:auth): check pass; > user unknown > Mar 17 12:41:02 kwtpocpbis01 sshd[15816]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.18.2.130 > Mar 17 12:41:04 kwtpocpbis01 sshd[15816]: Failed password for invalid user > bobby at infra.com from 10.18.2.130 port 64470 ssh2 > > Mar 17 12:44:56 kwtpocpbis01 sshd[15840]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.18.2.130 user=ben at infra.com > Mar 17 12:44:57 kwtpocpbis01 sshd[15840]: pam_sss(sshd:auth): > authentication success; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.18.2.130 user=ben at infra.com > Mar 17 12:44:57 kwtpocpbis01 sshd[15840]: Accepted password for > ben at infra.com from 10.18.2.130 port 64782 ssh2 > Mar 17 12:44:59 kwtpocpbis01 sshd[15840]: pam_unix(sshd:session): session > opened for user ben at infra.com by (uid=0) > > > > On Tue, Mar 17, 2015 at 12:09 PM, Jakub Hrozek wrote: > >> On Tue, Mar 17, 2015 at 11:37:24AM +0300, Ben .T.George wrote: >> > HI List >> > >> > i was following this link : >> > http://www.freeipa.org/page/Active_Directory_trust_setup#Assumptions >> > to setup IPA server >> > >> > my IPA version is 4.1.2 >> > >> > every setps in this tutorials was passed without any error >> > >> > even "*Allow access for users from AD domain to protected resources*" >> > went successfully >> > my current issue is only one user called ben can able to login to ipa >> > server.please check below: >> > >> > [root at kwtpocpbis01 ~]# getent passwd ben at infra.com >> > ben at infra.com:*:531001104:531001104:ben:/home/infra.com/ben: >> > [root at kwtpocpbis01 ~]# getent passwd bobby at infra.com >> > [root at kwtpocpbis01 ~]# getent passwd administrator at infra.com >> > [root at kwtpocpbis01 ~]# >> > >> > the users ben & bobby are on same group (Domain users). but bobby cannot >> > able to login to IPA and not getting any information while querying >> > please help me to fix this issue. i don't know where i need to >> troubleshoot >> > this issue. >> >> Can you increase debug_level in both [nss] and [domain] sections on the >> server and paste the logs here? >> >> -- >> 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 bentech4you at gmail.com Tue Mar 17 10:09:05 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 13:09:05 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: <20150317090922.GL9563@hendrix.arn.redhat.com> Message-ID: i tried to establish trust again and got below output. Is this the expected one. i can see " Insufficient access: CIFS server denied your credentials" here too. [root at kwtpocpbis01 ~]# ipa trust-add --type=ad infra.com --admin Administrator --password ipa: DEBUG: importing all plugin modules in '/usr/lib/python2.7/site-packages/ipalib/plugins'... ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/idviews.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otpconfig.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' ipa: DEBUG: Starting external process ipa: DEBUG: args='klist' '-V' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=Kerberos 5 version 1.12.2 ipa: DEBUG: stderr= ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' ipa: DEBUG: importing plugin module '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:admin at SOLARIS.LOCAL' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=35095713 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'pipe' '35095713' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 10:24:32 GMT; Secure; HttpOnly ipa: DEBUG: stderr= ipa: DEBUG: found session_cookie in persistent storage for principal 'admin at SOLARIS.LOCAL', cookie: 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 10:24:32 GMT; Secure; HttpOnly' ipa: DEBUG: setting session_cookie into context 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570;' ipa: INFO: trying https://kwtpocpbis01.solaris.local/ipa/session/json ipa: DEBUG: Created connection context.rpcclient Active Directory domain administrator's password: ipa: DEBUG: raw: trust_add(u'infra.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', all=False, raw=False, version=u'2.113') ipa: DEBUG: trust_add(u'infra.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', all=False, raw=False, version=u'2.113') ipa: INFO: Forwarding 'trust_add' to json server ' https://kwtpocpbis01.solaris.local/ipa/session/json' ipa: DEBUG: NSSConnection init kwtpocpbis01.solaris.local ipa: DEBUG: Connecting: 172.16.107.244:0 ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False Data: Version: 3 (0x2) Serial Number: 9 (0x9) Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Issuer: CN=Certificate Authority,O=SOLARIS.LOCAL Validity: Not Before: Wed Mar 04 16:08:30 2015 UTC Not After: Sat Mar 04 16:08:30 2017 UTC Subject: CN=kwtpocpbis01.solaris.local,O=SOLARIS.LOCAL Subject Public Key Info: Public Key Algorithm: Algorithm: PKCS #1 RSA Encryption RSA Public Key: Modulus: b7:bd:18:57:5f:27:23:87:78:32:51:25:25:2f:32:eb: b7:d7:7e:3d:91:e0:58:26:24:92:3c:c7:f3:f9:88:b6: e6:d1:61:b7:d3:f7:30:61:4e:d7:59:70:bd:62:86:a3: 51:ae:8e:ed:bc:7e:df:4d:5f:40:89:82:50:ad:a7:76: 8a:2c:83:a7:51:41:8d:d9:0f:06:6e:f9:a8:f3:7c:38: bc:af:28:14:cb:d1:ee:49:75:a0:07:c0:45:44:81:b1: 48:3d:ab:be:69:12:d2:e1:07:c7:e8:62:32:ac:88:19: 22:c5:4c:04:f8:b8:c1:57:71:c2:fc:13:fd:51:67:6d: 2a:6a:1e:f6:4a:28:95:b2:90:83:9f:f9:ca:f8:0e:10: aa:49:a4:00:76:1a:22:16:25:91:f2:d1:c7:f4:23:a5: da:40:f6:e4:5a:b3:17:56:aa:e3:3c:74:d5:30:85:1c: 54:99:0d:dc:1e:62:46:cf:a9:dc:96:82:06:08:8d:92: 56:5d:02:fe:de:00:f2:5f:c7:07:e3:ee:1c:51:32:73: f4:5c:94:c1:6d:04:ae:6d:2c:f4:4d:21:c2:da:42:db: 76:fe:f0:01:6d:69:94:25:20:68:54:20:16:be:11:51: 00:3b:2f:d8:e8:5a:6b:b8:91:ec:41:e1:8f:f6:14:eb Exponent: 65537 (0x10001) Signed Extensions: (6 total) Name: Certificate Authority Key Identifier Critical: False Key ID: 52:ae:39:5b:0b:ea:85:4d:5e:11:08:7e:55:49:c9:1c: 04:e8:76:ea Serial Number: None General Names: [0 total] Name: Authority Information Access Critical: False Authority Information Access: [1 total] Info [1]: Method: PKIX Online Certificate Status Protocol Location: URI: http://ipa-ca.solaris.local/ca/ocsp Name: Certificate Key Usage Critical: True Usages: Digital Signature Non-Repudiation Key Encipherment Data Encipherment Name: Extended Key Usage Critical: False Usages: TLS Web Server Authentication Certificate TLS Web Client Authentication Certificate Name: CRL Distribution Points Critical: False CRL Distribution Points: [1 total] Point [1]: General Names: [1 total] http://ipa-ca.solaris.local/ipa/crl/MasterCRL.bin Issuer: Directory Name: CN=Certificate Authority,O=ipaca Reasons: () Name: Certificate Subject Key ID Critical: False Data: 29:0f:9e:4d:a1:62:bf:ae:67:ca:82:f1:c2:6b:18:20: fb:40:db:c9 Signature: Signature Algorithm: Algorithm: PKCS #1 SHA-256 With RSA Encryption Signature: b7:76:76:ab:bf:ca:b0:4a:a3:7b:db:a8:fd:b3:15:4f: b6:6a:28:b5:e9:1b:55:2d:e2:f6:dc:f1:16:ee:4d:8e: b6:5b:5c:fc:0d:32:5f:07:69:92:92:01:45:f5:c5:e0: 15:b7:30:62:d2:46:c0:d7:2f:74:e8:9a:5c:99:ba:01: dc:a2:fb:02:f8:3f:31:9f:15:51:87:c0:38:c2:86:5b: 1e:dc:ab:10:a2:93:6b:88:b2:31:35:9d:ac:09:38:1b: d8:ad:19:67:96:e4:55:8e:f6:9e:e3:99:be:cd:28:16: 69:16:3d:57:b4:23:43:79:f4:22:6d:a7:07:55:59:6e: a0:b7:23:99:7c:4d:28:55:fb:88:88:e8:24:f0:67:af: 4a:f5:b8:60:b6:d1:5d:42:10:6f:9f:83:c0:9c:db:d2: 12:4d:ac:18:d0:17:c1:e3:77:83:c7:14:13:1f:73:d0: f3:ee:25:bb:72:cb:6d:bb:da:4b:ca:fc:25:ea:09:0a: 09:5f:6e:51:3d:e2:5e:63:9c:0f:d5:4f:cb:d8:88:be: 4c:e6:b2:05:74:ed:2e:25:72:c4:0a:c7:84:47:97:28: 79:a5:a0:1d:6d:b4:86:55:e7:61:3f:df:db:1c:cc:37: 24:a7:3e:40:35:12:f9:45:08:d6:3f:ca:74:34:51:ee Fingerprint (MD5): 73:b9:df:20:b1:f5:b7:29:55:de:88:88:9f:8b:ab:e7 Fingerprint (SHA1): 91:83:4b:fa:2f:c0:dc:3e:cc:e4:35:bf:69:f3:db:6c: 7f:ca:1b:21 ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server ipa: DEBUG: cert valid True for "CN=kwtpocpbis01.solaris.local,O=SOLARIS.LOCAL" ipa: DEBUG: handshake complete, peer = 172.16.107.244:443 ipa: DEBUG: received Set-Cookie 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 10:27:04 GMT; Secure; HttpOnly' ipa: DEBUG: storing cookie 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 10:27:04 GMT; Secure; HttpOnly' for principal admin at SOLARIS.LOCAL ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:admin at SOLARIS.LOCAL' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=35095713 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'search' '@s' 'user' 'ipa_session_cookie:admin at SOLARIS.LOCAL' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout=35095713 ipa: DEBUG: stderr= ipa: DEBUG: Starting external process ipa: DEBUG: args='keyctl' 'pupdate' '35095713' ipa: DEBUG: Process finished, return code=0 ipa: DEBUG: stdout= ipa: DEBUG: stderr= ipa: DEBUG: Destroyed connection context.rpcclient ipa: ERROR: Insufficient access: CIFS server denied your credentials On Tue, Mar 17, 2015 at 1:06 PM, Ben .T.George wrote: > another thing i notice is: > > [root at kwtpocpbis01 ~]# kinit admin > Password for admin at SOLARIS.LOCAL: > [root at kwtpocpbis01 ~]# ipa trust-fetch-domains infra.com > ipa: DEBUG: importing all plugin modules in > '/usr/lib/python2.7/site-packages/ipalib/plugins'... > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/aci.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automember.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/automount.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/baseldap.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/batch.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/cert.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/config.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/delegation.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/dns.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/group.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacrule.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvc.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbacsvcgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hbactest.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/host.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/hostgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/idrange.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/idviews.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/internal.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/kerberos.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/krbtpolicy.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/migration.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/misc.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/netgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/otpconfig.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/otptoken_yubikey.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/passwd.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/permission.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/ping.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pkinit.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/privilege.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/pwpolicy.py' > ipa: DEBUG: Starting external process > ipa: DEBUG: args='klist' '-V' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=Kerberos 5 version 1.12.2 > > ipa: DEBUG: stderr= > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/radiusproxy.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/realmdomains.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/role.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/rpcclient.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selfservice.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/selinuxusermap.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/service.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmd.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudocmdgroup.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/sudorule.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/user.py' > ipa: DEBUG: importing plugin module > '/usr/lib/python2.7/site-packages/ipalib/plugins/virtual.py' > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' > 'ipa_session_cookie:admin at SOLARIS.LOCAL' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=35095713 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'pipe' '35095713' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; > Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 > 10:23:58 GMT; Secure; HttpOnly > ipa: DEBUG: stderr= > ipa: DEBUG: found session_cookie in persistent storage for principal > 'admin at SOLARIS.LOCAL', cookie: > 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; > Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 > 10:23:58 GMT; Secure; HttpOnly' > ipa: DEBUG: setting session_cookie into context > 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570;' > ipa: INFO: trying https://kwtpocpbis01.solaris.local/ipa/session/json > ipa: DEBUG: Created connection context.rpcclient > ipa: DEBUG: raw: trust_fetch_domains(u'infra.com', rights=False, > all=False, raw=False, version=u'2.113') > ipa: DEBUG: trust_fetch_domains(u'infra.com', rights=False, all=False, > raw=False, version=u'2.113') > ipa: INFO: Forwarding 'trust_fetch_domains' to json server ' > https://kwtpocpbis01.solaris.local/ipa/session/json' > ipa: DEBUG: NSSConnection init kwtpocpbis01.solaris.local > ipa: DEBUG: Connecting: 172.16.107.244:0 > ipa: DEBUG: auth_certificate_callback: check_sig=True is_server=False > Data: > Version: 3 (0x2) > Serial Number: 9 (0x9) > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Issuer: CN=Certificate Authority,O=SOLARIS.LOCAL > Validity: > Not Before: Wed Mar 04 16:08:30 2015 UTC > Not After: Sat Mar 04 16:08:30 2017 UTC > Subject: CN=kwtpocpbis01.solaris.local,O=SOLARIS.LOCAL > Subject Public Key Info: > Public Key Algorithm: > Algorithm: PKCS #1 RSA Encryption > RSA Public Key: > Modulus: > b7:bd:18:57:5f:27:23:87:78:32:51:25:25:2f:32:eb: > b7:d7:7e:3d:91:e0:58:26:24:92:3c:c7:f3:f9:88:b6: > e6:d1:61:b7:d3:f7:30:61:4e:d7:59:70:bd:62:86:a3: > 51:ae:8e:ed:bc:7e:df:4d:5f:40:89:82:50:ad:a7:76: > 8a:2c:83:a7:51:41:8d:d9:0f:06:6e:f9:a8:f3:7c:38: > bc:af:28:14:cb:d1:ee:49:75:a0:07:c0:45:44:81:b1: > 48:3d:ab:be:69:12:d2:e1:07:c7:e8:62:32:ac:88:19: > 22:c5:4c:04:f8:b8:c1:57:71:c2:fc:13:fd:51:67:6d: > 2a:6a:1e:f6:4a:28:95:b2:90:83:9f:f9:ca:f8:0e:10: > aa:49:a4:00:76:1a:22:16:25:91:f2:d1:c7:f4:23:a5: > da:40:f6:e4:5a:b3:17:56:aa:e3:3c:74:d5:30:85:1c: > 54:99:0d:dc:1e:62:46:cf:a9:dc:96:82:06:08:8d:92: > 56:5d:02:fe:de:00:f2:5f:c7:07:e3:ee:1c:51:32:73: > f4:5c:94:c1:6d:04:ae:6d:2c:f4:4d:21:c2:da:42:db: > 76:fe:f0:01:6d:69:94:25:20:68:54:20:16:be:11:51: > 00:3b:2f:d8:e8:5a:6b:b8:91:ec:41:e1:8f:f6:14:eb > Exponent: > 65537 (0x10001) > Signed Extensions: (6 total) > Name: Certificate Authority Key Identifier > Critical: False > Key ID: > 52:ae:39:5b:0b:ea:85:4d:5e:11:08:7e:55:49:c9:1c: > 04:e8:76:ea > Serial Number: None > General Names: [0 total] > > Name: Authority Information Access > Critical: False > Authority Information Access: [1 total] > Info [1]: > Method: PKIX Online Certificate Status Protocol > Location: URI: http://ipa-ca.solaris.local/ca/ocsp > > Name: Certificate Key Usage > Critical: True > Usages: > Digital Signature > Non-Repudiation > Key Encipherment > Data Encipherment > > Name: Extended Key Usage > Critical: False > Usages: > TLS Web Server Authentication Certificate > TLS Web Client Authentication Certificate > > Name: CRL Distribution Points > Critical: False > CRL Distribution Points: [1 total] > Point [1]: > General Names: [1 total] > http://ipa-ca.solaris.local/ipa/crl/MasterCRL.bin > Issuer: Directory Name: CN=Certificate Authority,O=ipaca > Reasons: () > > Name: Certificate Subject Key ID > Critical: False > Data: > 29:0f:9e:4d:a1:62:bf:ae:67:ca:82:f1:c2:6b:18:20: > fb:40:db:c9 > > Signature: > Signature Algorithm: > Algorithm: PKCS #1 SHA-256 With RSA Encryption > Signature: > b7:76:76:ab:bf:ca:b0:4a:a3:7b:db:a8:fd:b3:15:4f: > b6:6a:28:b5:e9:1b:55:2d:e2:f6:dc:f1:16:ee:4d:8e: > b6:5b:5c:fc:0d:32:5f:07:69:92:92:01:45:f5:c5:e0: > 15:b7:30:62:d2:46:c0:d7:2f:74:e8:9a:5c:99:ba:01: > dc:a2:fb:02:f8:3f:31:9f:15:51:87:c0:38:c2:86:5b: > 1e:dc:ab:10:a2:93:6b:88:b2:31:35:9d:ac:09:38:1b: > d8:ad:19:67:96:e4:55:8e:f6:9e:e3:99:be:cd:28:16: > 69:16:3d:57:b4:23:43:79:f4:22:6d:a7:07:55:59:6e: > a0:b7:23:99:7c:4d:28:55:fb:88:88:e8:24:f0:67:af: > 4a:f5:b8:60:b6:d1:5d:42:10:6f:9f:83:c0:9c:db:d2: > 12:4d:ac:18:d0:17:c1:e3:77:83:c7:14:13:1f:73:d0: > f3:ee:25:bb:72:cb:6d:bb:da:4b:ca:fc:25:ea:09:0a: > 09:5f:6e:51:3d:e2:5e:63:9c:0f:d5:4f:cb:d8:88:be: > 4c:e6:b2:05:74:ed:2e:25:72:c4:0a:c7:84:47:97:28: > 79:a5:a0:1d:6d:b4:86:55:e7:61:3f:df:db:1c:cc:37: > 24:a7:3e:40:35:12:f9:45:08:d6:3f:ca:74:34:51:ee > Fingerprint (MD5): > 73:b9:df:20:b1:f5:b7:29:55:de:88:88:9f:8b:ab:e7 > Fingerprint (SHA1): > 91:83:4b:fa:2f:c0:dc:3e:cc:e4:35:bf:69:f3:db:6c: > 7f:ca:1b:21 > ipa: DEBUG: approved_usage = SSL Server intended_usage = SSL Server > ipa: DEBUG: cert valid True for > "CN=kwtpocpbis01.solaris.local,O=SOLARIS.LOCAL" > ipa: DEBUG: handshake complete, peer = 172.16.107.244:443 > ipa: DEBUG: received Set-Cookie > 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; > Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 > 10:24:32 GMT; Secure; HttpOnly' > ipa: DEBUG: storing cookie 'ipa_session=cf8484a2b0ee0f8f3fe2cac8c6ad7570; > Domain=kwtpocpbis01.solaris.local; Path=/ipa; Expires=Tue, 17 Mar 2015 > 10:24:32 GMT; Secure; HttpOnly' for principal admin at SOLARIS.LOCAL > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' > 'ipa_session_cookie:admin at SOLARIS.LOCAL' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=35095713 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'search' '@s' 'user' > 'ipa_session_cookie:admin at SOLARIS.LOCAL' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout=35095713 > > ipa: DEBUG: stderr= > ipa: DEBUG: Starting external process > ipa: DEBUG: args='keyctl' 'pupdate' '35095713' > ipa: DEBUG: Process finished, return code=0 > ipa: DEBUG: stdout= > ipa: DEBUG: stderr= > ipa: DEBUG: Destroyed connection context.rpcclient > ipa: ERROR: Insufficient access: CIFS server denied your credentials > > > > and it accepting password for admin and i can able to see tickets: > > [root at kwtpocpbis01 ~]# klist > Ticket cache: KEYRING:persistent:0:0 > Default principal: admin at SOLARIS.LOCAL > > Valid starting Expires Service principal > 03/17/2015 13:04:29 03/18/2015 13:04:26 > krbtgt/SOLARIS.LOCAL at SOLARIS.LOCAL > > > > On Tue, Mar 17, 2015 at 12:57 PM, Ben .T.George > wrote: > >> HI >> >> i have enabled debug >> >> here is my sssd.conf >> >> [root at kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf >> [domain/solaris.local] >> >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = solaris.local >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = kwtpocpbis01.solaris.local >> chpass_provider = ipa >> ipa_server = kwtpocpbis01.solaris.local >> ipa_server_mode = True >> ldap_tls_cacert = /etc/ipa/ca.crt >> [sssd] >> services = nss, sudo, pam, ssh >> config_file_version = 2 >> >> domains = solaris.local >> debug_level = 6 >> [nss] >> homedir_substring = /home >> debug_level = 6 >> >> [pam] >> >> [sudo] >> >> [autofs] >> >> [ssh] >> >> [pac] >> >> [ifp] >> >> >> LOGS: >> >> sssd.log: >> >> (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging >> solaris.local >> (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging >> nss >> (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging >> sudo >> (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging >> pam >> (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging >> ssh >> (Tue Mar 17 12:45:34 2015) [sssd] [service_send_ping] (0x0100): Pinging >> pac >> (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service nss >> replied to ping >> (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service sudo >> replied to ping >> (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service pam >> replied to ping >> (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service ssh >> replied to ping >> (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service >> solaris.local replied to ping >> (Tue Mar 17 12:45:34 2015) [sssd] [ping_check] (0x0100): Service pac >> replied to ping >> >> >> error_log: >> >> [root at kwtpocpbis01 ~]# tail -f /var/log/httpd/error_log >> [Tue Mar 17 11:26:25.458878 2015] [:error] [pid 15175] ipa: INFO: *** >> PROCESS START *** >> [Tue Mar 17 11:26:25.603536 2015] [:error] [pid 15176] ipa: DEBUG: >> session_auth_duration: 0:20:00 >> [Tue Mar 17 11:26:25.609112 2015] [:error] [pid 15176] ipa: DEBUG: >> session_auth_duration: 0:20:00 >> [Tue Mar 17 11:26:25.655477 2015] [:error] [pid 15176] ipa: DEBUG: >> Mounting ipaserver.rpcserver.login_kerberos() at '/session/login_kerberos' >> [Tue Mar 17 11:26:25.655597 2015] [:error] [pid 15176] ipa: DEBUG: >> session_auth_duration: 0:20:00 >> [Tue Mar 17 11:26:25.681652 2015] [:error] [pid 15176] ipa: DEBUG: >> Mounting ipaserver.rpcserver.login_password() at '/session/login_password' >> [Tue Mar 17 11:26:25.681849 2015] [:error] [pid 15176] ipa: DEBUG: >> session_auth_duration: 0:20:00 >> [Tue Mar 17 11:26:25.754351 2015] [:error] [pid 15176] ipa: INFO: *** >> PROCESS START *** >> p11-kit: ipa.p11-kit: x-public-key-info: invalid or unsupported attribute >> [Tue Mar 17 11:26:28.847563 2015] [:warn] [pid 15377] NSSProtocol: >> Unknown protocol 'tlsv1.2' not supported >> >> secure: >> [root at kwtpocpbis01 log]# tail -f secure >> Mar 17 12:35:41 kwtpocpbis01 sshd[15714]: subsystem request for sftp by >> user root >> Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: Accepted password for root from >> 10.18.2.130 port 64141 ssh2 >> Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: pam_unix(sshd:session): session >> opened for user root by (uid=0) >> Mar 17 12:35:44 kwtpocpbis01 sshd[15736]: subsystem request for sftp by >> user root >> Mar 17 12:39:12 kwtpocpbis01 sshd[14507]: pam_unix(sshd:session): session >> closed for user root >> Mar 17 12:40:57 kwtpocpbis01 sshd[15816]: Invalid user bobby at infra.com >> from 10.18.2.130 >> Mar 17 12:40:57 kwtpocpbis01 sshd[15816]: input_userauth_request: invalid >> user bobby at infra.com [preauth] >> Mar 17 12:41:02 kwtpocpbis01 sshd[15816]: pam_unix(sshd:auth): check >> pass; user unknown >> Mar 17 12:41:02 kwtpocpbis01 sshd[15816]: pam_unix(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.18.2.130 >> Mar 17 12:41:04 kwtpocpbis01 sshd[15816]: Failed password for invalid >> user bobby at infra.com from 10.18.2.130 port 64470 ssh2 >> >> Mar 17 12:44:56 kwtpocpbis01 sshd[15840]: pam_unix(sshd:auth): >> authentication failure; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.18.2.130 user=ben at infra.com >> Mar 17 12:44:57 kwtpocpbis01 sshd[15840]: pam_sss(sshd:auth): >> authentication success; logname= uid=0 euid=0 tty=ssh ruser= >> rhost=10.18.2.130 user=ben at infra.com >> Mar 17 12:44:57 kwtpocpbis01 sshd[15840]: Accepted password for >> ben at infra.com from 10.18.2.130 port 64782 ssh2 >> Mar 17 12:44:59 kwtpocpbis01 sshd[15840]: pam_unix(sshd:session): session >> opened for user ben at infra.com by (uid=0) >> >> >> >> On Tue, Mar 17, 2015 at 12:09 PM, Jakub Hrozek >> wrote: >> >>> On Tue, Mar 17, 2015 at 11:37:24AM +0300, Ben .T.George wrote: >>> > HI List >>> > >>> > i was following this link : >>> > http://www.freeipa.org/page/Active_Directory_trust_setup#Assumptions >>> > to setup IPA server >>> > >>> > my IPA version is 4.1.2 >>> > >>> > every setps in this tutorials was passed without any error >>> > >>> > even "*Allow access for users from AD domain to protected resources*" >>> > went successfully >>> > my current issue is only one user called ben can able to login to ipa >>> > server.please check below: >>> > >>> > [root at kwtpocpbis01 ~]# getent passwd ben at infra.com >>> > ben at infra.com:*:531001104:531001104:ben:/home/infra.com/ben: >>> > [root at kwtpocpbis01 ~]# getent passwd bobby at infra.com >>> > [root at kwtpocpbis01 ~]# getent passwd administrator at infra.com >>> > [root at kwtpocpbis01 ~]# >>> > >>> > the users ben & bobby are on same group (Domain users). but bobby >>> cannot >>> > able to login to IPA and not getting any information while querying >>> > please help me to fix this issue. i don't know where i need to >>> troubleshoot >>> > this issue. >>> >>> Can you increase debug_level in both [nss] and [domain] sections on the >>> server and paste the logs here? >>> >>> -- >>> 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 jhrozek at redhat.com Tue Mar 17 10:27:59 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Mar 2015 11:27:59 +0100 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: <20150317090922.GL9563@hendrix.arn.redhat.com> Message-ID: <20150317102759.GN9563@hendrix.arn.redhat.com> On Tue, Mar 17, 2015 at 12:57:27PM +0300, Ben .T.George wrote: > HI > > i have enabled debug > > here is my sssd.conf > > [root at kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf > [domain/solaris.local] > > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = solaris.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = kwtpocpbis01.solaris.local > chpass_provider = ipa > ipa_server = kwtpocpbis01.solaris.local > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt Please also add debug_level to this section, not just [sssd] and [nss] > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > > domains = solaris.local > debug_level = 6 > [nss] > homedir_substring = /home > debug_level = 6 > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] From bentech4you at gmail.com Tue Mar 17 11:23:57 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 14:23:57 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: <20150317102759.GN9563@hendrix.arn.redhat.com> References: <20150317090922.GL9563@hendrix.arn.redhat.com> <20150317102759.GN9563@hendrix.arn.redhat.com> Message-ID: HI i have changed like this: [root at kwtpocpbis01 yum.repos.d]# more /etc/sssd/sssd.conf [domain/solaris.local] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = solaris.local id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = kwtpocpbis01.solaris.local chpass_provider = ipa ipa_server = kwtpocpbis01.solaris.local ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt debug_level = 10 [sssd] services = nss, sudo, pam, ssh config_file_version = 2 debug_level = 5 domains = solaris.local [nss] homedir_substring = /home debug_level = 6 [pam] debug_level = 10 [sudo] debug_level = 5 [autofs] debug_level = 5 [ssh] debug_level = 5 [pac] debug_level = 5 [ifp] but sssd.log looks same. (Tue Mar 17 14:23:13 2015) [sssd] [ping_check] (0x0100): Service pam replied to ping (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging solaris.local (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging nss (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging sudo (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging pam (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging pac (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service sudo replied to ping (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service ssh replied to ping (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service pam replied to ping (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service solaris.local replied to ping (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service pac replied to ping (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service nss replied to ping On Tue, Mar 17, 2015 at 1:27 PM, Jakub Hrozek wrote: > On Tue, Mar 17, 2015 at 12:57:27PM +0300, Ben .T.George wrote: > > HI > > > > i have enabled debug > > > > here is my sssd.conf > > > > [root at kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf > > [domain/solaris.local] > > > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = solaris.local > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = kwtpocpbis01.solaris.local > > chpass_provider = ipa > > ipa_server = kwtpocpbis01.solaris.local > > ipa_server_mode = True > > ldap_tls_cacert = /etc/ipa/ca.crt > > Please also add debug_level to this section, not just [sssd] and [nss] > > > > [sssd] > > services = nss, sudo, pam, ssh > > config_file_version = 2 > > > > domains = solaris.local > > debug_level = 6 > > [nss] > > homedir_substring = /home > > debug_level = 6 > > > > [pam] > > > > [sudo] > > > > [autofs] > > > > [ssh] > > > > [pac] > > > > [ifp] > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Tue Mar 17 11:33:03 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Mar 2015 12:33:03 +0100 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <5507289E.2000703@opennms.org> References: <5507289E.2000703@opennms.org> Message-ID: <550810EF.2030705@redhat.com> On 03/16/2015 08:01 PM, Benjamin Reed wrote: > So given my RHEL6 machine started on an older FreeIPA 3.0, was a > self-signed cert, and has gone through all kinds of hell and I'm having > an impossible time setting up new master(s), I've decided to start over. > > I installed the EPEL7 FreeIPA 4.1.3 RPMs, in the hopes that being on the > latest would give me the best chance at migrating. > > I did the following: > > --- 8< --- > ipa-server-install > ipa config-mod --enable-migration=true > ipa-compat-manage disable > service ipa restart # ipa-compat-manage wants a restart > ipa migrate-ds \ > --bind-dn=uid=admin,cn=users,cn=accounts,dc=XXX,dc=XXX \ Note that this Bind DN will not migrate passwords at all, as admin does not have the privilege to *read* userPassword attribute by design. You need to migrate using Directory Manager. > --user-container=cn=users,cn=accounts \ > --group-container=cn=groups,cn=accounts \ > --group-overwrite-gid \ > ldap://XXX:389 > ipa-compat-manage enable > ipa-config-mod --enable-mogration=false As Dmitri mentioned, this should not be done before password migration is over. > service ipa restart > --- 8< --- > > It all seems to have (kinda) worked, I can log in to the UI as admin and > see all of my users and groups. There are a couple of snags. > > 1. When the migration completed, it said: > >> Passwords have been migrated in pre-hashed format. >> IPA is unable to generate Kerberos keys unless provided >> with clear text passwords. All migrated users need to >> login at https://your.domain/ipa/migration/ before they >> can use their Kerberos accounts. > > If I try to actually do this as a regular user, the web UI just says: > >> The password or username you entered is incorrect. Please try again >> (make sure your caps lock is off). >> If the problem persists, contact your administrator. > > I'm not sure where to look in the logs to figure out what's going on, > but nothing in the kerberos logs jump out at me. The dirsrv log has these: > >> [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should >> be added before the CoS Definition. >> [16/Mar/2015:14:43:21 -0400] - Skipping CoS Definition cn=Password >> Policy,cn=accounts,dc=XXX,dc=XXX--no CoS Templates found, which should >> be added before the CoS Definition. > > ...which seems fishy. The problem here is that migrate-ds is designed to migrate users from general LDAP, usually without Kerberos integration. However, you are migrating from FreeIPA LDAP with full Kerberos support and the already generated Kerberos keys. You thus need to do a small tweaking of migrate-ds options to filter already-generated kerberos keys from the old FreeIPA instance and to also let it migrate private user groups. This is what I did to migrate users from my RHEL-6 test VM to FreeIPA 4.1.3: # ipa config-mod --enable-migration=true # echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager" --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts --group-objectclass=posixgroup --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference} --with-compat ldap://vm-086.rhel-6.test ----------- migrate-ds: ----------- Migrated: user: fbar, non-upg group: fbar Failed user: admin: This entry already exists Failed group: admins: This entry already exists. Check GID of the existing group. Use --group-overwrite-gid option to overwrite the GID editors: This entry already exists. Check GID of the existing group. Use --group-overwrite-gid option to overwrite the GID ipausers: This entry already exists. Check GID of the existing group. Use --group-overwrite-gid option to overwrite the GID ---------- Passwords have been migrated in pre-hashed format. IPA is unable to generate Kerberos keys unless provided with clear text passwords. All migrated users need to login at https://your.domain/ipa/migration/ before they can use their Kerberos accounts. This migrated both fbar and non-pug users, with fbar's UPG and with userPassword: # ipa user-show fbar --all --raw dn: uid=fbar,cn=users,cn=accounts,dc=f21 uid: fbar givenname: Foo sn: Bar cn: Foo Bar initials: FB homedirectory: /home/fbar gecos: Foo Bar loginshell: /bin/sh mail: fbar at idm.lab.bos.redhat.com uidnumber: 1873800001 gidnumber: 1873800001 nsaccountlock: FALSE has_password: TRUE has_keytab: FALSE displayName: Foo Bar ipaUniqueID: fa9a125e-cc92-11e4-9bbd-001a4a104e33 krbPrincipalName: fbar at F21 memberofindirect: cn=ipausers,cn=groups,cn=accounts,dc=f21 mepManagedEntry: cn=fbar,cn=groups,cn=accounts,dc=f21 objectClass: ipasshgroupofpubkeys objectClass: ipaobject objectClass: meporiginentry objectClass: organizationalperson objectClass: top objectClass: ipasshuser objectClass: inetorgperson objectClass: person objectClass: krbticketpolicyaux objectClass: krbprincipalaux objectClass: inetuser objectClass: posixaccount I am now able to log in as fbar to the host and thus get the new Kerberos keys generated/migrated: # ssh fbar@`hostname` fbar at ipa.f21's password: Could not chdir to home directory /home/fbar: No such file or directory -sh-4.3$ logout Connection to ipa.f21 closed. # ipa user-show fbar --all --raw dn: uid=fbar,cn=users,cn=accounts,dc=f21 ... krbExtraData: AAJPDQhVZmJhckBGMjEA krbLastPwdChange: 20150317111735Z krbLastSuccessfulAuth: 20150317111735Z krbPasswordExpiration: 20150615111735Z krbPrincipalName: fbar at F21 ... > 2. If I manually reset my user's password in the UI and then try to log > in as that user, it does work, but I'd like to avoid having to > hand-reset every single user's account for obvious reasons. When I *do* > log in as my reset user, I always get this on the shell: > >> id: cannot find name for group ID 18600003 > > That gid is the `ipausers` GID from the old server. It appears that > modern FreeIPA doesn't assign a GID to `ipausers` which is fine, but I > can't figure out how to *remove* the old GID from existing users and > have everything be correct. I've tried adding a group and forcing its > GID to match the missing GID and deleting it again, but now it just > seems to have cached it... when I do an `id` on my user, it still shows > my user's GID as being 18600003(temp) even though the "temp" group has > been removed. As for the users without UPG, I think the best bet is to change your ipausers to POSIX (user-mod --posix) and then change it's GID to the original one. Of course, as Dmitri suggests, clearing SSSD cache should help too. > Any ideas how to do this migration properly? Please let me know if my advise helps. If yes, I think we should add it to either migrate-ds command online help and/or migration instructions on FreeIPA wiki. BTW, please also note that I found a bug in FreeIPA 4.1.3 migrate-ds command which hides the real reason why users/groups were not migrated. See https://fedorahosted.org/freeipa/ticket/4952 Native IPA 4.1.* package in RHEL/CentOS 7.1 do not have this bug. From bentech4you at gmail.com Tue Mar 17 11:34:44 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 14:34:44 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: <20150317090922.GL9563@hendrix.arn.redhat.com> <20150317102759.GN9563@hendrix.arn.redhat.com> Message-ID: Oops sorry here is the logs ==> sssd_pam.log <== (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7fdea7263bd0 (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] ==> sssd.log <== (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service solaris.local replied to ping (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service pac replied to ping (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service sudo replied to ping (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service ssh replied to ping (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service pam replied to ping (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service nss replied to ping ==> sssd_nss.log <== (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [bobby at infra.com]. (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'bobby at infra.com' matched expression for domain 'infra.com', user is bobby (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [bobby] from [infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [bobby at infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f426adbfb50:1:bobby at infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [infra.com][4097][1][name=bobby] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f426adbfb50:1:bobby at infra.com] ==> sssd_solaris.local.log <== (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d2a5140 (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=bobby] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_req_set_domain] (0x0400): Changing request domain from [solaris.local] to [infra.com] ==> sssd_nss.log <== (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Fast reply - offline Will try to return what we have in cache (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f426adbfb50:1:bobby at infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [bobby at infra.com]. (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'bobby at infra.com' matched expression for domain 'infra.com', user is bobby (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [bobby] from [infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [bobby at infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f426adbfb50:1:bobby at infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [infra.com][4097][1][name=bobby] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f426adbfb50:1:bobby at infra.com] ==> sssd_solaris.local.log <== (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d2a5140 (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=bobby] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_req_set_domain] (0x0400): Changing request domain from [solaris.local] to [infra.com] ==> sssd_nss.log <== (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Fast reply - offline Will try to return what we have in cache (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f426adbfb50:1:bobby at infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [bobby at infra.com]. (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'bobby at infra.com' matched expression for domain 'infra.com', user is bobby (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [bobby] from [infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [bobby at infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f426adbfb50:1:bobby at infra.com] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [infra.com][4097][1][name=bobby] (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f426adbfb50:1:bobby at infra.com] ==> sssd_solaris.local.log <== (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d2a5140 (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=bobby] (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_req_set_domain] (0x0400): Changing request domain from [solaris.local] to [infra.com] ==> sssd_nss.log <== (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 1, 11, Fast reply - offline Will try to return what we have in cache (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f426adbfb50:1:bobby at infra.com] ==> sssd.log <== (Tue Mar 17 14:33:30 2015) [sssd] [message_type] (0x0200): netlink Message type: 25 ==> sssd_solaris.local.log <== (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [resetOffline] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [resetOffline] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_run_unconditional_online_cb] (0x0400): Running unconditional online callbacks. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [check_if_online] (0x2000): Trying to go back online! (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'gc_infra.com' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'infra.com' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name not resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_port_status] (0x1000): Port status of port 0 for server 'kwtpocpbis01.solaris.local' is 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [resolv_is_address] (0x4000): [kwtpocpbis01.solaris.local] does not look like an IP address (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'kwtpocpbis01.solaris.local' in files (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'resolving name' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://kwtpocpbis01.solaris.local' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x4000): Using file descriptor [22] for LDAP connection. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://kwtpocpbis01.solaris.local:389/??base] with fd [22]. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_print_server] (0x2000): Searching 172.16.107.244 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c6140], connected[1], ops[0x7f6b7d2bf090], ldap[0x7f6b7d265a00] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_entry] (0x1000): OriginalDN: []. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [changeLog] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [firstchangenumber] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastchangenumber] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultNamingContext] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastUSN] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c6140], connected[1], ops[0x7f6b7d2bf090], ldap[0x7f6b7d265a00] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 84351 (int: 84351) (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/kwtpocpbis01.solaris.local, SOLARIS.LOCAL, 86400) (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 68 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [16425] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [16425] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c6140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [write_pipe_handler] (0x0400): All data has been sent! ==> ldap_child.log <== (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x0400): ldap_child started. (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x2000): context initialized (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] (0x1000): total buffer size: 68 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] (0x1000): realm_str size: 13 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] (0x1000): got realm_str: SOLARIS.LOCAL (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] (0x1000): princ_str size: 31 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] (0x1000): got princ_str: host/kwtpocpbis01.solaris.local (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] (0x1000): keytab_name size: 0 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] (0x1000): lifetime: 86400 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] (0x0200): Will run as [0][0]. (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [privileged_krb5_setup] (0x2000): Kerberos context initialized (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x2000): Kerberos context initialized (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [become_user] (0x0200): Trying to become user [0][0]. (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [become_user] (0x0200): Already user [0]. (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x2000): Running as [0][0]. (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x2000): getting TGT sync (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [ldap_child_get_tgt_sync] (0x2000): got realm_name: [SOLARIS.LOCAL] (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [ldap_child_get_tgt_sync] (0x0100): Principal name is: [host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL] (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.524474: Getting initial credentials for host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.526526: Looked up etypes in keytab: rc4-hmac, des3-cbc-sha1, aes128-cts, aes256-cts (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.526597: Sending request (196 bytes) to SOLARIS.LOCAL (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.526803: Initiating TCP connection to stream 172.16.107.244:88 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.526892: Sending TCP request to stream 172.16.107.244:88 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528813: Received answer (371 bytes) from stream 172.16.107.244:88 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528846: Terminating TCP connection to stream 172.16.107.244:88 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528895: Response was from master KDC (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528937: Received error from KDC: -1765328359/Additional pre-authentication required (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528977: Processing preauth types: 136, 19, 2, 133 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529008: Selected etype info: etype aes256-cts, salt "jUdxx&tm\3}.mh_[", params "" (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529023: Received cookie: MIT (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529056: Retrieving host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL from MEMORY:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: 0/Success (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529088: AS key obtained for encrypted timestamp: aes256-cts/445E (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529148: Encrypted timestamp (for 1426592010.528836): plain 301AA011180F32303135303331373131333333305AA10502030811C4, encrypted 98625FC80F84BE6C287E596D254D3862CE1A8938418E92A91224BB349985496C8AD8D7161D736951B4C3907B8F4CB964577C28F6C3B81708 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529173: Preauth module encrypted_timestamp (2) (real) returned: 0/Success (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529195: Produced preauth for next request: 133, 2 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529216: Sending request (291 bytes) to SOLARIS.LOCAL (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529248: Initiating TCP connection to stream 172.16.107.244:88 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529293: Sending TCP request to stream 172.16.107.244:88 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.535622: Received answer (201 bytes) from stream 172.16.107.244:88 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.535657: Terminating TCP connection to stream 172.16.107.244:88 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.535705: Response was from master KDC (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.535733: Received error from KDC: -1765328353/Decrypt integrity check failed (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt integrity check failed (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x0020): ldap_child_get_tgt_sync failed. (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [prepare_response] (0x0400): Building response for result [-1765328353] (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [pack_buffer] (0x2000): response size: 50 (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [pack_buffer] (0x1000): result [14] krberr [-1765328353] msgsize [30] msg [Decrypt integrity check failed] (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x0400): ldap_child completed successfully ==> sssd_solaris.local.log <== (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x1000): Waiting for child [16425]. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x0100): child [16425] finished successfully. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on [0] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f6b7d2c6140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [check_online_callback] (0x0100): Backend returned: (3, 0, ) [Internal Error (Success)] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'gc_infra.com' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'infra.com' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name not resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_ptask_disable] (0x0400): Task [Check if online (periodic)]: disabling task (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [ipa_subdom_reset_timeouts_cb] (0x4000): Resetting last_refreshed and disabled_until. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1426592010 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [resolv_is_address] (0x4000): [kwtpocpbis01.solaris.local] does not look like an IP address (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'kwtpocpbis01.solaris.local' in files (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'resolving name' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name resolved' (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x4000): Using file descriptor [22] for LDAP connection. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://kwtpocpbis01.solaris.local:389/??base] with fd [22]. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_print_server] (0x2000): Searching 172.16.107.244 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [ad_online_cb] (0x0400): The AD provider is online (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. On Tue, Mar 17, 2015 at 2:23 PM, Ben .T.George wrote: > HI > > i have changed like this: > > [root at kwtpocpbis01 yum.repos.d]# more /etc/sssd/sssd.conf > [domain/solaris.local] > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = solaris.local > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = kwtpocpbis01.solaris.local > chpass_provider = ipa > ipa_server = kwtpocpbis01.solaris.local > ipa_server_mode = True > ldap_tls_cacert = /etc/ipa/ca.crt > debug_level = 10 > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > debug_level = 5 > domains = solaris.local > [nss] > homedir_substring = /home > debug_level = 6 > > [pam] > debug_level = 10 > [sudo] > debug_level = 5 > [autofs] > debug_level = 5 > [ssh] > debug_level = 5 > [pac] > debug_level = 5 > [ifp] > > > but sssd.log looks same. > > (Tue Mar 17 14:23:13 2015) [sssd] [ping_check] (0x0100): Service pam > replied to ping > (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging > solaris.local > (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging nss > (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging > sudo > (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging pam > (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh > (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging pac > (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service sudo > replied to ping > (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service ssh > replied to ping > (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service pam > replied to ping > (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service > solaris.local replied to ping > (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service pac > replied to ping > (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service nss > replied to ping > > On Tue, Mar 17, 2015 at 1:27 PM, Jakub Hrozek wrote: > >> On Tue, Mar 17, 2015 at 12:57:27PM +0300, Ben .T.George wrote: >> > HI >> > >> > i have enabled debug >> > >> > here is my sssd.conf >> > >> > [root at kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf >> > [domain/solaris.local] >> > >> > cache_credentials = True >> > krb5_store_password_if_offline = True >> > ipa_domain = solaris.local >> > id_provider = ipa >> > auth_provider = ipa >> > access_provider = ipa >> > ipa_hostname = kwtpocpbis01.solaris.local >> > chpass_provider = ipa >> > ipa_server = kwtpocpbis01.solaris.local >> > ipa_server_mode = True >> > ldap_tls_cacert = /etc/ipa/ca.crt >> >> Please also add debug_level to this section, not just [sssd] and [nss] >> >> >> > [sssd] >> > services = nss, sudo, pam, ssh >> > config_file_version = 2 >> > >> > domains = solaris.local >> > debug_level = 6 >> > [nss] >> > homedir_substring = /home >> > debug_level = 6 >> > >> > [pam] >> > >> > [sudo] >> > >> > [autofs] >> > >> > [ssh] >> > >> > [pac] >> > >> > [ifp] >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Tue Mar 17 11:38:41 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 14:38:41 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: <20150317090922.GL9563@hendrix.arn.redhat.com> <20150317102759.GN9563@hendrix.arn.redhat.com> Message-ID: here is separated logs: tail -f sssd_solaris.local.log (Tue Mar 17 14:35:23 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:35:23 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:35:23 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:35:23 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:35:23 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:35:33 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:35:33 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:35:33 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:35:33 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:35:33 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:35:43 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:35:43 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:35:43 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:35:43 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:35:43 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [resetOffline] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [resetOffline] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_run_unconditional_online_cb] (0x0400): Running unconditional online callbacks. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [check_if_online] (0x2000): Trying to go back online! (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'gc_infra.com' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'infra.com' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name not resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [get_port_status] (0x1000): Port status of port 0 for server 'kwtpocpbis01.solaris.local' is 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [resolv_is_address] (0x4000): [kwtpocpbis01.solaris.local] does not look like an IP address (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'kwtpocpbis01.solaris.local' in files (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'resolving name' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://kwtpocpbis01.solaris.local' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x4000): Using file descriptor [22] for LDAP connection. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://kwtpocpbis01.solaris.local:389/??base] with fd [22]. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_print_server] (0x2000): Searching 172.16.107.244 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[0x7f6b7d2bae30], ldap[0x7f6b7d265a00] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_entry] (0x1000): OriginalDN: []. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [changeLog] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [firstchangenumber] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastchangenumber] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultNamingContext] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastUSN] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[0x7f6b7d2bae30], ldap[0x7f6b7d265a00] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 84359 (int: 84359) (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/kwtpocpbis01.solaris.local, SOLARIS.LOCAL, 86400) (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 68 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [16437] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [16437] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x1000): Waiting for child [16437]. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x0100): child [16437] finished successfully. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on [0] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [check_online_callback] (0x0100): Backend returned: (3, 0, ) [Internal Error (Success)] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'gc_infra.com' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'infra.com' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name not resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_ptask_disable] (0x0400): Task [Check if online (periodic)]: disabling task (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [ipa_subdom_reset_timeouts_cb] (0x4000): Resetting last_refreshed and disabled_until. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1426592145 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [resolv_is_address] (0x4000): [kwtpocpbis01.solaris.local] does not look like an IP address (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'kwtpocpbis01.solaris.local' in files (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'resolving name' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name resolved' (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x4000): Using file descriptor [22] for LDAP connection. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://kwtpocpbis01.solaris.local:389/??base] with fd [22]. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_print_server] (0x2000): Searching 172.16.107.244 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [ad_online_cb] (0x0400): The AD provider is online (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[0x7f6b7d2bf090], ldap[0x7f6b7d265a00] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_entry] (0x1000): OriginalDN: []. (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [changeLog] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [firstchangenumber] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastchangenumber] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultNamingContext] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastUSN] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[0x7f6b7d2bf090], ldap[0x7f6b7d265a00] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 84361 (int: 84361) (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/kwtpocpbis01.solaris.local, SOLARIS.LOCAL, 86400) (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 68 (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [16438] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [16438] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x1000): Waiting for child [16438]. (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x0100): child [16438] finished successfully. (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on [0] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x4000): attempting failover retry on op #1 (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [get_port_status] (0x1000): Port status of port 0 for server 'kwtpocpbis01.solaris.local' is 'not working' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x4000): attempting failover retry on op #2 (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [be_resolve_server_done] (0x1000): Server resolution failed: 5 (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [be_mark_offline] (0x2000): Going offline! (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [be_mark_offline] (0x2000): Enable check_if_online_ptask. (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [be_ptask_enable] (0x0400): Task [Check if online (periodic)]: enabling task (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 88 seconds from now [1426592234] (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily unavailable) (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_sudo_periodical_first_refresh_done] (0x0400): Data provider is offline. Scheduling another full refresh in 16 minutes. (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1426593106 (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #2 (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [ipa_subdomains_get_conn_done] (0x0080): No IPA server is available, cannot get the subdomain list while offline (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Mar 17 14:35:46 2015) [sssd[be[solaris.local]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.SOLARIS.LOCAL], [2][No such file or directory] (Tue Mar 17 14:35:53 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:35:53 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:35:53 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:35:53 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:35:53 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:03 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:36:03 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:03 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:03 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:03 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:13 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:36:13 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:13 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:13 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:13 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [resetOffline] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [resetOffline] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_run_unconditional_online_cb] (0x0400): Running unconditional online callbacks. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [check_if_online] (0x2000): Trying to go back online! (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'gc_infra.com' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'infra.com' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name not resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [get_port_status] (0x1000): Port status of port 0 for server 'kwtpocpbis01.solaris.local' is 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [resolv_is_address] (0x4000): [kwtpocpbis01.solaris.local] does not look like an IP address (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'kwtpocpbis01.solaris.local' in files (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'resolving name' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [ipa_resolve_callback] (0x0400): Constructed uri 'ldap://kwtpocpbis01.solaris.local' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x4000): Using file descriptor [22] for LDAP connection. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://kwtpocpbis01.solaris.local:389/??base] with fd [22]. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_print_server] (0x2000): Searching 172.16.107.244 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[0x7f6b7d2bae30], ldap[0x7f6b7d265a00] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_entry] (0x1000): OriginalDN: []. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [changeLog] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [firstchangenumber] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastchangenumber] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultNamingContext] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastUSN] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[0x7f6b7d2bae30], ldap[0x7f6b7d265a00] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 84363 (int: 84363) (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/kwtpocpbis01.solaris.local, SOLARIS.LOCAL, 86400) (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 68 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [16441] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [16441] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x1000): Waiting for child [16441]. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x0100): child [16441] finished successfully. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on [0] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [check_online_callback] (0x0100): Backend returned: (3, 0, ) [Internal Error (Success)] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'gc_infra.com' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_srv_data_status] (0x0100): Marking SRV lookup of service 'infra.com' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server '(no name)' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name not resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'neutral' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_ptask_disable] (0x0400): Task [Check if online (periodic)]: disabling task (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_run_online_cb] (0x0080): Going online. Running callbacks. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [ipa_subdom_reset_timeouts_cb] (0x4000): Resetting last_refreshed and disabled_until. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1426592175 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [resolv_is_address] (0x4000): [kwtpocpbis01.solaris.local] does not look like an IP address (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_step] (0x2000): Querying files (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of 'kwtpocpbis01.solaris.local' in files (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'resolving name' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [set_server_common_status] (0x0100): Marking server 'kwtpocpbis01.solaris.local' as 'name resolved' (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x4000): Using file descriptor [22] for LDAP connection. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] (0x0400): Setting 6 seconds timeout for connecting (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to [ldap://kwtpocpbis01.solaris.local:389/??base] with fd [22]. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_send] (0x4000): Getting rootdse (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_print_server] (0x2000): Searching 172.16.107.244 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(objectclass=*)][]. (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedLDAPVersion] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedSASLMechanisms] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [domainControllerFunctionality] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [defaultNamingContext] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [highestCommittedUSN] (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [ad_online_cb] (0x0400): The AD provider is online (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Mar 17 14:36:15 2015) [sssd[be[solaris.local]]] [delayed_online_authentication_callback] (0x0200): Backend is online, starting delayed online authentication. (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[0x7f6b7d2bae30], ldap[0x7f6b7d265a00] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_entry] (0x1000): OriginalDN: []. (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorName] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [vendorVersion] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [dataversion] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [netscapemdsuffix] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [changeLog] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [firstchangenumber] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastchangenumber] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [namingContexts] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedControl] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedExtension] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedLDAPVersion] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [supportedSASLMechanisms] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [defaultNamingContext] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_parse_range] (0x2000): No sub-attributes for [lastUSN] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[0x7f6b7d2bae30], ldap[0x7f6b7d265a00] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Got rootdse (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 84365 (int: 84365) (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/kwtpocpbis01.solaris.local, SOLARIS.LOCAL, 86400) (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service IPA (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [be_resolve_server_process] (0x0200): Found address for server kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 68 (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [16442] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [child_handler_setup] (0x2000): Signal handler set up for pid [16442] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [write_pipe_handler] (0x0400): All data has been sent! (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x1000): Waiting for child [16442]. (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [child_sig_handler] (0x0100): child [16442] finished successfully. (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [read_pipe_handler] (0x0400): EOF received, client finished (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on [0] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] (0x0100): Could not get TGT: 14 [Bad address] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_cli_kinit_done] (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [fo_set_port_status] (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' as 'not working' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_handle_release] (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [remove_connection_callback] (0x4000): Successfully removed connection callback. (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x4000): attempting failover retry on op #1 (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): beginning to connect (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [get_server_status] (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [get_port_status] (0x1000): Port status of port 0 for server 'kwtpocpbis01.solaris.local' is 'not working' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [fo_resolve_service_send] (0x0020): No available servers for service 'IPA' (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x4000): attempting failover retry on op #2 (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_step] (0x4000): waiting for connection to complete (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [be_resolve_server_done] (0x1000): Server resolution failed: 5 (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x0020): Failed to connect, going offline (5 [Input/output error]) (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [be_mark_offline] (0x2000): Going offline! (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [be_mark_offline] (0x2000): Enable check_if_online_ptask. (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [be_ptask_enable] (0x0400): Task [Check if online (periodic)]: enabling task (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [be_ptask_schedule] (0x0400): Task [Check if online (periodic)]: scheduling task 78 seconds from now [1426592254] (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [be_run_offline_cb] (0x0080): Going offline. Running callbacks. (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #1 (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_sudo_periodical_first_refresh_done] (0x0040): Periodical full refresh of sudo rules failed [dp_error: 1] ([11]: Resource temporarily unavailable) (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_sudo_periodical_first_refresh_done] (0x0400): Data provider is offline. Scheduling another full refresh in 16 minutes. (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1426593136 (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_op_connect_done] (0x4000): notify offline to op #2 (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [ipa_subdomains_get_conn_done] (0x0080): No IPA server is available, cannot get the subdomain list while offline (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [sdap_id_release_conn_data] (0x4000): releasing unused connection (Tue Mar 17 14:36:16 2015) [sssd[be[solaris.local]]] [remove_krb5_info_files] (0x0200): Could not remove [/var/lib/sss/pubconf/kpasswdinfo.SOLARIS.LOCAL], [2][No such file or directory] (Tue Mar 17 14:36:18 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d2a5140 (Tue Mar 17 14:36:18 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:18 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:36:18 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:18 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:36:18 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=bobby] (Tue Mar 17 14:36:18 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Mar 17 14:36:18 2015) [sssd[be[solaris.local]]] [be_req_set_domain] (0x0400): Changing request domain from [solaris.local] to [infra.com] (Tue Mar 17 14:36:23 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:36:23 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:23 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:23 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:23 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:33 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:36:33 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:33 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:33 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:33 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d2a5140 (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=bobby] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_req_set_domain] (0x0400): Changing request domain from [solaris.local] to [infra.com] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d2a5140 (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=bobby] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_req_set_domain] (0x0400): Changing request domain from [solaris.local] to [infra.com] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d2a5140 (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0200): Got request for [0x1001][1][name=bobby] (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_get_account_info] (0x0100): Request processed. Returned 1,11,Fast reply - offline (Tue Mar 17 14:36:35 2015) [sssd[be[solaris.local]]] [be_req_set_domain] (0x0400): Changing request domain from [solaris.local] to [infra.com] (Tue Mar 17 14:36:43 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:36:43 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:43 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:43 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:43 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:53 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:36:53 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:36:53 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:36:53 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:36:53 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:37:03 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): dbus conn: 0x7f6b7d266a70 (Tue Mar 17 14:37:03 2015) [sssd[be[solaris.local]]] [sbus_dispatch] (0x4000): Dispatching. (Tue Mar 17 14:37:03 2015) [sssd[be[solaris.local]]] [sbus_message_handler] (0x4000): Received SBUS method [ping] (Tue Mar 17 14:37:03 2015) [sssd[be[solaris.local]]] [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit (Tue Mar 17 14:37:03 2015) [sssd[be[solaris.local]]] [sbus_handler_got_caller_id] (0x4000): Received SBUS method [ping] On Tue, Mar 17, 2015 at 2:34 PM, Ben .T.George wrote: > Oops sorry > here is the logs > > ==> sssd_pam.log <== > (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus > conn: 0x7fdea7263bd0 > (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_dispatch] (0x4000): > Dispatching. > (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_message_handler] (0x4000): > Received SBUS method [ping] > (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_get_sender_id_send] (0x2000): > Not a sysbus message, quit > (Tue Mar 17 14:33:23 2015) [sssd[pam]] [sbus_handler_got_caller_id] > (0x4000): Received SBUS method [ping] > > ==> sssd.log <== > (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service > solaris.local replied to ping > (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service pac > replied to ping > (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service sudo > replied to ping > (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service ssh > replied to ping > (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service pam > replied to ping > (Tue Mar 17 14:33:23 2015) [sssd] [ping_check] (0x0100): Service nss > replied to ping > > ==> sssd_nss.log <== > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): > Running command [17] with input [bobby at infra.com]. > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_parse_name_for_domains] > (0x0200): name 'bobby at infra.com' matched expression for domain 'infra.com', > user is bobby > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [bobby] from [infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [bobby at infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): > Issuing request for [0x7f426adbfb50:1:bobby at infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): > Creating request for [infra.com][4097][1][name=bobby] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_internal_get_send] > (0x0400): Entering request [0x7f426adbfb50:1:bobby at infra.com] > > ==> sssd_solaris.local.log <== > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] > (0x4000): dbus conn: 0x7f6b7d2a5140 > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] > (0x4000): Dispatching. > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] > (0x0200): Got request for [0x1001][1][name=bobby] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] > (0x0100): Request processed. Returned 1,11,Fast reply - offline > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_req_set_domain] > (0x0400): Changing request domain from [solaris.local] to [infra.com] > > ==> sssd_nss.log <== > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] > (0x0040): Unable to get information from Data Provider > Error: 1, 11, Fast reply - offline > Will try to return what we have in cache > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): > Deleting request: [0x7f426adbfb50:1:bobby at infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): > Running command [17] with input [bobby at infra.com]. > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_parse_name_for_domains] > (0x0200): name 'bobby at infra.com' matched expression for domain 'infra.com', > user is bobby > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [bobby] from [infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [bobby at infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): > Issuing request for [0x7f426adbfb50:1:bobby at infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): > Creating request for [infra.com][4097][1][name=bobby] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_internal_get_send] > (0x0400): Entering request [0x7f426adbfb50:1:bobby at infra.com] > > ==> sssd_solaris.local.log <== > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] > (0x4000): dbus conn: 0x7f6b7d2a5140 > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] > (0x4000): Dispatching. > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] > (0x0200): Got request for [0x1001][1][name=bobby] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] > (0x0100): Request processed. Returned 1,11,Fast reply - offline > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_req_set_domain] > (0x0400): Changing request domain from [solaris.local] to [infra.com] > > ==> sssd_nss.log <== > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] > (0x0040): Unable to get information from Data Provider > Error: 1, 11, Fast reply - offline > Will try to return what we have in cache > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): > Deleting request: [0x7f426adbfb50:1:bobby at infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): > Running command [17] with input [bobby at infra.com]. > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_parse_name_for_domains] > (0x0200): name 'bobby at infra.com' matched expression for domain 'infra.com', > user is bobby > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [bobby] from [infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [bobby at infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): > Issuing request for [0x7f426adbfb50:1:bobby at infra.com] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): > Creating request for [infra.com][4097][1][name=bobby] > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_internal_get_send] > (0x0400): Entering request [0x7f426adbfb50:1:bobby at infra.com] > > ==> sssd_solaris.local.log <== > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] > (0x4000): dbus conn: 0x7f6b7d2a5140 > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [sbus_dispatch] > (0x4000): Dispatching. > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_message_handler] (0x4000): Received SBUS method [getAccountInfo] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] > [sbus_handler_got_caller_id] (0x4000): Received SBUS method [getAccountInfo] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] > (0x0200): Got request for [0x1001][1][name=bobby] > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_get_account_info] > (0x0100): Request processed. Returned 1,11,Fast reply - offline > (Tue Mar 17 14:33:27 2015) [sssd[be[solaris.local]]] [be_req_set_domain] > (0x0400): Changing request domain from [solaris.local] to [infra.com] > > ==> sssd_nss.log <== > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] > (0x0040): Unable to get information from Data Provider > Error: 1, 11, Fast reply - offline > Will try to return what we have in cache > (Tue Mar 17 14:33:27 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): > Deleting request: [0x7f426adbfb50:1:bobby at infra.com] > > ==> sssd.log <== > (Tue Mar 17 14:33:30 2015) [sssd] [message_type] (0x0200): netlink Message > type: 25 > > ==> sssd_solaris.local.log <== > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sbus_dispatch] > (0x4000): dbus conn: 0x7f6b7d266a70 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sbus_dispatch] > (0x4000): Dispatching. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sbus_message_handler] (0x4000): Received SBUS method [resetOffline] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sbus_get_sender_id_send] (0x2000): Not a sysbus message, quit > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sbus_handler_got_caller_id] (0x4000): Received SBUS method [resetOffline] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [be_run_unconditional_online_cb] (0x0400): Running unconditional online > callbacks. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [check_if_online] > (0x2000): Trying to go back online! > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_srv_data_status] > (0x0100): Marking SRV lookup of service 'gc_infra.com' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0100): Marking port 0 of server '(no name)' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_srv_data_status] > (0x0100): Marking SRV lookup of service 'infra.com' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0100): Marking port 0 of server '(no name)' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [set_server_common_status] (0x0100): Marking server > 'kwtpocpbis01.solaris.local' as 'name not resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' > as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] > (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not > resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_port_status] > (0x1000): Port status of port 0 for server 'kwtpocpbis01.solaris.local' is > 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 > seconds > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] > (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not > resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [resolv_is_address] > (0x4000): [kwtpocpbis01.solaris.local] does not look like an IP address > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [resolv_gethostbyname_step] (0x2000): Querying files > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of > 'kwtpocpbis01.solaris.local' in files > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [set_server_common_status] (0x0100): Marking server > 'kwtpocpbis01.solaris.local' as 'resolving name' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [set_server_common_status] (0x0100): Marking server > 'kwtpocpbis01.solaris.local' as 'name resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [be_resolve_server_process] (0x0200): Found address for server > kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [ipa_resolve_callback] (0x0400): Constructed uri > 'ldap://kwtpocpbis01.solaris.local' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] > (0x4000): Using file descriptor [22] for LDAP connection. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] > (0x0400): Setting 6 seconds timeout for connecting > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to > [ldap://kwtpocpbis01.solaris.local:389/??base] with fd [22]. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_rootdse_send] (0x4000): Getting rootdse > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_print_server] > (0x2000): Searching 172.16.107.244 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(objectclass=*)][]. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedLDAPVersion] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedSASLMechanisms] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [domainControllerFunctionality] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [defaultNamingContext] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [highestCommittedUSN] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_result] > (0x2000): Trace: sh[0x7f6b7d2c6140], connected[1], ops[0x7f6b7d2bf090], > ldap[0x7f6b7d265a00] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_entry] > (0x1000): OriginalDN: []. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [objectClass] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [vendorName] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [vendorVersion] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [dataversion] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [netscapemdsuffix] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [changeLog] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [firstchangenumber] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [lastchangenumber] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [namingContexts] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [supportedControl] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [supportedExtension] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [supportedLDAPVersion] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [supportedSASLMechanisms] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [defaultNamingContext] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_parse_range] > (0x2000): No sub-attributes for [lastUSN] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_result] > (0x2000): Trace: sh[0x7f6b7d2c6140], connected[1], ops[0x7f6b7d2bf090], > ldap[0x7f6b7d265a00] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no > errmsg set > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_rootdse_done] (0x2000): Got rootdse > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_rootdse_done] (0x2000): Skipping auto-detection of match rule > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_server_opts_from_rootdse] (0x4000): USN value: 84351 (int: 84351) > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_kinit_send] > (0x0400): Attempting kinit (default, host/kwtpocpbis01.solaris.local, > SOLARIS.LOCAL, 86400) > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_kinit_next_kdc] > (0x1000): Resolving next KDC for service IPA > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] > (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 > seconds > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] > (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [be_resolve_server_process] (0x0200): Found address for server > kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [create_tgt_req_send_buffer] (0x0400): buffer size: 68 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [child_handler_setup] > (0x2000): Setting up signal handler up for pid [16425] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [child_handler_setup] > (0x2000): Signal handler set up for pid [16425] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_result] > (0x2000): Trace: sh[0x7f6b7d2c6140], connected[1], ops[(nil)], > ldap[0x7f6b7d265a00] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_process_result] > (0x2000): Trace: ldap_result found nothing! > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [write_pipe_handler] > (0x0400): All data has been sent! > > ==> ldap_child.log <== > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x0400): > ldap_child started. > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x2000): > context initialized > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] > (0x1000): total buffer size: 68 > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] > (0x1000): realm_str size: 13 > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] > (0x1000): got realm_str: SOLARIS.LOCAL > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] > (0x1000): princ_str size: 31 > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] > (0x1000): got princ_str: host/kwtpocpbis01.solaris.local > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] > (0x1000): keytab_name size: 0 > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] > (0x1000): lifetime: 86400 > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [unpack_buffer] > (0x0200): Will run as [0][0]. > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [privileged_krb5_setup] (0x2000): Kerberos context initialized > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x2000): > Kerberos context initialized > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [become_user] > (0x0200): Trying to become user [0][0]. > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [become_user] > (0x0200): Already user [0]. > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x2000): > Running as [0][0]. > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x2000): > getting TGT sync > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [ldap_child_get_tgt_sync] (0x2000): got realm_name: [SOLARIS.LOCAL] > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [ldap_child_get_tgt_sync] (0x0100): Principal name is: > [host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL] > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [ldap_child_get_tgt_sync] (0x0100): Using keytab [MEMORY:/etc/krb5.keytab] > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [ldap_child_get_tgt_sync] (0x0100): Will canonicalize principals > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.524474: Getting > initial credentials for host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.526526: Looked up > etypes in keytab: rc4-hmac, des3-cbc-sha1, aes128-cts, aes256-cts > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.526597: Sending > request (196 bytes) to SOLARIS.LOCAL > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.526803: Initiating > TCP connection to stream 172.16.107.244:88 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.526892: Sending TCP > request to stream 172.16.107.244:88 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528813: Received > answer (371 bytes) from stream 172.16.107.244:88 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528846: Terminating > TCP connection to stream 172.16.107.244:88 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528895: Response was > from master KDC > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528937: Received > error from KDC: -1765328359/Additional pre-authentication required > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.528977: Processing > preauth types: 136, 19, 2, 133 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529008: Selected > etype info: etype aes256-cts, salt "jUdxx&tm\3}.mh_[", params "" > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529023: Received > cookie: MIT > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529056: Retrieving > host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL from > MEMORY:/etc/krb5.keytab (vno 0, enctype aes256-cts) with result: 0/Success > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529088: AS key > obtained for encrypted timestamp: aes256-cts/445E > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529148: Encrypted > timestamp (for 1426592010.528836): plain > 301AA011180F32303135303331373131333333305AA10502030811C4, encrypted > 98625FC80F84BE6C287E596D254D3862CE1A8938418E92A91224BB349985496C8AD8D7161D736951B4C3907B8F4CB964577C28F6C3B81708 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529173: Preauth > module encrypted_timestamp (2) (real) returned: 0/Success > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529195: Produced > preauth for next request: 133, 2 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529216: Sending > request (291 bytes) to SOLARIS.LOCAL > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529248: Initiating > TCP connection to stream 172.16.107.244:88 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.529293: Sending TCP > request to stream 172.16.107.244:88 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.535622: Received > answer (201 bytes) from stream 172.16.107.244:88 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.535657: Terminating > TCP connection to stream 172.16.107.244:88 > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.535705: Response was > from master KDC > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [sss_child_krb5_trace_cb] (0x4000): [16425] 1426592010.535733: Received > error from KDC: -1765328353/Decrypt integrity check failed > > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] > [ldap_child_get_tgt_sync] (0x0010): Failed to init credentials: Decrypt > integrity check failed > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x0020): > ldap_child_get_tgt_sync failed. > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [prepare_response] > (0x0400): Building response for result [-1765328353] > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [pack_buffer] > (0x2000): response size: 50 > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [pack_buffer] > (0x1000): result [14] krberr [-1765328353] msgsize [30] msg [Decrypt > integrity check failed] > (Tue Mar 17 14:33:30 2015) [[sssd[ldap_child[16425]]]] [main] (0x0400): > ldap_child completed successfully > > ==> sssd_solaris.local.log <== > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [child_sig_handler] > (0x1000): Waiting for child [16425]. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [child_sig_handler] > (0x0100): child [16425] finished successfully. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [read_pipe_handler] > (0x0400): EOF received, client finished > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] > (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on > [0] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] > (0x0100): Could not get TGT: 14 [Bad address] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_cli_kinit_done] > (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not > working' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' > as 'not working' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_handle_release] > (0x2000): Trace: sh[0x7f6b7d2c6140], connected[1], ops[(nil)], > ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [remove_connection_callback] (0x4000): Successfully removed connection > callback. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [check_online_callback] (0x0100): Backend returned: (3, 0, ) > [Internal Error (Success)] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_srv_data_status] > (0x0100): Marking SRV lookup of service 'gc_infra.com' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0100): Marking port 0 of server '(no name)' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [set_srv_data_status] > (0x0100): Marking SRV lookup of service 'infra.com' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0100): Marking port 0 of server '(no name)' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [set_server_common_status] (0x0100): Marking server > 'kwtpocpbis01.solaris.local' as 'name not resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' > as 'neutral' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_ptask_disable] > (0x0400): Task [Check if online (periodic)]: disabling task > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [be_run_online_cb] > (0x0080): Going online. Running callbacks. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [ipa_subdom_reset_timeouts_cb] (0x4000): Resetting last_refreshed and > disabled_until. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_sudo_schedule_refresh] (0x0400): Full refresh scheduled at: 1426592010 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_sudo_full_refresh_send] (0x0400): Issuing a full refresh of sudo rules > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_id_op_connect_step] (0x4000): beginning to connect > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] > (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not > resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 > seconds > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [get_server_status] > (0x1000): Status of server 'kwtpocpbis01.solaris.local' is 'name not > resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [resolv_is_address] > (0x4000): [kwtpocpbis01.solaris.local] does not look like an IP address > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [resolv_gethostbyname_step] (0x2000): Querying files > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [resolv_gethostbyname_files_send] (0x0100): Trying to resolve A record of > 'kwtpocpbis01.solaris.local' in files > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [set_server_common_status] (0x0100): Marking server > 'kwtpocpbis01.solaris.local' as 'resolving name' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [set_server_common_status] (0x0100): Marking server > 'kwtpocpbis01.solaris.local' as 'name resolved' > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [be_resolve_server_process] (0x1000): Saving the first resolved server > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [be_resolve_server_process] (0x0200): Found address for server > kwtpocpbis01.solaris.local: [172.16.107.244] TTL 7200 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] > (0x4000): Using file descriptor [22] for LDAP connection. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sss_ldap_init_send] > (0x0400): Setting 6 seconds timeout for connecting > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_ldap_connect_callback_add] (0x1000): New LDAP connection to > [ldap://kwtpocpbis01.solaris.local:389/??base] with fd [22]. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_rootdse_send] (0x4000): Getting rootdse > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [sdap_print_server] > (0x2000): Searching 172.16.107.244 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with > [(objectclass=*)][]. > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [*] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [altServer] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [namingContexts] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedControl] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedExtension] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [supportedFeatures] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedLDAPVersion] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [supportedSASLMechanisms] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [domainControllerFunctionality] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [defaultNamingContext] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [lastUSN] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x1000): Requesting attrs: > [highestCommittedUSN] > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 1 > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] [ad_online_cb] > (0x0400): The AD provider is online > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [sdap_id_op_connect_step] (0x4000): waiting for connection to complete > (Tue Mar 17 14:33:30 2015) [sssd[be[solaris.local]]] > [delayed_online_authentication_callback] (0x0200): Backend is online, > starting delayed online authentication. > > > On Tue, Mar 17, 2015 at 2:23 PM, Ben .T.George > wrote: > >> HI >> >> i have changed like this: >> >> [root at kwtpocpbis01 yum.repos.d]# more /etc/sssd/sssd.conf >> [domain/solaris.local] >> cache_credentials = True >> krb5_store_password_if_offline = True >> ipa_domain = solaris.local >> id_provider = ipa >> auth_provider = ipa >> access_provider = ipa >> ipa_hostname = kwtpocpbis01.solaris.local >> chpass_provider = ipa >> ipa_server = kwtpocpbis01.solaris.local >> ipa_server_mode = True >> ldap_tls_cacert = /etc/ipa/ca.crt >> debug_level = 10 >> [sssd] >> services = nss, sudo, pam, ssh >> config_file_version = 2 >> debug_level = 5 >> domains = solaris.local >> [nss] >> homedir_substring = /home >> debug_level = 6 >> >> [pam] >> debug_level = 10 >> [sudo] >> debug_level = 5 >> [autofs] >> debug_level = 5 >> [ssh] >> debug_level = 5 >> [pac] >> debug_level = 5 >> [ifp] >> >> >> but sssd.log looks same. >> >> (Tue Mar 17 14:23:13 2015) [sssd] [ping_check] (0x0100): Service pam >> replied to ping >> (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging >> solaris.local >> (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging >> nss >> (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging >> sudo >> (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging >> pam >> (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging >> ssh >> (Tue Mar 17 14:23:23 2015) [sssd] [service_send_ping] (0x0100): Pinging >> pac >> (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service sudo >> replied to ping >> (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service ssh >> replied to ping >> (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service pam >> replied to ping >> (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service >> solaris.local replied to ping >> (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service pac >> replied to ping >> (Tue Mar 17 14:23:23 2015) [sssd] [ping_check] (0x0100): Service nss >> replied to ping >> >> On Tue, Mar 17, 2015 at 1:27 PM, Jakub Hrozek wrote: >> >>> On Tue, Mar 17, 2015 at 12:57:27PM +0300, Ben .T.George wrote: >>> > HI >>> > >>> > i have enabled debug >>> > >>> > here is my sssd.conf >>> > >>> > [root at kwtpocpbis01 ~]# cat /etc/sssd/sssd.conf >>> > [domain/solaris.local] >>> > >>> > cache_credentials = True >>> > krb5_store_password_if_offline = True >>> > ipa_domain = solaris.local >>> > id_provider = ipa >>> > auth_provider = ipa >>> > access_provider = ipa >>> > ipa_hostname = kwtpocpbis01.solaris.local >>> > chpass_provider = ipa >>> > ipa_server = kwtpocpbis01.solaris.local >>> > ipa_server_mode = True >>> > ldap_tls_cacert = /etc/ipa/ca.crt >>> >>> Please also add debug_level to this section, not just [sssd] and [nss] >>> >>> >>> > [sssd] >>> > services = nss, sudo, pam, ssh >>> > config_file_version = 2 >>> > >>> > domains = solaris.local >>> > debug_level = 6 >>> > [nss] >>> > homedir_substring = /home >>> > debug_level = 6 >>> > >>> > [pam] >>> > >>> > [sudo] >>> > >>> > [autofs] >>> > >>> > [ssh] >>> > >>> > [pac] >>> > >>> > [ifp] >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Tue Mar 17 11:45:06 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 17 Mar 2015 12:45:06 +0100 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: <20150317090922.GL9563@hendrix.arn.redhat.com> <20150317102759.GN9563@hendrix.arn.redhat.com> Message-ID: <20150317114506.GT9563@hendrix.arn.redhat.com> On Tue, Mar 17, 2015 at 02:38:41PM +0300, Ben .T.George wrote: > here is separated logs: > > tail -f sssd_solaris.local.log Thank you, see inline: > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] > (0x0400): Child responded: 14 [Decrypt integrity check failed], expired on > [0] > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] > (0x0100): Could not get TGT: 14 [Bad address] > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_cli_kinit_done] > (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not > working' > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' > as 'not working' > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_handle_release] > (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], > ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] > [remove_connection_callback] (0x4000): Successfully removed connection > callback. > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] > [check_online_callback] (0x0100): Backend returned: (3, 0, ) > [Internal Error (Success)] So it seems the keytab is wrong, you can also test the keytab validity with "kinit -k".. From bentech4you at gmail.com Tue Mar 17 12:02:00 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 15:02:00 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: <20150317114506.GT9563@hendrix.arn.redhat.com> References: <20150317090922.GL9563@hendrix.arn.redhat.com> <20150317102759.GN9563@hendrix.arn.redhat.com> <20150317114506.GT9563@hendrix.arn.redhat.com> Message-ID: Hi i did kinit [root at kwtpocpbis01 sssd]# kinit -kt /etc/dirsrv/ds.keytab kinit: Keytab contains no suitable keys for host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL while getting initial credentials i destroyed and re-created. but still same On Tue, Mar 17, 2015 at 2:45 PM, Jakub Hrozek wrote: > On Tue, Mar 17, 2015 at 02:38:41PM +0300, Ben .T.George wrote: > > here is separated logs: > > > > tail -f sssd_solaris.local.log > > Thank you, see inline: > > > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] > > (0x0400): Child responded: 14 [Decrypt integrity check failed], expired > on > > [0] > > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] > > (0x0100): Could not get TGT: 14 [Bad address] > > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] > [sdap_cli_kinit_done] > > (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) > > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > > (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not > > working' > > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [fo_set_port_status] > > (0x0400): Marking port 0 of duplicate server 'kwtpocpbis01.solaris.local' > > as 'not working' > > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] > [sdap_handle_release] > > (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], > > ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] > > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] > > [remove_connection_callback] (0x4000): Successfully removed connection > > callback. > > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] > > [check_online_callback] (0x0100): Backend returned: (3, 0, ) > > [Internal Error (Success)] > > So it seems the keytab is wrong, you can also test the keytab validity > with "kinit -k".. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Tue Mar 17 12:32:55 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Tue, 17 Mar 2015 13:32:55 +0100 Subject: [Freeipa-users] DNS forwarders Message-ID: Hi there, I've just installed freeIPA on a FC21 server and trying to perform some sanity checks. A first puzzle for me is: I have some DNS forwarders, which I selected during installation. They do work and they do appear in /etc/named.conf forward first; forwarders { 217.21.244.7; 217.21.244.66; 8.8.8.8; 8.8.4.4; }; However, I don't see them as DNS forwarders in IPA? Should I see them? Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan at redhat.com Mon Mar 16 22:24:12 2015 From: dan at redhat.com (Dan Lavu) Date: Mon, 16 Mar 2015 18:24:12 -0400 (EDT) Subject: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA In-Reply-To: References: Message-ID: <6485318.331.1426544650200.JavaMail.?@msmarvel.lab.runlevelone.lan> I was helping a friend out with his environment that was experiencing the same issue. CC'ing him as well. Between his ipa servers, the conflicted values were the same just time stamp that created the conflict? (I'm still not sure what caused the conflict in the first place). So what we did to fix the issue was to modify the entries and remove the conflict. You can follow this guide, https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html and with a simple script we were able to clean up the conflicts. Then SSSD started working again as soon as these conflicts were cleaned up, just make sure the values are the same between both servers otherwise you may be updating the environment with old data. Let me know if you have specific questions. Dan ----- Original Message ----- From: "Jakub Hrozek" To: "Andreas Skarmutsos Lindh" Cc: freeipa-users at redhat.com, "Dan Lavu" Sent: Monday, March 16, 2015 5:37:16 PM Subject: Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA > On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh wrote: > > Hi everyone, > > After upgrading (using rpm, yum upgrade) I can no longer login to my machines using ssh. Before the upgrade everything was working fine. > > Some loose facts: > - I'm installing IPA packages from the RHEL repositories onto RHEL systems, so I'm not sure if this is the right mailing list to ask for assistance > - I have a basic setup of IPA with minimum rules (deleted HBAC rules to single that out), using SSSD+PAM. > - Both other machines that are upgraded to a more recent version of sssd and it's fellow packages and servers which was not yum upgraded are affected by the issue, thus, everything seems to point at IPA. > - I'm able to obtain a kerberos ticket via kinit > - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 > > SSH returns (adding -vvv hardly tells me anything useful): > Connection closed by UNKNOWN > > I think that I have boiled down the issue to the following.. > Both clients with upgraded sssd (1.12.2-58) and non upgraded clients (1.11.2-65) give me the following output in sssd_.log: > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync Managers Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] (0x0020): Could not construct eval request > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) [Internal Error (System error)] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sending result [4][domain.com] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [be_pam_handler_callback] (0x0100): Sent result [4][domain.com] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], ldap[0x7f571108d0e0] > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! > This is a combination of a broken replication on the server side and too strict SSSD processing which can't handle unexpected entries. The broken replication has yielded entries like: cn=Modify PassSync Managers Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] note the nsUniqueID. As I learned today, entries with nsUniqueID in the RDN are relicts of broken replication. Dan Lavu (CC) has helped another setup with the same symtoms recently, maybe he can help here as well? The SSSD should just skip malformed entries if no DENY rules are used. That is tracked by SSSD ticket #2603. I have local patches for that one and I'll send them out to the list tomorrow. > I'm happy to attach more logs if needed. > I would very much like to avoid rolling back to an older IPA version by reinstalling everything from scratch. > Any and all help would be very much appreciated. > > Thanks in advance, > Andreas > -- > 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 andreas at superblock.se Tue Mar 17 09:06:46 2015 From: andreas at superblock.se (Andreas Skarmutsos Lindh) Date: Tue, 17 Mar 2015 10:06:46 +0100 Subject: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA In-Reply-To: <6485318.331.1426544650200.JavaMail.?@msmarvel.lab.runlevelone.lan> References: <6485318.331.1426544650200.JavaMail.?@msmarvel.lab.runlevelone.lan> Message-ID: Thanks, I'll look into that. Would you mind sharing the script used to clean up the entries? That would save me some time. Not expecting anything that I can run blindly and that will magically solve my problems, but some hints would definitely be appreciated :-) - Andreas On Mon, Mar 16, 2015 at 11:24 PM, Dan Lavu wrote: > I was helping a friend out with his environment that was experiencing the > same issue. CC'ing him as well. > > Between his ipa servers, the conflicted values were the same just time > stamp that created the conflict? (I'm still not sure what caused the > conflict in the first place). So what we did to fix the issue was to modify > the entries and remove the conflict. You can follow this guide, > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > and with a simple script we were able to clean up the conflicts. > > Then SSSD started working again as soon as these conflicts were cleaned > up, just make sure the values are the same between both servers otherwise > you may be updating the environment with old data. Let me know if you have > specific questions. > > Dan > > > ------------------------------ > *From: *"Jakub Hrozek" > *To: *"Andreas Skarmutsos Lindh" > *Cc: *freeipa-users at redhat.com, "Dan Lavu" > *Sent: *Monday, March 16, 2015 5:37:16 PM > *Subject: *Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA > > > > > On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh < > andreas at superblock.se> wrote: > > > > Hi everyone, > > > > After upgrading (using rpm, yum upgrade) I can no longer login to my > machines using ssh. Before the upgrade everything was working fine. > > > > Some loose facts: > > - I'm installing IPA packages from the RHEL repositories onto RHEL > systems, so I'm not sure if this is the right mailing list to ask for > assistance > > - I have a basic setup of IPA with minimum rules (deleted HBAC rules to > single that out), using SSSD+PAM. > > - Both other machines that are upgraded to a more recent version of sssd > and it's fellow packages and servers which was not yum upgraded are > affected by the issue, thus, everything seems to point at IPA. > > - I'm able to obtain a kerberos ticket via kinit > > - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 > > > > SSH returns (adding -vvv hardly tells me anything useful): > > Connection closed by UNKNOWN > > > > I think that I have boiled down the issue to the following.. > > Both clients with upgraded sssd (1.12.2-58) and non upgraded clients > (1.11.2-65) give me the following output in sssd_.log: > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync > Managers > Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] > (0x0020): Could not construct eval request > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) > [Internal Error (System error)] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [be_pam_handler_callback] (0x0100): Sending result [4][domain.com] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [be_pam_handler_callback] (0x0100): Sent result [4][domain.com] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] > (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], > ldap[0x7f571108d0e0] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] > (0x2000): Trace: ldap_result found nothing! > > > > This is a combination of a broken replication on the server side and too > strict SSSD processing which can't handle unexpected entries. The broken > replication has yielded entries like: > cn=Modify PassSync Managers > Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] > note the nsUniqueID. As I learned today, entries with nsUniqueID in the > RDN are relicts of broken replication. > > Dan Lavu (CC) has helped another setup with the same symtoms recently, > maybe he can help here as well? > > The SSSD should just skip malformed entries if no DENY rules are used. > That is tracked by SSSD ticket #2603. I have local patches for that one and > I'll send them out to the list tomorrow. > > > I'm happy to attach more logs if needed. > > I would very much like to avoid rolling back to an older IPA version by > reinstalling everything from scratch. > > Any and all help would be very much appreciated. > > > > Thanks in advance, > > Andreas > > -- > > 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 andreas at superblock.se Tue Mar 17 10:14:36 2015 From: andreas at superblock.se (Andreas Skarmutsos Lindh) Date: Tue, 17 Mar 2015 11:14:36 +0100 Subject: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA In-Reply-To: <6485318.331.1426544650200.JavaMail.?@msmarvel.lab.runlevelone.lan> References: <6485318.331.1426544650200.JavaMail.?@msmarvel.lab.runlevelone.lan> Message-ID: Quick update: I think that I have solved it, by just deleting the entries holding nsuniqueid additional string. I went forward using a gui application for browsing LDAP structures. I guess a script for tackling this issue in a slightly more automated way could probably be of value to other people. Thanks a lot for the help & support guys - Andreas On Mon, Mar 16, 2015 at 11:24 PM, Dan Lavu wrote: > I was helping a friend out with his environment that was experiencing the > same issue. CC'ing him as well. > > Between his ipa servers, the conflicted values were the same just time > stamp that created the conflict? (I'm still not sure what caused the > conflict in the first place). So what we did to fix the issue was to modify > the entries and remove the conflict. You can follow this guide, > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > and with a simple script we were able to clean up the conflicts. > > Then SSSD started working again as soon as these conflicts were cleaned > up, just make sure the values are the same between both servers otherwise > you may be updating the environment with old data. Let me know if you have > specific questions. > > Dan > > > ------------------------------ > *From: *"Jakub Hrozek" > *To: *"Andreas Skarmutsos Lindh" > *Cc: *freeipa-users at redhat.com, "Dan Lavu" > *Sent: *Monday, March 16, 2015 5:37:16 PM > *Subject: *Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA > > > > > On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh < > andreas at superblock.se> wrote: > > > > Hi everyone, > > > > After upgrading (using rpm, yum upgrade) I can no longer login to my > machines using ssh. Before the upgrade everything was working fine. > > > > Some loose facts: > > - I'm installing IPA packages from the RHEL repositories onto RHEL > systems, so I'm not sure if this is the right mailing list to ask for > assistance > > - I have a basic setup of IPA with minimum rules (deleted HBAC rules to > single that out), using SSSD+PAM. > > - Both other machines that are upgraded to a more recent version of sssd > and it's fellow packages and servers which was not yum upgraded are > affected by the issue, thus, everything seems to point at IPA. > > - I'm able to obtain a kerberos ticket via kinit > > - Running the following package version: ipa-server-4.1.0-18.el7.x86_64 > > > > SSH returns (adding -vvv hardly tells me anything useful): > > Connection closed by UNKNOWN > > > > I think that I have boiled down the issue to the following.. > > Both clients with upgraded sssd (1.12.2-58) and non upgraded clients > (1.11.2-65) give me the following output in sssd_.log: > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [hbac_eval_user_element] (0x0080): Parse error on [cn=Modify PassSync > Managers > Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [hbac_ctx_to_rules] > (0x0020): Could not construct eval request > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [ipa_hbac_evaluate_rules] (0x0020): Could not construct HBAC rules > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [be_pam_handler_callback] (0x0100): Backend returned: (3, 4, ) > [Internal Error (System error)] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [be_pam_handler_callback] (0x0100): Sending result [4][domain.com] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] > [be_pam_handler_callback] (0x0100): Sent result [4][domain.com] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] > (0x2000): Trace: sh[0x7f5711099220], connected[1], ops[(nil)], > ldap[0x7f571108d0e0] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com]]] [sdap_process_result] > (0x2000): Trace: ldap_result found nothing! > > > > This is a combination of a broken replication on the server side and too > strict SSSD processing which can't handle unexpected entries. The broken > replication has yielded entries like: > cn=Modify PassSync Managers > Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] > note the nsUniqueID. As I learned today, entries with nsUniqueID in the > RDN are relicts of broken replication. > > Dan Lavu (CC) has helped another setup with the same symtoms recently, > maybe he can help here as well? > > The SSSD should just skip malformed entries if no DENY rules are used. > That is tracked by SSSD ticket #2603. I have local patches for that one and > I'll send them out to the list tomorrow. > > > I'm happy to attach more logs if needed. > > I would very much like to avoid rolling back to an older IPA version by > reinstalling everything from scratch. > > Any and all help would be very much appreciated. > > > > Thanks in advance, > > Andreas > > -- > > 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 lkrispen at redhat.com Tue Mar 17 12:58:05 2015 From: lkrispen at redhat.com (Ludwig Krispenz) Date: Tue, 17 Mar 2015 13:58:05 +0100 Subject: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA In-Reply-To: References: <6485318.331.1426544650200.JavaMail.?@msmarvel.lab.runlevelone.lan> Message-ID: <550824DD.2040307@redhat.com> Hi, do you have the DS access logs from your servers from the time around the conflicting entry was created ? Thanks, Ludwig On 03/17/2015 11:14 AM, Andreas Skarmutsos Lindh wrote: > Quick update: I think that I have solved it, by just deleting the > entries holding nsuniqueid additional string. I went forward using a > gui application for browsing LDAP structures. > I guess a script for tackling this issue in a slightly more automated > way could probably be of value to other people. > > Thanks a lot for the help & support guys > > > - Andreas > > On Mon, Mar 16, 2015 at 11:24 PM, Dan Lavu > wrote: > > I was helping a friend out with his environment that was > experiencing the same issue. CC'ing him as well. > > Between his ipa servers, the conflicted values were the same just > time stamp that created the conflict? (I'm still not sure what > caused the conflict in the first place). So what we did to fix the > issue was to modify the entries and remove the conflict. You can > follow this guide, > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/Managing_Replication-Solving_Common_Replication_Conflicts.html > and with a simple script we were able to clean up the conflicts. > > Then SSSD started working again as soon as these conflicts were > cleaned up, just make sure the values are the same between both > servers otherwise you may be updating the environment with old > data. Let me know if you have specific questions. > > Dan > > > ------------------------------------------------------------------------ > *From: *"Jakub Hrozek" > > *To: *"Andreas Skarmutsos Lindh" > > *Cc: *freeipa-users at redhat.com , > "Dan Lavu" > > *Sent: *Monday, March 16, 2015 5:37:16 PM > *Subject: *Re: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA > > > > > On 16 Mar 2015, at 22:03, Andreas Skarmutsos Lindh > > wrote: > > > > Hi everyone, > > > > After upgrading (using rpm, yum upgrade) I can no longer login > to my machines using ssh. Before the upgrade everything was > working fine. > > > > Some loose facts: > > - I'm installing IPA packages from the RHEL repositories onto > RHEL systems, so I'm not sure if this is the right mailing list to > ask for assistance > > - I have a basic setup of IPA with minimum rules (deleted HBAC > rules to single that out), using SSSD+PAM. > > - Both other machines that are upgraded to a more recent version > of sssd and it's fellow packages and servers which was not yum > upgraded are affected by the issue, thus, everything seems to > point at IPA. > > - I'm able to obtain a kerberos ticket via kinit > > - Running the following package version: > ipa-server-4.1.0-18.el7.x86_64 > > > > SSH returns (adding -vvv hardly tells me anything useful): > > Connection closed by UNKNOWN > > > > I think that I have boiled down the issue to the following.. > > Both clients with upgraded sssd (1.12.2-58) and non upgraded > clients (1.11.2-65) give me the following output in sssd_.log: > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com > ]]] [hbac_eval_user_element] (0x0080): Parse > error on [cn=Modify PassSync Managers > Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com > ]]] [hbac_ctx_to_rules] (0x0020): Could not > construct eval request > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com > ]]] [ipa_hbac_evaluate_rules] (0x0020): Could > not construct HBAC rules > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com > ]]] [be_pam_handler_callback] (0x0100): Backend > returned: (3, 4, ) [Internal Error (System error)] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com > ]]] [be_pam_handler_callback] (0x0100): Sending > result [4][domain.com ] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com > ]]] [be_pam_handler_callback] (0x0100): Sent > result [4][domain.com ] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com > ]]] [sdap_process_result] (0x2000): Trace: > sh[0x7f5711099220], connected[1], ops[(nil)], ldap[0x7f571108d0e0] > > (Mon Mar 16 14:12:17 2015) [sssd[be[domain.com > ]]] [sdap_process_result] (0x2000): Trace: > ldap_result found nothing! > > > > This is a combination of a broken replication on the server side > and too strict SSSD processing which can't handle unexpected > entries. The broken replication has yielded entries like: > cn=Modify PassSync Managers > Configuration+nsuniqueid=21e13243-cbd011e4-ba3a9b82-0e1e4aae,cn=permissions,cn=pbac,dc=domain,dc=com] > note the nsUniqueID. As I learned today, entries with nsUniqueID > in the RDN are relicts of broken replication. > > Dan Lavu (CC) has helped another setup with the same symtoms > recently, maybe he can help here as well? > > The SSSD should just skip malformed entries if no DENY rules are > used. That is tracked by SSSD ticket #2603. I have local patches > for that one and I'll send them out to the list tomorrow. > > > I'm happy to attach more logs if needed. > > I would very much like to avoid rolling back to an older IPA > version by reinstalling everything from scratch. > > Any and all help would be very much appreciated. > > > > Thanks in advance, > > Andreas > > -- > > 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 mbasti at redhat.com Tue Mar 17 13:06:12 2015 From: mbasti at redhat.com (Martin Basti) Date: Tue, 17 Mar 2015 14:06:12 +0100 Subject: [Freeipa-users] DNS forwarders In-Reply-To: References: Message-ID: <550826C4.3070704@redhat.com> On 17/03/15 13:32, Roberto Cornacchia wrote: > Hi there, > > I've just installed freeIPA on a FC21 server and trying to perform > some sanity checks. > > A first puzzle for me is: I have some DNS forwarders, which I selected > during installation. > They do work and they do appear in /etc/named.conf > > forward first; > forwarders { > 217.21.244.7; > 217.21.244.66; > 8.8.8.8; > 8.8.4.4; > }; > > However, I don't see them as DNS forwarders in IPA? Should I see them? > > Roberto > > Hello, if you want to see them in IPA, you must add those forwarders with IPA command ipa dnsconfig-mod --forwarder=8.8.4.4 --forwarder=8.8.8.8 ... or using webUI This setting will override configuration of forwarders in named.conf. I don't know if there are some historical reasons to configure forwarders only in named.conf during installation, do you know Petr? -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Tue Mar 17 13:51:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 17 Mar 2015 14:51:52 +0100 Subject: [Freeipa-users] DNS forwarders In-Reply-To: <550826C4.3070704@redhat.com> References: <550826C4.3070704@redhat.com> Message-ID: <55083178.2090606@redhat.com> On 17.3.2015 14:06, Martin Basti wrote: > On 17/03/15 13:32, Roberto Cornacchia wrote: >> Hi there, >> >> I've just installed freeIPA on a FC21 server and trying to perform some >> sanity checks. >> >> A first puzzle for me is: I have some DNS forwarders, which I selected >> during installation. >> They do work and they do appear in /etc/named.conf >> >> forward first; >> forwarders { >> 217.21.244.7; >> 217.21.244.66; >> 8.8.8.8; >> 8.8.4.4; >> }; >> >> However, I don't see them as DNS forwarders in IPA? Should I see them? >> >> Roberto >> >> > Hello, > > if you want to see them in IPA, you must add those forwarders with IPA command > > ipa dnsconfig-mod --forwarder=8.8.4.4 --forwarder=8.8.8.8 ... > or using webUI > > This setting will override configuration of forwarders in named.conf. > > I don't know if there are some historical reasons to configure forwarders only > in named.conf during installation, do you know Petr? This is done for practical purposes. In cases where you have multiple IPA servers scatted across the globe you most likely do not want to use the same set of forwarders for all IPA DNS servers - usually you want to use nearest forwarder possible. 'ipa dnsconfig' is global for the whole cluster, /etc/named.conf is local for that particular server. It would be nice to move per-server configuration to LDAP to make it available via IPA user interface but up to know it did not get priority. -- Petr^2 Spacek From guertin at middlebury.edu Tue Mar 17 15:18:32 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 17 Mar 2015 15:18:32 +0000 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID Message-ID: <1426605513212.47081@middlebury.edu> We have a trust relationship established between our AD domain and our IPA domain, and AD users can be found on the IPA server with id and getent passwd. When a user tries to SSH to the IPA server with AD credentials, the logs show: (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x0400): Processing user guertin-s (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x1000): Mapping user [guertin-s] objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to unix ID (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID It seems that this is a problem with the ID range, but I can't see where the problem is. We increased the default ranges of 200,000 to 2,000,000, which I would think should be able to handle a RID of 245906: # ipa idrange-find --all ---------------- 2 ranges matched ---------------- dn: cn=CSNS.MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu Range name: CSNS.MIDDLEBURY.EDU_id_range First Posix ID of the range: 1824600000 Number of IDs in the range: 2000000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range iparangetyperaw: ipa-local objectclass: top, ipaIDrange, ipaDomainIDRange dn: cn=MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu Range name: MIDDLEBURY.EDU_id_range First Posix ID of the range: 10000 Number of IDs in the range: 2000000 Domain SID of the trusted domain: S-1-5-21-1983215674-46037090-646806464 Range type: Active Directory trust range with POSIX attributes iparangetyperaw: ipa-ad-trust-posix objectclass: ipatrustedaddomainrange, ipaIDrange ---------------------------- Number of entries returned 2 ---------------------------- But the error remains. What am I missing? David Guertin -------------- next part -------------- An HTML attachment was scrubbed... URL: From tevfik.ceydeliler at astron.yasar.com.tr Tue Mar 17 15:19:25 2015 From: tevfik.ceydeliler at astron.yasar.com.tr (Tevfik Ceydeliler) Date: Tue, 17 Mar 2015 17:19:25 +0200 Subject: [Freeipa-users] Unknown Client? Message-ID: <550845FD.7010604@astron.yasar.com.tr> Hi, Altough I have this configuration in client .conf: ################################## client 172.30.47.241 { secret = 877909 shortname = VodafonePinarsuAPNYeni1 nastype = other } client 172.30.47.242 { secret = 877909 shortname = VodafonePinarsuAPNYeni2 nastype = other } #################################### Why I get this error? ################################################################################################# Tue Mar 17 14:31:55 2015 : Error: Ignoring request to authentication address * port 1812 from unknown client 172.30.47.242 port 58312 Tue Mar 17 14:32:01 2015 : Error: Ignoring request to authentication address * port 1812 from unknown client 172.30.47.241 port 6040 ################################################################################################# And I am sure that secret is correct. Any idea? Bu elektronik postada bulunan tum fikir ve gorusler ve ekindeki dosyalar sadece adres sahip/sahiplerine ait olup, Yasar Toplulugu Sirketleri bu mesajin icerigi ile ilgili olarak hic bir hukuksal sorumlulugu kabul etmez. Eger gonderilmesi dusunulen kisi veya kurulus degilseniz, lutfen gonderen kisiyi derhal haberdar ediniz ve mesaji sisteminizden siliniz.The information contained in this e-mail and any files transmitted with it are intended solely for the use of the individual or entity to whom they are addressed and Yasar Group Companies do not accept legal responsibility for the contents. If you are not the intended recipient, please immediately notify the sender and delete it from your system. From ranger at opennms.org Tue Mar 17 15:27:34 2015 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 17 Mar 2015 11:27:34 -0400 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <550810EF.2030705@redhat.com> References: <5507289E.2000703@opennms.org> <550810EF.2030705@redhat.com> Message-ID: <550847E6.8010303@opennms.org> On 3/17/15 7:33 AM, Martin Kosek wrote: > # ipa config-mod --enable-migration=true > > # echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager" > --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts > --group-objectclass=posixgroup > --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference} > --with-compat ldap://vm-086.rhel-6.test Confirmed, this works PERFECTLY. It'd be great to have it as a simple option in the migrate-ds script. Thanks so much for the help! You saved me a lot of pain. :) -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From rcritten at redhat.com Tue Mar 17 15:32:15 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Mar 2015 11:32:15 -0400 Subject: [Freeipa-users] Unknown Client? In-Reply-To: <550845FD.7010604@astron.yasar.com.tr> References: <550845FD.7010604@astron.yasar.com.tr> Message-ID: <550848FF.8050602@redhat.com> Tevfik Ceydeliler wrote: > Hi, > Altough I have this configuration in client .conf: > > ################################## > client 172.30.47.241 { > secret = 877909 > shortname = VodafonePinarsuAPNYeni1 > nastype = other > } > > client 172.30.47.242 { > secret = 877909 > shortname = VodafonePinarsuAPNYeni2 > nastype = other > } > > #################################### > > Why I get this error? > > ################################################################################################# > > > Tue Mar 17 14:31:55 2015 : Error: Ignoring request to authentication > address * port 1812 from unknown client 172.30.47.242 port 58312 > Tue Mar 17 14:32:01 2015 : Error: Ignoring request to authentication > address * port 1812 from unknown client 172.30.47.241 port 6040 > > ################################################################################################# How is this related to IPA? rob From janellenicole80 at gmail.com Tue Mar 17 15:35:26 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 17 Mar 2015 08:35:26 -0700 Subject: [Freeipa-users] pki-tomcatd stopped responding? Won't restart? Message-ID: <550849BE.2020308@gmail.com> Hello, I have a server - a master (has CA) - and it does not want to restart after it has been running sometime. pki-tomcatd keeps failing. It starts up with these errors, then adds a lot more. Maybe this might point you to something that is know or a place I can start looking? Any ideas? ~J Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'enableOCSP' to 'false' did not find a matching property. Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' did not find a matching property. Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a matching property. Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspCacheSize' to '1000' did not find a matching property. Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspMinCacheEntryDuration' to '60' did not find a matching property. Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspMaxCacheEntryDuration' to '120' did not find a matching property. Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'ocspTimeout' to '10' did not find a matching property. Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'strictCiphers' to 'true' did not find a matching property. Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property 'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a matching property. From roberto.cornacchia at gmail.com Tue Mar 17 15:38:20 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Tue, 17 Mar 2015 16:38:20 +0100 Subject: [Freeipa-users] DNS forwarders In-Reply-To: <55083178.2090606@redhat.com> References: <550826C4.3070704@redhat.com> <55083178.2090606@redhat.com> Message-ID: I see. Peter, Martin, thanks for the explanation. My worry was that something went wrong in my reinstallation, glad to hear it is not the case. Roberto On 17 Mar 2015 14:51, "Petr Spacek" wrote: > On 17.3.2015 14:06, Martin Basti wrote: > > On 17/03/15 13:32, Roberto Cornacchia wrote: > >> Hi there, > >> > >> I've just installed freeIPA on a FC21 server and trying to perform some > >> sanity checks. > >> > >> A first puzzle for me is: I have some DNS forwarders, which I selected > >> during installation. > >> They do work and they do appear in /etc/named.conf > >> > >> forward first; > >> forwarders { > >> 217.21.244.7; > >> 217.21.244.66; > >> 8.8.8.8; > >> 8.8.4.4; > >> }; > >> > >> However, I don't see them as DNS forwarders in IPA? Should I see them? > >> > >> Roberto > >> > >> > > Hello, > > > > if you want to see them in IPA, you must add those forwarders with IPA > command > > > > ipa dnsconfig-mod --forwarder=8.8.4.4 --forwarder=8.8.8.8 ... > > or using webUI > > > > This setting will override configuration of forwarders in named.conf. > > > > I don't know if there are some historical reasons to configure > forwarders only > > in named.conf during installation, do you know Petr? > > This is done for practical purposes. In cases where you have multiple IPA > servers scatted across the globe you most likely do not want to use the > same > set of forwarders for all IPA DNS servers - usually you want to use nearest > forwarder possible. > > 'ipa dnsconfig' is global for the whole cluster, /etc/named.conf is local > for > that particular server. > > It would be nice to move per-server configuration to LDAP to make it > available > via IPA user interface but up to know it did not get priority. > > -- > Petr^2 Spacek > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 17 15:43:00 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Mar 2015 17:43:00 +0200 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: <1426605513212.47081@middlebury.edu> References: <1426605513212.47081@middlebury.edu> Message-ID: <20150317154300.GQ3878@redhat.com> On Tue, 17 Mar 2015, Guertin, David S. wrote: >We have a trust relationship established between our AD domain and our IPA domain, and AD users can be found on the IPA server with id and getent passwd. When a user tries to SSH to the IPA server with AD credentials, the logs show: > > >(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x0400): Processing user guertin-s >(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x1000): Mapping user [guertin-s] objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to unix ID >(Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID > >It seems that this is a problem with the ID range, but I can't see where the problem is. We increased the default ranges of 200,000 to 2,000,000, which I would think should be able to handle a RID of 245906: > > ># ipa idrange-find --all >---------------- >2 ranges matched >---------------- > dn: cn=CSNS.MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu > Range name: CSNS.MIDDLEBURY.EDU_id_range > First Posix ID of the range: 1824600000 > Number of IDs in the range: 2000000 > First RID of the corresponding RID range: 1000 > First RID of the secondary RID range: 100000000 > Range type: local domain range > iparangetyperaw: ipa-local > objectclass: top, ipaIDrange, ipaDomainIDRange > > dn: cn=MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu > Range name: MIDDLEBURY.EDU_id_range > First Posix ID of the range: 10000 > Number of IDs in the range: 2000000 > Domain SID of the trusted domain: S-1-5-21-1983215674-46037090-646806464 > Range type: Active Directory trust range with POSIX attributes > iparangetyperaw: ipa-ad-trust-posix > objectclass: ipatrustedaddomainrange, ipaIDrange >---------------------------- >Number of entries returned 2 >---------------------------- > >But the error remains. What am I missing? When you changed idrange, it helps to remove SSSD cache, both on IPA master and IPA clients and restart SSSD. -- / Alexander Bokovoy From mkosek at redhat.com Tue Mar 17 16:02:18 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Mar 2015 17:02:18 +0100 Subject: [Freeipa-users] 4.1.0: Logon issue after upgrading IPA In-Reply-To: References: <6485318.331.1426544650200.JavaMail.?@msmarvel.lab.runlevelone.lan> Message-ID: <5508500A.7050108@redhat.com> On 03/17/2015 11:14 AM, Andreas Skarmutsos Lindh wrote: > Quick update: I think that I have solved it, by just deleting the entries > holding nsuniqueid additional string. I went forward using a gui > application for browsing LDAP structures. > I guess a script for tackling this issue in a slightly more automated way > could probably be of value to other people. I am glad to see the problem resolved. FYI, the pending upstrema request to have more automated way of handling replication conflicts is https://fedorahosted.org/freeipa/ticket/1025 You can add yourself to CC list of you are interested in the updates (or even contribute help/patches :-) From mkosek at redhat.com Tue Mar 17 16:06:56 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Mar 2015 17:06:56 +0100 Subject: [Freeipa-users] pki-tomcatd stopped responding? Won't restart? In-Reply-To: <550849BE.2020308@gmail.com> References: <550849BE.2020308@gmail.com> Message-ID: <55085120.9010601@redhat.com> On 03/17/2015 04:35 PM, Janelle wrote: > Hello, > > I have a server - a master (has CA) - and it does not want to restart after it > has been running sometime. pki-tomcatd keeps failing. It starts up with these > errors, then adds a lot more. Maybe this might point you to something that is > know or a place I can start looking? > > Any ideas? > ~J > > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'enableOCSP' to 'false' did not find a matching property. > > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' did not find > a matching property. > > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a > matching property. > > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'ocspCacheSize' to '1000' did not find a matching property. > > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'ocspMinCacheEntryDuration' to '60' did not find a matching property. > > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'ocspMaxCacheEntryDuration' to '120' did not find a matching property. > > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'ocspTimeout' to '10' did not find a matching property. > > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'strictCiphers' to 'true' did not find a matching property. > Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin > > WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property > 'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a matching property. > CCing folks from Dogtag team to know about this issue. However, I think you will need to provide more information before we continue with issues - like version of FreeIPA, pki-ca packages, what system you are running it on (Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere (system and catalina.out logs are usually most interesting ones). From mkosek at redhat.com Tue Mar 17 16:09:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Mar 2015 17:09:44 +0100 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <550847E6.8010303@opennms.org> References: <5507289E.2000703@opennms.org> <550810EF.2030705@redhat.com> <550847E6.8010303@opennms.org> Message-ID: <550851C8.2000009@redhat.com> On 03/17/2015 04:27 PM, Benjamin Reed wrote: > On 3/17/15 7:33 AM, Martin Kosek wrote: >> # ipa config-mod --enable-migration=true >> >> # echo Secret123 | ipa migrate-ds --bind-dn="cn=Directory Manager" >> --user-container=cn=users,cn=accounts --group-container=cn=groups,cn=accounts >> --group-objectclass=posixgroup >> --user-ignore-attribute={krbPrincipalName,krbextradata,krblastfailedauth,krblastpwdchange,krblastsuccessfulauth,krbloginfailedcount,krbpasswordexpiration,krbticketflags,krbpwdpolicyreference} >> --with-compat ldap://vm-086.rhel-6.test > > Confirmed, this works PERFECTLY. > > It'd be great to have it as a simple option in the migrate-ds script. > > Thanks so much for the help! You saved me a lot of pain. :) Ah, good to hear! I would still wished we fixed the original root cause why replication was failing for you - as this is the obviously expected way of upgrading to RHEL/CentOS 7.1 from RHEL-6 environment and I think/hope it would be less work than starting over (depends on how populated is your existing IPA instance). Martin From janellenicole80 at gmail.com Tue Mar 17 16:12:50 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 17 Mar 2015 09:12:50 -0700 Subject: [Freeipa-users] pki-tomcatd stopped responding? Won't restart? In-Reply-To: <55085120.9010601@redhat.com> References: <550849BE.2020308@gmail.com> <55085120.9010601@redhat.com> Message-ID: <55085282.4080100@gmail.com> On 3/17/15 9:06 AM, Martin Kosek wrote: > On 03/17/2015 04:35 PM, Janelle wrote: >> Hello, >> >> I have a server - a master (has CA) - and it does not want to restart after it >> has been running sometime. pki-tomcatd keeps failing. It starts up with these >> errors, then adds a lot more. Maybe this might point you to something that is >> know or a place I can start looking? >> >> Any ideas? >> ~J >> >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'enableOCSP' to 'false' did not find a matching property. >> >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' did not find >> a matching property. >> >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not find a >> matching property. >> >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'ocspCacheSize' to '1000' did not find a matching property. >> >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'ocspMinCacheEntryDuration' to '60' did not find a matching property. >> >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'ocspMaxCacheEntryDuration' to '120' did not find a matching property. >> >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'ocspTimeout' to '10' did not find a matching property. >> >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'strictCiphers' to 'true' did not find a matching property. >> Mar 17, 2015 8:21:03 AM org.apache.catalina.startup.SetAllPropertiesRule begin >> >> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting property >> 'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a matching property. >> > CCing folks from Dogtag team to know about this issue. However, I think you > will need to provide more information before we continue with issues - like > version of FreeIPA, pki-ca packages, what system you are running it on > (Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere (system and > catalina.out logs are usually most interesting ones). My bad -- CentOS 7 FreeIPA 4.1.3 from mosek The strange thing is -- 12 other servers - 3 of which are CA masters and no issues, ~J From ranger at opennms.org Tue Mar 17 16:16:53 2015 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 17 Mar 2015 12:16:53 -0400 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <550851C8.2000009@redhat.com> References: <5507289E.2000703@opennms.org> <550810EF.2030705@redhat.com> <550847E6.8010303@opennms.org> <550851C8.2000009@redhat.com> Message-ID: <55085375.1050205@opennms.org> On 3/17/15 12:09 PM, Martin Kosek wrote: > I would still wished we fixed the original root cause why replication was > failing for you - as this is the obviously expected way of upgrading to > RHEL/CentOS 7.1 from RHEL-6 environment and I think/hope it would be less work > than starting over (depends on how populated is your existing IPA instance). Yeah, I totally get that, but I've actually been holding up a product launch trying to get things working, or I'd try to work through it longer. :( I'm actually going to just shut down the old server's IPA but not uninstall it, so if there is any progress made on the issue I've opened I may be able to try it with a fresh replication target still. I did run into one snag. Our IPA servers are on the public internet, so I've disabled anonymous bind. However, it appears that the /ipa/migration/ tool requires it; at least, I'm getting this error in httpd/error_log: > migration context search failed: Insufficient access: Inappropriate > authentication: Anonymous access is not allowed. Is there a way to make migration work without anonymous bind? A config file I can change somewhere to force the migration tool to bind as a user? -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From mkosek at redhat.com Tue Mar 17 16:29:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 17 Mar 2015 17:29:25 +0100 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <55085375.1050205@opennms.org> References: <5507289E.2000703@opennms.org> <550810EF.2030705@redhat.com> <550847E6.8010303@opennms.org> <550851C8.2000009@redhat.com> <55085375.1050205@opennms.org> Message-ID: <55085665.4040902@redhat.com> On 03/17/2015 05:16 PM, Benjamin Reed wrote: > On 3/17/15 12:09 PM, Martin Kosek wrote: >> I would still wished we fixed the original root cause why replication was >> failing for you - as this is the obviously expected way of upgrading to >> RHEL/CentOS 7.1 from RHEL-6 environment and I think/hope it would be less work >> than starting over (depends on how populated is your existing IPA instance). > > Yeah, I totally get that, but I've actually been holding up a product > launch trying to get things working, or I'd try to work through it > longer. :( > > I'm actually going to just shut down the old server's IPA but not > uninstall it, so if there is any progress made on the issue I've opened > I may be able to try it with a fresh replication target still. Ok, thank you. > I did run into one snag. Our IPA servers are on the public internet, so > I've disabled anonymous bind. However, it appears that the > /ipa/migration/ tool requires it; at least, I'm getting this error in > httpd/error_log: > >> migration context search failed: Insufficient access: Inappropriate >> authentication: Anonymous access is not allowed. I am CCing Peter Vobornik for the UI part. I think you are right. I quickly checked the code, it indeed does an anonymous search and it also does not use the CA certificate for TLS authentication when LDAPI is not available. IMO, a ticket creation is due, to use IPA API object to get the basedn that is read in the anonymous connection and to also use TLS when LDAPI is not available. > Is there a way to make migration work without anonymous bind? A config > file I can change somewhere to force the migration tool to bind as a user? Hmm, if the migration page is not working for you, I see following options: 1) Migrate users via SSSD and simply SSH or log in to any machine enrolled to the new IPA, as I showed in the example 2) Implement your own migration tool, doing an LDAP BIND for the migrated user (this is what SSSD does too anyway). 3) (hackish) Until the potential ticket is fixed, you can try to fix /usr/share/ipa/migration/migration.py on the IPA server yourself. This is the migration script that is used. If you actually fix it, you may even think about contributing the fix to FreeIPA project as a patch, it would be very welcome :-) From ranger at opennms.org Tue Mar 17 16:56:24 2015 From: ranger at opennms.org (Benjamin Reed) Date: Tue, 17 Mar 2015 12:56:24 -0400 Subject: [Freeipa-users] Gave Up on RHEL6->7 migration, starting over. (ipa migrate-ds) In-Reply-To: <55085665.4040902@redhat.com> References: <5507289E.2000703@opennms.org> <550810EF.2030705@redhat.com> <550847E6.8010303@opennms.org> <550851C8.2000009@redhat.com> <55085375.1050205@opennms.org> <55085665.4040902@redhat.com> Message-ID: <55085CB8.4010200@opennms.org> On 3/17/15 12:29 PM, Martin Kosek wrote: > 1) Migrate users via SSSD and simply SSH or log in to any machine enrolled to > the new IPA, as I showed in the example I'll have my users who need working kerberos ssh in. The union of the set of users who need kerberos and users who ssh is a circle. ;) > 2) Implement your own migration tool, doing an LDAP BIND for the migrated user > (this is what SSSD does too anyway). > > 3) (hackish) Until the potential ticket is fixed, you can try to fix > /usr/share/ipa/migration/migration.py on the IPA server yourself. This is the > migration script that is used. If you actually fix it, you may even think about > contributing the fix to FreeIPA project as a patch, it would be very welcome :-) I looked at the script and I don't know python or how the binding stuff is set up enough to understand making a patch, but I have at least created an issue: https://fedorahosted.org/freeipa/ticket/4953 Thanks again for your help. I've been banging my head on getting away from our broken old FreeIPA server for quite some time. -- Benjamin Reed The OpenNMS Group http://www.opennms.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 195 bytes Desc: OpenPGP digital signature URL: From guertin at middlebury.edu Tue Mar 17 17:02:15 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 17 Mar 2015 17:02:15 +0000 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: <20150317154300.GQ3878@redhat.com> References: <1426605513212.47081@middlebury.edu> <20150317154300.GQ3878@redhat.com> Message-ID: <3746481a704f4e68b6aea41daf62597f@greyhound.middlebury.edu> > When you changed idrange, it helps to remove SSSD cache, both on IPA > master and IPA clients and restart SSSD. OK, I cleared the cache and restarted sssd with: sss_cache -E systemctl restart sssd Still no change in the error: Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID FWIW, here's my sssd.conf: [domain/csns.middlebury.edu] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = csns.middlebury.edu id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = genet.csns.middlebury.edu chpass_provider = ipa ipa_server = genet.csns.middlebury.edu ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt [domain/middlebury.edu] id_provider = ad auth_provider = ad chpass_provider = ad access_provider = ad debug_level = 10 [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = middlebury.edu,csns.middlebury.edu debug_level = 10 [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] #debug_level = 10 [pac] [ifp] This is RHEL 7 running sssd-1.12.2 and ipa-server-4.1.0. Thanks for any suggestions. David Guertin From natxo.asenjo at gmail.com Tue Mar 17 17:07:36 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Tue, 17 Mar 2015 18:07:36 +0100 Subject: [Freeipa-users] Unknown Client? In-Reply-To: <550845FD.7010604@astron.yasar.com.tr> References: <550845FD.7010604@astron.yasar.com.tr> Message-ID: On Tue, Mar 17, 2015 at 4:19 PM, Tevfik Ceydeliler < tevfik.ceydeliler at astron.yasar.com.tr> wrote: > Hi, > Altough I have this configuration in client .conf: > > ################################## > client 172.30.47.241 { > secret = 877909 > shortname = VodafonePinarsuAPNYeni1 > nastype = other > } > > client 172.30.47.242 { > secret = 877909 > shortname = VodafonePinarsuAPNYeni2 > nastype = other > } > > #################################### > > Why I get this error? > > ############################################################ > ##################################### > > Tue Mar 17 14:31:55 2015 : Error: Ignoring request to authentication > address * port 1812 from unknown client 172.30.47.242 port 58312 > Tue Mar 17 14:32:01 2015 : Error: Ignoring request to authentication > address * port 1812 from unknown client 172.30.47.241 port 6040 > > ############################################################ > ##################################### > I think you should post your question to the free*radius* mailing list ;-) -- Groeten, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 17 17:22:29 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Mar 2015 19:22:29 +0200 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: <3746481a704f4e68b6aea41daf62597f@greyhound.middlebury.edu> References: <1426605513212.47081@middlebury.edu> <20150317154300.GQ3878@redhat.com> <3746481a704f4e68b6aea41daf62597f@greyhound.middlebury.edu> Message-ID: <20150317172229.GT3878@redhat.com> On Tue, 17 Mar 2015, Guertin, David S. wrote: >> When you changed idrange, it helps to remove SSSD cache, both on IPA >> master and IPA clients and restart SSSD. > >OK, I cleared the cache and restarted sssd with: > >sss_cache -E >systemctl restart sssd > >Still no change in the error: Could not convert objectSID >[S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID I don't think sss_cache -E removes cached idrange objects. You need to delete the databases in /var/lib/sss/db/. >This is RHEL 7 running sssd-1.12.2 and ipa-server-4.1.0. You mean RHEL 7.1, right? -- / Alexander Bokovoy From bpk678 at gmail.com Tue Mar 17 17:25:02 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 17 Mar 2015 13:25:02 -0400 Subject: [Freeipa-users] Unknown Client? In-Reply-To: References: <550845FD.7010604@astron.yasar.com.tr> Message-ID: <1426613102.9328.15.camel@desktop.bpk2.com> On Tue, 2015-03-17 at 18:07 +0100, Natxo Asenjo wrote: > > > On Tue, Mar 17, 2015 at 4:19 PM, Tevfik Ceydeliler > wrote: > Hi, > Altough I have this configuration in client .conf: > > ################################## > client 172.30.47.241 { > secret = 877909 > shortname = VodafonePinarsuAPNYeni1 > nastype = other > } > > client 172.30.47.242 { > secret = 877909 > shortname = VodafonePinarsuAPNYeni2 > nastype = other > } > > #################################### > > Why I get this error? > > ################################################################################################# > > Tue Mar 17 14:31:55 2015 : Error: Ignoring request to > authentication address * port 1812 from unknown client > 172.30.47.242 port 58312 > Tue Mar 17 14:32:01 2015 : Error: Ignoring request to > authentication address * port 1812 from unknown client > 172.30.47.241 port 6040 > > ################################################################################################# > > > I think you should post your question to the free*radius* mailing > list ;-) > > > -- > Groeten, > natxo yes, and when you do post to that list, give the output of "radiusd -X". see http://wiki.freeradius.org/guide/Troubleshooting From guertin at middlebury.edu Tue Mar 17 17:29:45 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 17 Mar 2015 17:29:45 +0000 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: <20150317172229.GT3878@redhat.com> References: <1426605513212.47081@middlebury.edu> <20150317154300.GQ3878@redhat.com> <3746481a704f4e68b6aea41daf62597f@greyhound.middlebury.edu> <20150317172229.GT3878@redhat.com> Message-ID: > I don't think sss_cache -E removes cached idrange objects. You need to > delete the databases in /var/lib/sss/db/. OK, I stopped sssd, removed everything in /var/lib/sss/db, and restarted sssd. Still no change -- I get the same error. > You mean RHEL 7.1, right? Yes, RHEL 7.1. David Guertin From dan at descript.co.uk Tue Mar 17 17:45:44 2015 From: dan at descript.co.uk (Dan) Date: Tue, 17 Mar 2015 17:45:44 +0000 (UTC) Subject: [Freeipa-users] =?utf-8?q?Using_FreeIPA_for_LDAP_authentication_i?= =?utf-8?q?n_3rd_party=09applications?= References: Message-ID: Thomas Raehalme writes: > > Hi, > > Previously we have used Atlassian Crowd as a source for user data in > various applications, both in-house built and proprietary such as JIRA > or Confluence. As we have deployed FreeIPA, I would like to start > using it as the identity source. Unfortunately using Kerberos is not > always possible so I am thinking about LDAP which often is an option > in 3rd party applicaitons. > > Anonymous access to the FreeIPA LDAP is enabled by default. Is it > possible to configure username/password to access the information? > Currently vSphere has a problem with anonymous access to LDAP not > working as intended. Ofcourse it would be nice to be able to restrict > access anyways. > > If using FreeIPA LDAP as the identity source, how should > authentication be handled? Is it possible to read the hash code for > passwords? Is it possible to authenticate against the LDAP service? > > Any advice appreciated! > > Best regards, > Thomas Hi, I have just successfully configured confluence and jira to use FreeIPA for its LDAP user directory. First, create an IPA user group for confluence-users and jira-users using the IPA dashboard. Then add a user to both of these groups. If you navigate to the confluence and jira dashboards and then in the "User Directories" settings menu add a "Generic Directory Server" and then use the following settings... Base DN: You can find this in your IPA config. Additional User DN: cn=users,cn=accounts Additional Group DN: cn=groups,cn=accounts LDAP Permissions: Read Only Advanced Settings - Defaults are fine for this section User Schema Settings User Object Class: inetorgperson User Object Filter: (objectclass=inetorgperson) User Name Attribute: uid User Name RDN Attribute: uid User First Name Attribute: givenName User Last Name Attribute: sn User Display Name Attribute: displayName User Email Attribute: mail User Password Attribute: userPassword User Password Encryption: SHA User Unique ID Attribute: ipaUniqueID Group Schema Settings Group Object Class ipausergroup Group Object Filter (objectclass=ipausergroup) Group Name Attribute cn Group Description description Membership Schema Settings Group Members Attribute: member User Membership Attribute: member (This is not used due to the next option) User the User Membership Attribute: (Ensure this is unchecked, it is not supported) Now save and test using the user who is in the groups created above. Hope this helps someone. Dan From bentech4you at gmail.com Tue Mar 17 18:19:45 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 17 Mar 2015 21:19:45 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: <20150317090922.GL9563@hendrix.arn.redhat.com> <20150317102759.GN9563@hendrix.arn.redhat.com> <20150317114506.GT9563@hendrix.arn.redhat.com> Message-ID: Hi all how can i fix this issue.? even i tried to trust add AD again. that too failed. from where i need to troubleshoot ? On Tue, Mar 17, 2015 at 3:02 PM, Ben .T.George wrote: > Hi > > i did kinit > > [root at kwtpocpbis01 sssd]# kinit -kt /etc/dirsrv/ds.keytab > kinit: Keytab contains no suitable keys for > host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL while getting initial > credentials > > > i destroyed and re-created. but still same > > > > On Tue, Mar 17, 2015 at 2:45 PM, Jakub Hrozek wrote: > >> On Tue, Mar 17, 2015 at 02:38:41PM +0300, Ben .T.George wrote: >> > here is separated logs: >> > >> > tail -f sssd_solaris.local.log >> >> Thank you, see inline: >> >> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_get_tgt_recv] >> > (0x0400): Child responded: 14 [Decrypt integrity check failed], expired >> on >> > [0] >> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] [sdap_kinit_done] >> > (0x0100): Could not get TGT: 14 [Bad address] >> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] >> [sdap_cli_kinit_done] >> > (0x0400): Cannot get a TGT: ret [1432158219](Authentication Failed) >> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] >> [fo_set_port_status] >> > (0x0100): Marking port 0 of server 'kwtpocpbis01.solaris.local' as 'not >> > working' >> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] >> [fo_set_port_status] >> > (0x0400): Marking port 0 of duplicate server >> 'kwtpocpbis01.solaris.local' >> > as 'not working' >> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] >> [sdap_handle_release] >> > (0x2000): Trace: sh[0x7f6b7d2c3140], connected[1], ops[(nil)], >> > ldap[0x7f6b7d265a00], destructor_lock[0], release_memory[0] >> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] >> > [remove_connection_callback] (0x4000): Successfully removed connection >> > callback. >> > (Tue Mar 17 14:35:45 2015) [sssd[be[solaris.local]]] >> > [check_online_callback] (0x0100): Backend returned: (3, 0, ) >> > [Internal Error (Success)] >> >> So it seems the keytab is wrong, you can also test the keytab validity >> with "kinit -k".. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Tue Mar 17 18:30:32 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 17 Mar 2015 20:30:32 +0200 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: References: <20150317090922.GL9563@hendrix.arn.redhat.com> <20150317102759.GN9563@hendrix.arn.redhat.com> <20150317114506.GT9563@hendrix.arn.redhat.com> Message-ID: <20150317183032.GU3878@redhat.com> On Tue, 17 Mar 2015, Ben .T.George wrote: >Hi > >i did kinit > >[root at kwtpocpbis01 sssd]# kinit -kt /etc/dirsrv/ds.keytab >kinit: Keytab contains no suitable keys for >host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL while getting initial >credentials > > >i destroyed and re-created. but still same What did you destroy? Why did you need to touch /etc/dirsrv/ds.keytab at all? It contains key for ldap/kwtpocpbis01.solaris.local at SOLARIS.LOCAL that your LDAP server is using. It has nothing to do with your host/... principal. If your sssd cannot authenticate against AD DC, it means trust is *not* working and anything else is fruitless unless you fix it. hat do you see in /var/log/httpd/error_log as result of dumping netr_LogonControl2Ex structure? Can you follow http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust and tell what do you see in /var/log/httpd/error_log as result of dumping netr_LogonControl2Ex structure? We went through this few weeks ago and I'm not seeing what did you broke. -- / Alexander Bokovoy From prasun.gera at gmail.com Tue Mar 17 18:41:37 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 17 Mar 2015 14:41:37 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server Message-ID: Hello, I installed the ipa-server on an RHEL 7.1 system, uninstalled it and reinstalled it with the same domain name as the first time. This somehow creates problems with ssh authentication on the server from external systems as well as from the server itself. Steps: 1. ipa-server-install 2. service sshd restart 3. kinit admin 4. ssh admin at localhost -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Tue Mar 17 18:54:13 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 17 Mar 2015 14:54:13 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: References: Message-ID: Sorry, the message got sent accidentally earlier before I could provide all the details. Version: 4.1.0 on RHEL 7.1 x86_64 Steps: 1. ipa-server-install 2. service sshd restart 3. kinit admin <- This always works 4. ssh admin at localhost <- This works for the first time, fails second time onwards ssh admin at host_addr from external system <- This also works the first time, fails second time onwards 5. ipa-server-install --uninstall 6. go to 1 The log messages in /var/log/messages point to [sssd[krb5_child[21029]]]: Decrypt integrity check failed at the point of the authentication failure sssd's log's have a lot of "No matching domain found for user" messages. /var/log/krb5kdc.log has a lot of error decoding FAST: for , Decrypt integrity check failed while handling ap-request armor The only ERROR I can see in /var/log/ipaserver-uninstall.log is pkidestroy : ERROR ....... subprocess.CalledProcessError: Command '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', ......returned non-zero exit status 6! It appears that the uninstall process is leaving some residual configuration behind which is conflicting with the subsequent installation with the same domain name Regards, Prasun On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera wrote: > Hello, > I installed the ipa-server on an RHEL 7.1 system, uninstalled it and > reinstalled it with the same domain name as the first time. This somehow > creates problems with ssh authentication on the server from external > systems as well as from the server itself. > > Steps: > 1. ipa-server-install > 2. service sshd restart > 3. kinit admin > 4. ssh admin at localhost > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Mar 17 19:14:44 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Mar 2015 15:14:44 -0400 Subject: [Freeipa-users] pki-tomcatd stopped responding? Won't restart? In-Reply-To: <55085282.4080100@gmail.com> References: <550849BE.2020308@gmail.com> <55085120.9010601@redhat.com> <55085282.4080100@gmail.com> Message-ID: <55087D24.7090401@redhat.com> On 03/17/2015 12:12 PM, Janelle wrote: > On 3/17/15 9:06 AM, Martin Kosek wrote: >> On 03/17/2015 04:35 PM, Janelle wrote: >>> Hello, >>> >>> I have a server - a master (has CA) - and it does not want to >>> restart after it >>> has been running sometime. pki-tomcatd keeps failing. It starts up >>> with these >>> errors, then adds a lot more. Maybe this might point you to >>> something that is >>> know or a place I can start looking? >>> >>> Any ideas? >>> ~J >>> >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'enableOCSP' to 'false' did not find a matching property. >>> >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' >>> did not find >>> a matching property. >>> >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did not >>> find a >>> matching property. >>> >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'ocspCacheSize' to '1000' did not find a matching property. >>> >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'ocspMinCacheEntryDuration' to '60' did not find a matching property. >>> >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'ocspMaxCacheEntryDuration' to '120' did not find a matching property. >>> >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'ocspTimeout' to '10' did not find a matching property. >>> >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'strictCiphers' to 'true' did not find a matching property. >>> Mar 17, 2015 8:21:03 AM >>> org.apache.catalina.startup.SetAllPropertiesRule begin >>> >>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>> property >>> 'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a >>> matching property. >>> >> CCing folks from Dogtag team to know about this issue. However, I >> think you >> will need to provide more information before we continue with issues >> - like >> version of FreeIPA, pki-ca packages, what system you are running it on >> (Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere >> (system and >> catalina.out logs are usually most interesting ones). > My bad -- > > CentOS 7 > FreeIPA 4.1.3 from mosek > > The strange thing is -- 12 other servers - 3 of which are CA masters > and no issues, > > ~J > Just some areas to check: - versions of dogtag package - versions of nss package -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From Dan.Watson at bcferries.com Tue Mar 17 19:28:27 2015 From: Dan.Watson at bcferries.com (Watson, Dan) Date: Tue, 17 Mar 2015 13:28:27 -0600 Subject: [Freeipa-users] Scripting reports from ipa? Message-ID: Hi all, Can anyone tell me how to script calls from the ipa server? I would like to be able to do something like "ipa group-show unix_admin" in a script, but I don't know how to pass Kerberos credentials that don't expire. I'd appreciate some help, thanks! Dan -------------- next part -------------- An HTML attachment was scrubbed... URL: From kperrin at doctorondemand.com Tue Mar 17 19:41:42 2015 From: kperrin at doctorondemand.com (Kim Perrin) Date: Tue, 17 Mar 2015 12:41:42 -0700 Subject: [Freeipa-users] Can't remove all replica records from ldap Message-ID: Hello all, For nearly 2 years I?ve been running a Freeipa 3 (currently 3.0.0-42) environment. We've had 2 masters since the start. Several replicas have had problems that required me to remove them. I?ve removed them all (except the very last one) by running ?ipa-server-install --uninstall? and then ipa-replica-manage clean-ruv?. The latest replica I tried to remove failed on both commands. On further inspection I see all the previous replicas have orphaned entries in the ldap db. How do I remove all the entries? (I?ve listed the entries below). Is this process safe (in what is currently a single ipa server environment)? Note, I?ve seen the one of the necessary LDIFs that can be ?run? to remove the entries -- I just don?t understand how to run an ldif. Relevant entries - kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s sub -b cn=config objectclass=nsds5replica Enter LDAP Password: dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config cn: replica nsDS5Flags: 1 objectClass: top objectClass: nsds5replica objectClass: extensibleobject nsDS5ReplicaType: 3 nsDS5ReplicaRoot: dc=companyz,dc=com nsds5ReplicaLegacyConsumer: off nsDS5ReplicaId: 4 nsDS5ReplicaBindDN: cn=replication manager,cn=config nsDS5ReplicaBindDN: krbprincipalname=ldap/noc2prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com nsDS5ReplicaBindDN: krbprincipalname=ldap/util1prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com nsDS5ReplicaBindDN: krbprincipalname=ldap/noc3prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com nsDS5ReplicaBindDN: krbprincipalname=ldap/noc4prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com nsState:: BAAAAAAAAABlZwhVAAAAAAAAAAAAAAAADgAAAAAAAAAFAAAAAAAAAA== nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3 nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com nsds5ReplicaChangeCount: 682699 nsds5replicareapactive: 0 kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b o=ipaca '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' -p 7389 -h noc1-prd Enter LDAP Password: dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 5317a449000000600000 nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 600000 550878b9000000600000 nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 470000 531ce069000300470000 nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 4c0000 53f659500004004c0000 nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 510000 531bf265000100510000 nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 560000 531a3256000400560000 nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 5b0000 531949920000005b0000 nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 0610000 5317a48a000100610000 o: ipaca nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} 550878ab nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389 } 00000000 -- and here is an example LDIF to remove the last record listed above - dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config changetype: modify replace: nsds5task nsds5task: CLEANRUV97 How do I ?run? this ldif? Thanks, Kim Perrin From janellenicole80 at gmail.com Tue Mar 17 19:41:57 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 17 Mar 2015 12:41:57 -0700 Subject: [Freeipa-users] pki-tomcatd stopped responding? Won't restart? In-Reply-To: <55087D24.7090401@redhat.com> References: <550849BE.2020308@gmail.com> <55085120.9010601@redhat.com> <55085282.4080100@gmail.com> <55087D24.7090401@redhat.com> Message-ID: <55088385.7010806@gmail.com> On 3/17/15 12:14 PM, Dmitri Pal wrote: > On 03/17/2015 12:12 PM, Janelle wrote: >> On 3/17/15 9:06 AM, Martin Kosek wrote: >>> On 03/17/2015 04:35 PM, Janelle wrote: >>>> Hello, >>>> >>>> I have a server - a master (has CA) - and it does not want to >>>> restart after it >>>> has been running sometime. pki-tomcatd keeps failing. It starts up >>>> with these >>>> errors, then adds a lot more. Maybe this might point you to >>>> something that is >>>> know or a place I can start looking? >>>> >>>> Any ideas? >>>> ~J >>>> >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'enableOCSP' to 'false' did not find a matching property. >>>> >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' >>>> did not find >>>> a matching property. >>>> >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did >>>> not find a >>>> matching property. >>>> >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'ocspCacheSize' to '1000' did not find a matching property. >>>> >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'ocspMinCacheEntryDuration' to '60' did not find a matching property. >>>> >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'ocspMaxCacheEntryDuration' to '120' did not find a matching property. >>>> >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'ocspTimeout' to '10' did not find a matching property. >>>> >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'strictCiphers' to 'true' did not find a matching property. >>>> Mar 17, 2015 8:21:03 AM >>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>> >>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>> property >>>> 'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a >>>> matching property. >>>> >>> CCing folks from Dogtag team to know about this issue. However, I >>> think you >>> will need to provide more information before we continue with issues >>> - like >>> version of FreeIPA, pki-ca packages, what system you are running it on >>> (Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere >>> (system and >>> catalina.out logs are usually most interesting ones). >> My bad -- >> >> CentOS 7 >> FreeIPA 4.1.3 from mosek >> >> The strange thing is -- 12 other servers - 3 of which are CA masters >> and no issues, >> >> ~J >> > Just some areas to check: > - versions of dogtag package > - versions of nss package > pki-tools-10.1.2-7.1.el7.centos.x86_64 dogtag-pki-server-theme-10.1.1-1.el7.centos.noarch pki-server-10.1.2-7.1.el7.centos.noarch krb5-pkinit-1.12.2-9.el7.centos.x86_64 pki-base-10.1.2-7.1.el7.centos.noarch pki-ca-10.1.2-7.1.el7.centos.noarch mod_nss-1.0.8-32.el7.x86_64 nss-sysinit-3.16.2.3-2.el7_0.x86_64 python-nss-0.15.0-1.el7.centos.x86_64 nss-softokn-3.16.2.3-1.el7_0.x86_64 nss-softokn-freebl-3.16.2.3-1.el7_0.x86_64 nss-tools-3.16.2.3-2.el7_0.x86_64 nss-util-3.16.2.3-1.el7_0.x86_64 nss-3.16.2.3-2.el7_0.x86_64 Anything? All the servers are identical. ~J From rcritten at redhat.com Tue Mar 17 21:06:41 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Mar 2015 17:06:41 -0400 Subject: [Freeipa-users] Can't remove all replica records from ldap In-Reply-To: References: Message-ID: <55089761.8080202@redhat.com> Kim Perrin wrote: > Hello all, > > For nearly 2 years I?ve been running a Freeipa 3 (currently 3.0.0-42) > environment. We've had 2 masters since the start. Several replicas > have had problems that required me to remove them. I?ve removed them > all (except the very last one) by running ?ipa-server-install > --uninstall? and then ipa-replica-manage clean-ruv?. The latest > replica I tried to remove failed on both commands. On further > inspection I see all the previous replicas have orphaned entries in > the ldap db. How do I remove all the entries? (I?ve listed the > entries below). Is this process safe (in what is currently a single > ipa server environment)? Note, I?ve seen the one of the necessary > LDIFs that can be ?run? to remove the entries -- I just don?t > understand how to run an ldif. You're skipping the step of ipa-replica-manage del ? That should do most of this cleanup for you. For the CA you use ipa-csreplica-manage. Unfortunately that utility lacks the RUV commands. rob > Relevant entries - > > kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s > sub -b cn=config objectclass=nsds5replica > Enter LDAP Password: > dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config > cn: replica > nsDS5Flags: 1 > objectClass: top > objectClass: nsds5replica > objectClass: extensibleobject > nsDS5ReplicaType: 3 > nsDS5ReplicaRoot: dc=companyz,dc=com > nsds5ReplicaLegacyConsumer: off > nsDS5ReplicaId: 4 > nsDS5ReplicaBindDN: cn=replication manager,cn=config > nsDS5ReplicaBindDN: > krbprincipalname=ldap/noc2prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com > nsDS5ReplicaBindDN: > krbprincipalname=ldap/util1prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com > nsDS5ReplicaBindDN: > krbprincipalname=ldap/noc3prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com > nsDS5ReplicaBindDN: > krbprincipalname=ldap/noc4prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com > nsState:: BAAAAAAAAABlZwhVAAAAAAAAAAAAAAAADgAAAAAAAAAFAAAAAAAAAA== > nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3 > nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com > nsds5ReplicaChangeCount: 682699 > nsds5replicareapactive: 0 > > kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b > o=ipaca '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' > -p 7389 -h noc1-prd > Enter LDAP Password: > dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca > objectClass: top > objectClass: nsTombstone > objectClass: extensibleobject > nsds50ruv: {replicageneration} 5317a449000000600000 > nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 > 600000 550878b9000000600000 > nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 > 470000 531ce069000300470000 > nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 > 4c0000 53f659500004004c0000 > nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 > 510000 531bf265000100510000 > nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 > 560000 531a3256000400560000 > nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 > 5b0000 531949920000005b0000 > nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 > 0610000 5317a48a000100610000 > o: ipaca > nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} > 550878ab > nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389 > } 00000000 > > -- and here is an example LDIF to remove the last record listed above - > > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > changetype: modify > replace: nsds5task > nsds5task: CLEANRUV97 That doesn't look right. It should look like: dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config changetype: add objectclass: top objectclass: extensibleObject replica-base-dn: dc=companyz,dc=com replica-id: 97 cn: clean 97 Be careful which RUV you remove. You only want to remove those that are no longer active. rob From rcritten at redhat.com Tue Mar 17 21:09:22 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 17 Mar 2015 17:09:22 -0400 Subject: [Freeipa-users] Scripting reports from ipa? In-Reply-To: References: Message-ID: <55089802.1080806@redhat.com> Watson, Dan wrote: > Hi all, > > > > Can anyone tell me how to script calls from the ipa server? I would like > to be able to do something like ?ipa group-show unix_admin? in a script, > but I don?t know how to pass Kerberos credentials that don?t expire. I think you want to use credentials in a keytab. Then, before you call your command, you can run: $ kinit -kt /path/to/keytab princ at REALM This can be wasteful because it always gets a new ticket. Depending on your distro, if you have gss-proxy, it can take care of a lot of those details for you. rob From kperrin at doctorondemand.com Tue Mar 17 21:52:13 2015 From: kperrin at doctorondemand.com (Kim Perrin) Date: Tue, 17 Mar 2015 14:52:13 -0700 Subject: [Freeipa-users] Can't remove all replica records from ldap In-Reply-To: <55089761.8080202@redhat.com> References: <55089761.8080202@redhat.com> Message-ID: Thanks for the reply Rob. On Tue, Mar 17, 2015 at 2:06 PM, Rob Crittenden wrote: > Kim Perrin wrote: >> Hello all, >> >> For nearly 2 years I?ve been running a Freeipa 3 (currently 3.0.0-42) >> environment. We've had 2 masters since the start. Several replicas >> have had problems that required me to remove them. I?ve removed them >> all (except the very last one) by running ?ipa-server-install >> --uninstall? and then ipa-replica-manage clean-ruv?. The latest >> replica I tried to remove failed on both commands. On further >> inspection I see all the previous replicas have orphaned entries in >> the ldap db. How do I remove all the entries? (I?ve listed the >> entries below). Is this process safe (in what is currently a single >> ipa server environment)? Note, I?ve seen the one of the necessary >> LDIFs that can be ?run? to remove the entries -- I just don?t >> understand how to run an ldif. > > You're skipping the step of ipa-replica-manage del ? > That should do most of this cleanup for you. I did run 'ipa-replica-manage del ' for all these as well. > > For the CA you use ipa-csreplica-manage. Unfortunately that utility > lacks the RUV commands. > > rob > >> Relevant entries - >> >> kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s >> sub -b cn=config objectclass=nsds5replica >> Enter LDAP Password: >> dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config >> cn: replica >> nsDS5Flags: 1 >> objectClass: top >> objectClass: nsds5replica >> objectClass: extensibleobject >> nsDS5ReplicaType: 3 >> nsDS5ReplicaRoot: dc=companyz,dc=com >> nsds5ReplicaLegacyConsumer: off >> nsDS5ReplicaId: 4 >> nsDS5ReplicaBindDN: cn=replication manager,cn=config >> nsDS5ReplicaBindDN: >> krbprincipalname=ldap/noc2prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >> nsDS5ReplicaBindDN: >> krbprincipalname=ldap/util1prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >> nsDS5ReplicaBindDN: >> krbprincipalname=ldap/noc3prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >> nsDS5ReplicaBindDN: >> krbprincipalname=ldap/noc4prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >> nsState:: BAAAAAAAAABlZwhVAAAAAAAAAAAAAAAADgAAAAAAAAAFAAAAAAAAAA== >> nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3 >> nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com >> nsds5ReplicaChangeCount: 682699 >> nsds5replicareapactive: 0 >> >> kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b >> o=ipaca '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' >> -p 7389 -h noc1-prd >> Enter LDAP Password: >> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca >> objectClass: top >> objectClass: nsTombstone >> objectClass: extensibleobject >> nsds50ruv: {replicageneration} 5317a449000000600000 >> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 >> 600000 550878b9000000600000 >> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 >> 470000 531ce069000300470000 >> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 >> 4c0000 53f659500004004c0000 >> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 >> 510000 531bf265000100510000 >> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 >> 560000 531a3256000400560000 >> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 >> 5b0000 531949920000005b0000 >> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 >> 0610000 5317a48a000100610000 >> o: ipaca >> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} >> 550878ab >> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389 >> } 00000000 >> >> -- and here is an example LDIF to remove the last record listed above - >> >> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config >> changetype: modify >> replace: nsds5task >> nsds5task: CLEANRUV97 > > That doesn't look right. It should look like: > > dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config > changetype: add > objectclass: top > objectclass: extensibleObject > replica-base-dn: dc=companyz,dc=com > replica-id: 97 > cn: clean 97 > > Be careful which RUV you remove. You only want to remove those that are > no longer active. Thanks for the additional spec on the LDIF, though I still don't understand how to run this. Is there somewhere you can point me to with example commands to run such LDIFs? -Kim > > rob From dpal at redhat.com Tue Mar 17 22:02:56 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Mar 2015 18:02:56 -0400 Subject: [Freeipa-users] pki-tomcatd stopped responding? Won't restart? In-Reply-To: <55088385.7010806@gmail.com> References: <550849BE.2020308@gmail.com> <55085120.9010601@redhat.com> <55085282.4080100@gmail.com> <55087D24.7090401@redhat.com> <55088385.7010806@gmail.com> Message-ID: <5508A490.8080504@redhat.com> On 03/17/2015 03:41 PM, Janelle wrote: > On 3/17/15 12:14 PM, Dmitri Pal wrote: >> On 03/17/2015 12:12 PM, Janelle wrote: >>> On 3/17/15 9:06 AM, Martin Kosek wrote: >>>> On 03/17/2015 04:35 PM, Janelle wrote: >>>>> Hello, >>>>> >>>>> I have a server - a master (has CA) - and it does not want to >>>>> restart after it >>>>> has been running sometime. pki-tomcatd keeps failing. It starts up >>>>> with these >>>>> errors, then adds a lot more. Maybe this might point you to >>>>> something that is >>>>> know or a place I can start looking? >>>>> >>>>> Any ideas? >>>>> ~J >>>>> >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'enableOCSP' to 'false' did not find a matching property. >>>>> >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'ocspResponderURL' to 'http://ipa-server.example.com:9080/ca/ocsp' >>>>> did not find >>>>> a matching property. >>>>> >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'ocspResponderCertNickname' to 'ocspSigningCert cert-pki-ca' did >>>>> not find a >>>>> matching property. >>>>> >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'ocspCacheSize' to '1000' did not find a matching property. >>>>> >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'ocspMinCacheEntryDuration' to '60' did not find a matching property. >>>>> >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'ocspMaxCacheEntryDuration' to '120' did not find a matching >>>>> property. >>>>> >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'ocspTimeout' to '10' did not find a matching property. >>>>> >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'strictCiphers' to 'true' did not find a matching property. >>>>> Mar 17, 2015 8:21:03 AM >>>>> org.apache.catalina.startup.SetAllPropertiesRule begin >>>>> >>>>> WARNING: [SetAllPropertiesRule]{Server/Service/Connector} Setting >>>>> property >>>>> 'sslOptions' to 'ssl2=true,ssl3=true,tls=true' did not find a >>>>> matching property. >>>>> >>>> CCing folks from Dogtag team to know about this issue. However, I >>>> think you >>>> will need to provide more information before we continue with >>>> issues - like >>>> version of FreeIPA, pki-ca packages, what system you are running it on >>>> (Fedora/RHEL/CentOS/...) and maybe whole logs pasted somewhere >>>> (system and >>>> catalina.out logs are usually most interesting ones). >>> My bad -- >>> >>> CentOS 7 >>> FreeIPA 4.1.3 from mosek >>> >>> The strange thing is -- 12 other servers - 3 of which are CA masters >>> and no issues, >>> >>> ~J >>> >> Just some areas to check: >> - versions of dogtag package >> - versions of nss package >> > pki-tools-10.1.2-7.1.el7.centos.x86_64 > dogtag-pki-server-theme-10.1.1-1.el7.centos.noarch > pki-server-10.1.2-7.1.el7.centos.noarch > krb5-pkinit-1.12.2-9.el7.centos.x86_64 > pki-base-10.1.2-7.1.el7.centos.noarch > pki-ca-10.1.2-7.1.el7.centos.noarch > > mod_nss-1.0.8-32.el7.x86_64 > nss-sysinit-3.16.2.3-2.el7_0.x86_64 > python-nss-0.15.0-1.el7.centos.x86_64 > nss-softokn-3.16.2.3-1.el7_0.x86_64 > nss-softokn-freebl-3.16.2.3-1.el7_0.x86_64 > nss-tools-3.16.2.3-2.el7_0.x86_64 > nss-util-3.16.2.3-1.el7_0.x86_64 > nss-3.16.2.3-2.el7_0.x86_64 > > Anything? All the servers are identical. > > ~J > No if they are same then it is not it. We need to find what is different on these machines. May be it is tomcat or tomcatjss that is different. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From Joshua.Gould at osumc.edu Tue Mar 17 22:08:04 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Tue, 17 Mar 2015 18:08:04 -0400 Subject: [Freeipa-users] sssd options ignored? Message-ID: I?ve been getting messages like these when I try the id command for a test AD domain user: (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_get_primary_name] (0x0400): Processing object farus at test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x0400): Processing user farus at test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x1000): Mapping user [farus at test.osuwmc] objectSID [S-1-5-21-226267946-722566613-1883572810-398410] to unix ID (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x0020): Failed to save user [adm-faru03 at test.osuwmc] Various sources all inicate that its a range issue with ldap_idmap_range_size. I?ve tried several large values of just ldap_idmap_range_size as well as adding ldap_idmap_range_min and ldap_idmap_range_range. All I can figure is that perhaps sssd is ignoring the values? Between changing values I did stop sssd, delete the cache and restart it. This is RHEL7 fully up to date. My SSSD shows 1.12.2-58. Here is my full sssd.conf. [domain/unix.test.osuwmc] debug_level = 9 subdomains_provider = ipa cache_credentials = True krb5_store_password_if_offline = True ipa_domain = unix.test.osuwmc id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = mid-ipa-vp01.unix.test.osuwmc chpass_provider = ipa ipa_server = mid-ipa-vp01.unix.test.osuwmc ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt #ldap_idmap_range_min = 2000 #ldap_idmap_range_size = 900000 #ldap_idmap_range_range = 3602000 ldap_idmap_range_size=1000000 ldap_id_mapping = True [sssd] services = nss, sudo, pam, ssh, pac config_file_version = 2 domains = unix.test.osuwmc [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] -------------- next part -------------- An HTML attachment was scrubbed... URL: From kperrin at doctorondemand.com Tue Mar 17 22:09:21 2015 From: kperrin at doctorondemand.com (Kim Perrin) Date: Tue, 17 Mar 2015 15:09:21 -0700 Subject: [Freeipa-users] Can't remove all replica records from ldap In-Reply-To: References: <55089761.8080202@redhat.com> Message-ID: On Tue, Mar 17, 2015 at 2:52 PM, Kim Perrin wrote: > Thanks for the reply Rob. > > On Tue, Mar 17, 2015 at 2:06 PM, Rob Crittenden wrote: >> Kim Perrin wrote: >>> Hello all, >>> >>> For nearly 2 years I?ve been running a Freeipa 3 (currently 3.0.0-42) >>> environment. We've had 2 masters since the start. Several replicas >>> have had problems that required me to remove them. I?ve removed them >>> all (except the very last one) by running ?ipa-server-install >>> --uninstall? and then ipa-replica-manage clean-ruv?. The latest >>> replica I tried to remove failed on both commands. On further >>> inspection I see all the previous replicas have orphaned entries in >>> the ldap db. How do I remove all the entries? (I?ve listed the >>> entries below). Is this process safe (in what is currently a single >>> ipa server environment)? Note, I?ve seen the one of the necessary >>> LDIFs that can be ?run? to remove the entries -- I just don?t >>> understand how to run an ldif. >> >> You're skipping the step of ipa-replica-manage del ? >> That should do most of this cleanup for you. > I did run 'ipa-replica-manage del ' for all these as well. > > >> >> For the CA you use ipa-csreplica-manage. Unfortunately that utility >> lacks the RUV commands. >> >> rob >> >>> Relevant entries - >>> >>> kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s >>> sub -b cn=config objectclass=nsds5replica >>> Enter LDAP Password: >>> dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config >>> cn: replica >>> nsDS5Flags: 1 >>> objectClass: top >>> objectClass: nsds5replica >>> objectClass: extensibleobject >>> nsDS5ReplicaType: 3 >>> nsDS5ReplicaRoot: dc=companyz,dc=com >>> nsds5ReplicaLegacyConsumer: off >>> nsDS5ReplicaId: 4 >>> nsDS5ReplicaBindDN: cn=replication manager,cn=config >>> nsDS5ReplicaBindDN: >>> krbprincipalname=ldap/noc2prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>> nsDS5ReplicaBindDN: >>> krbprincipalname=ldap/util1prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>> nsDS5ReplicaBindDN: >>> krbprincipalname=ldap/noc3prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>> nsDS5ReplicaBindDN: >>> krbprincipalname=ldap/noc4prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>> nsState:: BAAAAAAAAABlZwhVAAAAAAAAAAAAAAAADgAAAAAAAAAFAAAAAAAAAA== >>> nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3 >>> nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com >>> nsds5ReplicaChangeCount: 682699 >>> nsds5replicareapactive: 0 >>> >>> kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b >>> o=ipaca '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' >>> -p 7389 -h noc1-prd >>> Enter LDAP Password: >>> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca >>> objectClass: top >>> objectClass: nsTombstone >>> objectClass: extensibleobject >>> nsds50ruv: {replicageneration} 5317a449000000600000 >>> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 >>> 600000 550878b9000000600000 >>> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 >>> 470000 531ce069000300470000 >>> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 >>> 4c0000 53f659500004004c0000 >>> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 >>> 510000 531bf265000100510000 >>> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 >>> 560000 531a3256000400560000 >>> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 >>> 5b0000 531949920000005b0000 >>> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 >>> 0610000 5317a48a000100610000 >>> o: ipaca >>> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} >>> 550878ab >>> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389 >>> } 00000000 >>> >>> -- and here is an example LDIF to remove the last record listed above - >>> >>> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config >>> changetype: modify >>> replace: nsds5task >>> nsds5task: CLEANRUV97 >> >> That doesn't look right. It should look like: >> >> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config >> changetype: add >> objectclass: top >> objectclass: extensibleObject >> replica-base-dn: dc=companyz,dc=com >> replica-id: 97 >> cn: clean 97 >> >> Be careful which RUV you remove. You only want to remove those that are >> no longer active. > Thanks for the additional spec on the LDIF, though I still don't > understand how to run this. Is there somewhere you can point me to > with example commands to run such LDIFs? I figured out how to enter the ldif changes. > -Kim >> >> rob From kperrin at doctorondemand.com Tue Mar 17 22:27:41 2015 From: kperrin at doctorondemand.com (Kim Perrin) Date: Tue, 17 Mar 2015 15:27:41 -0700 Subject: [Freeipa-users] Can't remove all replica records from ldap In-Reply-To: References: <55089761.8080202@redhat.com> Message-ID: On Tue, Mar 17, 2015 at 3:09 PM, Kim Perrin wrote: > On Tue, Mar 17, 2015 at 2:52 PM, Kim Perrin wrote: >> Thanks for the reply Rob. >> >> On Tue, Mar 17, 2015 at 2:06 PM, Rob Crittenden wrote: >>> Kim Perrin wrote: >>>> Hello all, >>>> >>>> For nearly 2 years I?ve been running a Freeipa 3 (currently 3.0.0-42) >>>> environment. We've had 2 masters since the start. Several replicas >>>> have had problems that required me to remove them. I?ve removed them >>>> all (except the very last one) by running ?ipa-server-install >>>> --uninstall? and then ipa-replica-manage clean-ruv?. The latest >>>> replica I tried to remove failed on both commands. On further >>>> inspection I see all the previous replicas have orphaned entries in >>>> the ldap db. How do I remove all the entries? (I?ve listed the >>>> entries below). Is this process safe (in what is currently a single >>>> ipa server environment)? Note, I?ve seen the one of the necessary >>>> LDIFs that can be ?run? to remove the entries -- I just don?t >>>> understand how to run an ldif. >>> >>> You're skipping the step of ipa-replica-manage del ? >>> That should do most of this cleanup for you. >> I did run 'ipa-replica-manage del ' for all these as well. >> >> >>> >>> For the CA you use ipa-csreplica-manage. Unfortunately that utility >>> lacks the RUV commands. On using the 'ipa-csreplica-manage' command to remove the CAs - the del option failed with "Unable to delete replica noc3-prd.companyz.com: Can't contact LDAP server" And failed with the same response for a couple other listed servers as well. >>> >>> rob >>> >>>> Relevant entries - >>>> >>>> kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s >>>> sub -b cn=config objectclass=nsds5replica >>>> Enter LDAP Password: >>>> dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config >>>> cn: replica >>>> nsDS5Flags: 1 >>>> objectClass: top >>>> objectClass: nsds5replica >>>> objectClass: extensibleobject >>>> nsDS5ReplicaType: 3 >>>> nsDS5ReplicaRoot: dc=companyz,dc=com >>>> nsds5ReplicaLegacyConsumer: off >>>> nsDS5ReplicaId: 4 >>>> nsDS5ReplicaBindDN: cn=replication manager,cn=config >>>> nsDS5ReplicaBindDN: >>>> krbprincipalname=ldap/noc2prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>>> nsDS5ReplicaBindDN: >>>> krbprincipalname=ldap/util1prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>>> nsDS5ReplicaBindDN: >>>> krbprincipalname=ldap/noc3prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>>> nsDS5ReplicaBindDN: >>>> krbprincipalname=ldap/noc4prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>>> nsState:: BAAAAAAAAABlZwhVAAAAAAAAAAAAAAAADgAAAAAAAAAFAAAAAAAAAA== >>>> nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3 >>>> nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com >>>> nsds5ReplicaChangeCount: 682699 >>>> nsds5replicareapactive: 0 >>>> >>>> kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b >>>> o=ipaca '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' >>>> -p 7389 -h noc1-prd >>>> Enter LDAP Password: >>>> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca >>>> objectClass: top >>>> objectClass: nsTombstone >>>> objectClass: extensibleobject >>>> nsds50ruv: {replicageneration} 5317a449000000600000 >>>> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 >>>> 600000 550878b9000000600000 >>>> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 >>>> 470000 531ce069000300470000 >>>> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 >>>> 4c0000 53f659500004004c0000 >>>> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 >>>> 510000 531bf265000100510000 >>>> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 >>>> 560000 531a3256000400560000 >>>> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 >>>> 5b0000 531949920000005b0000 >>>> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 >>>> 0610000 5317a48a000100610000 >>>> o: ipaca >>>> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} >>>> 550878ab >>>> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389 >>>> } 00000000 >>>> >>>> -- and here is an example LDIF to remove the last record listed above - >>>> >>>> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config >>>> changetype: modify >>>> replace: nsds5task >>>> nsds5task: CLEANRUV97 >>> >>> That doesn't look right. It should look like: >>> >>> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config >>> changetype: add >>> objectclass: top >>> objectclass: extensibleObject >>> replica-base-dn: dc=companyz,dc=com >>> replica-id: 97 >>> cn: clean 97 >>> >>> Be careful which RUV you remove. You only want to remove those that are >>> no longer active. >> Thanks for the additional spec on the LDIF, though I still don't >> understand how to run this. Is there somewhere you can point me to >> with example commands to run such LDIFs? > I figured out how to enter the ldif changes. > >> -Kim >>> >>> rob From dpal at redhat.com Tue Mar 17 22:49:59 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 17 Mar 2015 18:49:59 -0400 Subject: [Freeipa-users] Can't remove all replica records from ldap In-Reply-To: References: <55089761.8080202@redhat.com> Message-ID: <5508AF97.50509@redhat.com> On 03/17/2015 06:27 PM, Kim Perrin wrote: > On Tue, Mar 17, 2015 at 3:09 PM, Kim Perrin wrote: >> On Tue, Mar 17, 2015 at 2:52 PM, Kim Perrin wrote: >>> Thanks for the reply Rob. >>> >>> On Tue, Mar 17, 2015 at 2:06 PM, Rob Crittenden wrote: >>>> Kim Perrin wrote: >>>>> Hello all, >>>>> >>>>> For nearly 2 years I?ve been running a Freeipa 3 (currently 3.0.0-42) >>>>> environment. We've had 2 masters since the start. Several replicas >>>>> have had problems that required me to remove them. I?ve removed them >>>>> all (except the very last one) by running ?ipa-server-install >>>>> --uninstall? and then ipa-replica-manage clean-ruv?. The latest >>>>> replica I tried to remove failed on both commands. On further >>>>> inspection I see all the previous replicas have orphaned entries in >>>>> the ldap db. How do I remove all the entries? (I?ve listed the >>>>> entries below). Is this process safe (in what is currently a single >>>>> ipa server environment)? Note, I?ve seen the one of the necessary >>>>> LDIFs that can be ?run? to remove the entries -- I just don?t >>>>> understand how to run an ldif. >>>> You're skipping the step of ipa-replica-manage del ? >>>> That should do most of this cleanup for you. >>> I did run 'ipa-replica-manage del ' for all these as well. >>> >>> >>>> For the CA you use ipa-csreplica-manage. Unfortunately that utility >>>> lacks the RUV commands. > On using the 'ipa-csreplica-manage' command to remove the CAs - the > del option failed with > "Unable to delete replica noc3-prd.companyz.com: Can't contact LDAP server" > And failed with the same response for a couple other listed servers as well. Yes, you would have to clean it manually. >>>> rob >>>> >>>>> Relevant entries - >>>>> >>>>> kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -s >>>>> sub -b cn=config objectclass=nsds5replica >>>>> Enter LDAP Password: >>>>> dn: cn=replica,cn=dc\3Dcompanyz\2Cdc\3Dcom,cn=mapping tree,cn=config >>>>> cn: replica >>>>> nsDS5Flags: 1 >>>>> objectClass: top >>>>> objectClass: nsds5replica >>>>> objectClass: extensibleobject >>>>> nsDS5ReplicaType: 3 >>>>> nsDS5ReplicaRoot: dc=companyz,dc=com >>>>> nsds5ReplicaLegacyConsumer: off >>>>> nsDS5ReplicaId: 4 >>>>> nsDS5ReplicaBindDN: cn=replication manager,cn=config >>>>> nsDS5ReplicaBindDN: >>>>> krbprincipalname=ldap/noc2prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>>>> nsDS5ReplicaBindDN: >>>>> krbprincipalname=ldap/util1prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>>>> nsDS5ReplicaBindDN: >>>>> krbprincipalname=ldap/noc3prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>>>> nsDS5ReplicaBindDN: >>>>> krbprincipalname=ldap/noc4prd.companyz.com at COMPANYZ.COM,cn=services,cn=accounts,dc=companyz,dc=com >>>>> nsState:: BAAAAAAAAABlZwhVAAAAAAAAAAAAAAAADgAAAAAAAAAFAAAAAAAAAA== >>>>> nsDS5ReplicaName: 2767660e-9e5611e2-b7b6a070-c35ad5d3 >>>>> nsds5ReplicaAbortCleanRUV: 14:dc=companyz,dc=com >>>>> nsds5ReplicaChangeCount: 682699 >>>>> nsds5replicareapactive: 0 >>>>> >>>>> kperrin at noc1-prd:~# ldapsearch -xLLL -D "cn=directory manager" -W -b >>>>> o=ipaca '(&(nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff)(objectclass=nstombstone))' >>>>> -p 7389 -h noc1-prd >>>>> Enter LDAP Password: >>>>> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca >>>>> objectClass: top >>>>> objectClass: nsTombstone >>>>> objectClass: extensibleobject >>>>> nsds50ruv: {replicageneration} 5317a449000000600000 >>>>> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 >>>>> 600000 550878b9000000600000 >>>>> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 >>>>> 470000 531ce069000300470000 >>>>> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 >>>>> 4c0000 53f659500004004c0000 >>>>> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 >>>>> 510000 531bf265000100510000 >>>>> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 >>>>> 560000 531a3256000400560000 >>>>> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 >>>>> 5b0000 531949920000005b0000 >>>>> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 >>>>> 0610000 5317a48a000100610000 >>>>> o: ipaca >>>>> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} >>>>> 550878ab >>>>> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} >>>>> 00000000 >>>>> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} >>>>> 00000000 >>>>> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} >>>>> 00000000 >>>>> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} >>>>> 00000000 >>>>> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} >>>>> 00000000 >>>>> nsruvReplicaLastModified: {replica 97 ldap://util1-prd.companyz.com:7389 >>>>> } 00000000 >>>>> >>>>> -- and here is an example LDIF to remove the last record listed above - >>>>> >>>>> dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config >>>>> changetype: modify >>>>> replace: nsds5task >>>>> nsds5task: CLEANRUV97 >>>> That doesn't look right. It should look like: >>>> >>>> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config >>>> changetype: add >>>> objectclass: top >>>> objectclass: extensibleObject >>>> replica-base-dn: dc=companyz,dc=com >>>> replica-id: 97 >>>> cn: clean 97 >>>> >>>> Be careful which RUV you remove. You only want to remove those that are >>>> no longer active. >>> Thanks for the additional spec on the LDIF, though I still don't >>> understand how to run this. Is there somewhere you can point me to >>> with example commands to run such LDIFs? >> I figured out how to enter the ldif changes. >> >>> -Kim >>>> rob -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From Joshua.Gould at osumc.edu Wed Mar 18 00:30:23 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Tue, 17 Mar 2015 20:30:23 -0400 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: <1426605513212.47081@middlebury.edu> References: <1426605513212.47081@middlebury.edu> Message-ID: David, I had a very similar issue which I posted to the list today. Your notes indirectly helped me. I think we both had two ends to the same puzzle. It looks like the range for your AD domain defined in ?ipa idrange-find ?all? needs to match whats in for your domain in /etc/sssd/sssd.conf. For your example. Under the [domain/CSNS.MIDDLEBURY.EDU] should have ldap_idmap_range_min = 1824600000 ldap_idmap_range_size = 2000000 Setting these two identically let me resolve AD ID?s with the id command. Hopefully this works for you too. From: , "David S." Date: Tuesday, March 17, 2015 at 11:18 AM To: "freeipa-users at redhat.com" Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID We have a trust relationship established between our AD domain and our IPA domain, and AD users can be found on the IPA server with id and getent passwd. When a user tries to SSH to the IPA server with AD credentials, the logs show: (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x0400): Processing user guertin-s (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_save_user] (0x1000): Mapping user [guertin-s] objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to unix ID (Tue Mar 17 10:45:54 2015) [sssd[be[middlebury.edu]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID It seems that this is a problem with the ID range, but I can't see where the problem is. We increased the default ranges of 200,000 to 2,000,000, which I would think should be able to handle a RID of 245906: # ipa idrange-find --all ---------------- 2 ranges matched ---------------- dn: cn=CSNS.MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=e du Range name: CSNS.MIDDLEBURY.EDU_id_range First Posix ID of the range: 1824600000 Number of IDs in the range: 2000000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range iparangetyperaw: ipa-local objectclass: top, ipaIDrange, ipaDomainIDRange dn: cn=MIDDLEBURY.EDU_id_range,cn=ranges,cn=etc,dc=csns,dc=middlebury,dc=edu Range name: MIDDLEBURY.EDU_id_range First Posix ID of the range: 10000 Number of IDs in the range: 2000000 Domain SID of the trusted domain: S-1-5-21-1983215674-46037090-646806464 Range type: Active Directory trust range with POSIX attributes iparangetyperaw: ipa-ad-trust-posix objectclass: ipatrustedaddomainrange, ipaIDrange ---------------------------- Number of entries returned 2 ---------------------------- But the error remains. What am I missing? David Guertin From guertin at middlebury.edu Wed Mar 18 02:03:33 2015 From: guertin at middlebury.edu (David Guertin) Date: Tue, 17 Mar 2015 22:03:33 -0400 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: References: <1426605513212.47081@middlebury.edu> Message-ID: <5508DCF5.5070100@middlebury.edu> On 03/17/2015 08:30 PM, Gould, Joshua wrote: > It looks like the range for your AD domain defined in ?ipa idrange-find > ?all? needs to match whats in for your domain in /etc/sssd/sssd.conf. > > For your example. Under the [domain/CSNS.MIDDLEBURY.EDU] should have > > ldap_idmap_range_min = 1824600000 > ldap_idmap_range_size = 2000000 > > Setting these two identically let me resolve AD ID?s with the id command. > Hopefully this works for you too. Bingo! Thank you! That was indeed the solution. I needed to set the ID range in both places, and now users can log in. David Guertin From Joshua.Gould at osumc.edu Wed Mar 18 02:29:07 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Tue, 17 Mar 2015 22:29:07 -0400 Subject: [Freeipa-users] sssd options ignored? Message-ID: I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need to match whats in ipa idrange-find --all for the AD domain. # ipa idrange-mod --base-id=100000 --range-size=900000 --rid-base=0 Range name: TEST.OSUWMC_id_range ---------------------------------------- Modified ID range "TEST.OSUWMC_id_range" ---------------------------------------- Range name: TEST.OSUWMC_id_range First Posix ID of the range: 100000 Number of IDs in the range: 900000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810 Range type: Active Directory domain range /etc/sssd/sssd.conf: [domain/test.osuwmc] ldap_idmap_range_min = 100000 ldap_idmap_range_size = 900000 From: , Joshua Gould Date: Tuesday, March 17, 2015 at 6:08 PM To: "freeipa-users at redhat.com" Subject: [Freeipa-users] sssd options ignored? I?ve been getting messages like these when I try the id command for a test AD domain user: (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_get_primary_name] (0x0400): Processing object farus at test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x0400): Processing user farus at test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x1000): Mapping user [farus at test.osuwmc] objectSID [S-1-5-21-226267946-722566613-1883572810-398410] to unix ID (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID [S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x0020): Failed to save user [adm-faru03 at test.osuwmc] Various sources all inicate that its a range issue with ldap_idmap_range_size. I?ve tried several large values of just ldap_idmap_range_size as well as adding ldap_idmap_range_min and ldap_idmap_range_range. All I can figure is that perhaps sssd is ignoring the values? Between changing values I did stop sssd, delete the cache and restart it. This is RHEL7 fully up to date. My SSSD shows 1.12.2-58. Here is my full sssd.conf. [domain/unix.test.osuwmc] debug_level = 9 subdomains_provider = ipa cache_credentials = True krb5_store_password_if_offline = True ipa_domain = unix.test.osuwmc id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = mid-ipa-vp01.unix.test.osuwmc chpass_provider = ipa ipa_server = mid-ipa-vp01.unix.test.osuwmc ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt #ldap_idmap_range_min = 2000 #ldap_idmap_range_size = 900000 #ldap_idmap_range_range = 3602000 ldap_idmap_range_size=1000000 ldap_id_mapping = True [sssd] services = nss, sudo, pam, ssh, pac config_file_version = 2 domains = unix.test.osuwmc [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] From bentech4you at gmail.com Wed Mar 18 05:12:35 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 08:12:35 +0300 Subject: [Freeipa-users] Only one AD user can able to login to IPA server In-Reply-To: <20150317183032.GU3878@redhat.com> References: <20150317090922.GL9563@hendrix.arn.redhat.com> <20150317102759.GN9563@hendrix.arn.redhat.com> <20150317114506.GT9563@hendrix.arn.redhat.com> <20150317183032.GU3878@redhat.com> Message-ID: Dear Alex i already enable debugging and this is what i am getting on error_log while running : ipa trust-add --type=ad infra.com --admin Administrator --password [Wed Mar 18 08:10:17.470460 2015] [:error] [pid 15176] ipa: DEBUG: WSGI wsgi_dispatch.__call__: [Wed Mar 18 08:10:17.470571 2015] [:error] [pid 15176] ipa: DEBUG: WSGI jsonserver_session.__call__: [Wed Mar 18 08:10:17.470821 2015] [:error] [pid 15176] ipa: DEBUG: found session cookie_id = 15b334c24b28c1e228c1e843efb0bf86 [Wed Mar 18 08:10:17.471493 2015] [:error] [pid 15176] ipa: DEBUG: found session data in cache with id=15b334c24b28c1e228c1e843efb0bf86 [Wed Mar 18 08:10:17.471613 2015] [:error] [pid 15176] ipa: DEBUG: jsonserver_session.__call__: session_id=15b334c24b28c1e228c1e843efb0bf86 start_timestamp=2015-03-18T08:06:18 access_timestamp=2015-03-18T08:10:17 expiration_timestamp=2015-03-18T08:26:18 [Wed Mar 18 08:10:17.471698 2015] [:error] [pid 15176] ipa: DEBUG: storing ccache data into file "/var/run/ipa_memcached/krbcc_15176" [Wed Mar 18 08:10:17.472404 2015] [:error] [pid 15176] ipa: DEBUG: get_credential_times: principal=HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL, authtime=03/17/15 16:04:12, starttime=03/18/15 08:06:17, endtime=03/18/15 16:04:09, renew_till=01/01/70 03:00:00 [Wed Mar 18 08:10:17.472610 2015] [:error] [pid 15176] ipa: DEBUG: get_credential_times: principal=HTTP/kwtpocpbis01.solaris.local at SOLARIS.LOCAL, authtime=03/17/15 16:04:12, starttime=03/18/15 08:06:17, endtime=03/18/15 16:04:09, renew_till=01/01/70 03:00:00 [Wed Mar 18 08:10:17.472829 2015] [:error] [pid 15176] ipa: DEBUG: KRB5_CCache FILE:/var/run/ipa_memcached/krbcc_15176 endtime=1426683849 (03/18/15 16:04:09) [Wed Mar 18 08:10:17.472978 2015] [:error] [pid 15176] ipa: DEBUG: set_session_expiration_time: duration_type=inactivity_timeout duration=1200 max_age=1426683549 expiration=1426656617.47 (2015-03-18T08:30:17) [Wed Mar 18 08:10:18.484137 2015] [:error] [pid 15176] ipa: DEBUG: Created connection context.ldap2 [Wed Mar 18 08:10:18.484255 2015] [:error] [pid 15176] ipa: DEBUG: WSGI jsonserver.__call__: [Wed Mar 18 08:10:18.484330 2015] [:error] [pid 15176] ipa: DEBUG: WSGI WSGIExecutioner.__call__: [Wed Mar 18 08:10:18.484919 2015] [:error] [pid 15176] ipa: DEBUG: raw: trust_add(u'infra.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', all=False, raw=False, version=u'2.113') [Wed Mar 18 08:10:18.485210 2015] [:error] [pid 15176] ipa: DEBUG: trust_add(u'infra.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', all=False, raw=False, version=u'2.113') 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:kwtpocpbis01.solaris.local[,] s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7f5a6441f040 s4_tevent: Added timed event "composite_trigger": 0x7f5a6424ed80 s4_tevent: Added timed event "composite_trigger": 0x7f5a644b7f60 s4_tevent: Running timer event 0x7f5a6424ed80 "composite_trigger" s4_tevent: Destroying timer event 0x7f5a644b7f60 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface ens160 ip=172.16.107.244 bcast=172.16.107.255 netmask=255.255.255.0 added interface ens160 ip=172.16.107.244 bcast=172.16.107.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7f5a6424ed80 "composite_trigger" s4_tevent: Added timed event "connect_multi_timer": 0x7f5a64421500 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f5a64095f20 s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5a64095f20 s4_tevent: Destroying timer event 0x7f5a64421500 "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": 0x7f5a6449da70 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f5a640c4c30 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f5a640c4c30 s4_tevent: Destroying timer event 0x7f5a6449da70 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for admin at SOLARIS.LOCAL will expire in 5885 secs s4_tevent: Added timed event "tevent_req_timedout": 0x7f5a644a23f0 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f5a640c4c30 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f5a640c4c30 s4_tevent: Destroying timer event 0x7f5a644a23f0 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7f5a6441f040 "dcerpc_connect_timeout_handler" Using binding ncacn_np:kwtpocpbis01.solaris.local s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7f5a64030f60 s4_tevent: Added timed event "composite_trigger": 0x7f5a64360af0 s4_tevent: Added timed event "composite_trigger": 0x7f5a64491b50 s4_tevent: Running timer event 0x7f5a64360af0 "composite_trigger" s4_tevent: Destroying timer event 0x7f5a64491b50 "composite_trigger" Mapped to DCERPC endpoint \pipe\lsarpc added interface ens160 ip=172.16.107.244 bcast=172.16.107.255 netmask=255.255.255.0 added interface ens160 ip=172.16.107.244 bcast=172.16.107.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7f5a64360af0 "composite_trigger" s4_tevent: Added timed event "connect_multi_timer": 0x7f5a640e6a40 s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f5a6402ae00 s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5a6402ae00 s4_tevent: Destroying timer event 0x7f5a640e6a40 "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": 0x7f5a644cde60 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f5a64240aa0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f5a64240aa0 s4_tevent: Destroying timer event 0x7f5a644cde60 "tevent_req_timedout" Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 GSSAPI credentials for admin at SOLARIS.LOCAL will expire in 5885 secs s4_tevent: Added timed event "tevent_req_timedout": 0x7f5a64093a80 s4_tevent: Schedule immediate event "tevent_queue_immediate_trigger": 0x7f5a64240aa0 s4_tevent: Run immediate event "tevent_queue_immediate_trigger": 0x7f5a64240aa0 s4_tevent: Destroying timer event 0x7f5a64093a80 "tevent_req_timedout" s4_tevent: Destroying timer event 0x7f5a64030f60 "dcerpc_connect_timeout_handler" Using binding ncacn_ip_tcp:kwtpocpbis01.solaris.local[,] s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7f5a64240170 s4_tevent: Added timed event "dcerpc_connect_timeout_handler": 0x7f5a644d29c0 s4_tevent: Added timed event "composite_trigger": 0x7f5a643df470 s4_tevent: Added timed event "composite_trigger": 0x7f5a643fc900 s4_tevent: Running timer event 0x7f5a643df470 "composite_trigger" s4_tevent: Destroying timer event 0x7f5a643fc900 "composite_trigger" Mapped to DCERPC endpoint 135 added interface ens160 ip=172.16.107.244 bcast=172.16.107.255 netmask=255.255.255.0 added interface ens160 ip=172.16.107.244 bcast=172.16.107.255 netmask=255.255.255.0 s4_tevent: Ending timer event 0x7f5a643df470 "composite_trigger" s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7f5a6448b6d0 s4_tevent: Destroying timer event 0x7f5a6448b6d0 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f5a645345f0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5a645345f0 s4_tevent: Destroying timer event 0x7f5a644d29c0 "dcerpc_connect_timeout_handler" epm_Map: struct epm_Map in: struct epm_Map object : * object : 00000000-0000-0000-0000-000000000000 map_tower : * map_tower: struct epm_twr_t tower_length : 0x0000004b (75) tower: struct epm_tower num_floors : 0x0005 (5) floors: ARRAY(5) floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_UUID (13) lhs_data : DATA_BLOB length=18 [0000] 78 57 34 12 34 12 CD AB EF 00 01 23 45 67 89 AB xW4.4... ...#Eg.. [0010] 00 00 .. rhs : union epm_rhs(case 13) uuid: struct epm_rhs_uuid unknown : DATA_BLOB length=2 [0000] 00 00 .. floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_UUID (13) lhs_data : DATA_BLOB length=18 [0000] 04 5D 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 .]...... ....+.H` [0010] 02 00 .. rhs : union epm_rhs(case 13) uuid: struct epm_rhs_uuid unknown : DATA_BLOB length=2 [0000] 00 00 .. floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_NCACN (11) lhs_data : DATA_BLOB length=0 rhs : union epm_rhs(case 11) ncacn: struct epm_rhs_ncacn minor_version : 0x0000 (0) floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_TCP (7) lhs_data : DATA_BLOB length=0 rhs : union epm_rhs(case 7) tcp: struct epm_rhs_tcp port : 0x0000 (0) floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_IP (9) lhs_data : DATA_BLOB length=0 rhs : union epm_rhs(case 9) ip: struct epm_rhs_ip ipaddr : 0.0.0.0 entry_handle : * entry_handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 max_towers : 0x00000001 (1) rpc request data: [0000] 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0010] 00 00 00 00 02 00 00 00 4B 00 00 00 4B 00 00 00 ........ K...K... [0020] 05 00 13 00 0D 78 57 34 12 34 12 CD AB EF 00 01 .....xW4 .4...... [0030] 23 45 67 89 AB 00 00 02 00 00 00 13 00 0D 04 5D #Eg..... .......] [0040] 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 02 00 ........ ..+.H`.. [0050] 02 00 00 00 01 00 0B 02 00 00 00 01 00 07 02 00 ........ ........ [0060] 00 00 01 00 09 04 00 00 00 00 00 00 00 00 00 00 ........ ........ [0070] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0080] 01 00 00 00 .... s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7f5a640d3b10 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7f5a64437b50 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7f5a640d3b10 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7f5a640d3b10 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7f5a640d3b10 s4_tevent: Destroying timer event 0x7f5a64437b50 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f5a64076bc0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5a64076bc0 epm_Map: struct epm_Map out: struct epm_Map entry_handle : * entry_handle: struct policy_handle handle_type : 0x00000000 (0) uuid : 00000000-0000-0000-0000-000000000000 num_towers : * num_towers : 0x00000001 (1) towers: ARRAY(1) towers: struct epm_twr_p_t twr : * twr: struct epm_twr_t tower_length : 0x0000004b (75) tower: struct epm_tower num_floors : 0x0005 (5) floors: ARRAY(5) floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_UUID (13) lhs_data : DATA_BLOB length=18 [0000] 78 57 34 12 34 12 CD AB EF 00 01 23 45 67 89 AB xW4.4... ...#Eg.. [0010] 00 00 .. rhs : union epm_rhs(case 13) uuid: struct epm_rhs_uuid unknown : DATA_BLOB length=2 [0000] 00 00 .. floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_UUID (13) lhs_data : DATA_BLOB length=18 [0000] 04 5D 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 .]...... ....+.H` [0010] 02 00 .. rhs : union epm_rhs(case 13) uuid: struct epm_rhs_uuid unknown : DATA_BLOB length=2 [0000] 00 00 .. floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_NCACN (11) lhs_data : DATA_BLOB length=0 rhs : union epm_rhs(case 11) ncacn: struct epm_rhs_ncacn minor_version : 0x0000 (0) floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_TCP (7) lhs_data : DATA_BLOB length=0 rhs : union epm_rhs(case 7) tcp: struct epm_rhs_tcp port : 0x0400 (1024) floors: struct epm_floor lhs: struct epm_lhs protocol : EPM_PROTOCOL_IP (9) lhs_data : DATA_BLOB length=0 rhs : union epm_rhs(case 9) ip: struct epm_rhs_ip ipaddr : 172.16.107.244 result : 0x00000000 (0) rpc reply data: [0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0010] 00 00 00 00 01 00 00 00 01 00 00 00 00 00 00 00 ........ ........ [0020] 01 00 00 00 03 00 00 00 4B 00 00 00 4B 00 00 00 ........ K...K... [0030] 05 00 13 00 0D 78 57 34 12 34 12 CD AB EF 00 01 .....xW4 .4...... [0040] 23 45 67 89 AB 00 00 02 00 00 00 13 00 0D 04 5D #Eg..... .......] [0050] 88 8A EB 1C C9 11 9F E8 08 00 2B 10 48 60 02 00 ........ ..+.H`.. [0060] 02 00 00 00 01 00 0B 02 00 00 00 01 00 07 02 00 ........ ........ [0070] 04 00 01 00 09 04 00 AC 10 6B F4 00 00 00 00 00 ........ .k...... Mapped to DCERPC endpoint 1024 added interface ens160 ip=172.16.107.244 bcast=172.16.107.255 netmask=255.255.255.0 added interface ens160 ip=172.16.107.244 bcast=172.16.107.255 netmask=255.255.255.0 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7f5a644d4990 s4_tevent: Destroying timer event 0x7f5a644d4990 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f5a64076bc0 s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5a64076bc0 s4_tevent: Destroying timer event 0x7f5a64240170 "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": 0x7f5a642b3a00 s4_tevent: Added timed event "dcerpc_timeout_handler": 0x7f5a64093810 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7f5a642b3a00 s4_tevent: Schedule immediate event "dcerpc_io_trigger": 0x7f5a642b3a00 s4_tevent: Run immediate event "dcerpc_io_trigger": 0x7f5a642b3a00 rpc fault: WERR_ACCESS_DENIED s4_tevent: Destroying timer event 0x7f5a64093810 "dcerpc_timeout_handler" s4_tevent: Schedule immediate event "tevent_req_trigger": 0x7f5a64093560 s4_tevent: Run immediate event "tevent_req_trigger": 0x7f5a64093560 [Wed Mar 18 08:10:19.541586 2015] [:error] [pid 15176] ipa: DEBUG: WSGI wsgi_execute PublicError: Traceback (most recent call last): [Wed Mar 18 08:10:19.541617 2015] [:error] [pid 15176] File "/usr/lib/python2.7/site-packages/ipaserver/rpcserver.py", line 349, in wsgi_execute [Wed Mar 18 08:10:19.541624 2015] [:error] [pid 15176] result = self.Command[name](*args, **options) [Wed Mar 18 08:10:19.541627 2015] [:error] [pid 15176] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 439, in __call__ [Wed Mar 18 08:10:19.541631 2015] [:error] [pid 15176] ret = self.run(*args, **options) [Wed Mar 18 08:10:19.541634 2015] [:error] [pid 15176] File "/usr/lib/python2.7/site-packages/ipalib/frontend.py", line 754, in run [Wed Mar 18 08:10:19.541637 2015] [:error] [pid 15176] return self.execute(*args, **options) [Wed Mar 18 08:10:19.541640 2015] [:error] [pid 15176] File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line 472, in execute [Wed Mar 18 08:10:19.541643 2015] [:error] [pid 15176] full_join = self.validate_options(*keys, **options) [Wed Mar 18 08:10:19.541646 2015] [:error] [pid 15176] File "/usr/lib/python2.7/site-packages/ipalib/plugins/trust.py", line 582, in validate_options [Wed Mar 18 08:10:19.541650 2015] [:error] [pid 15176] self.trustinstance = ipaserver.dcerpc.TrustDomainJoins(self.api) [Wed Mar 18 08:10:19.541656 2015] [:error] [pid 15176] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1127, in __init__ [Wed Mar 18 08:10:19.541660 2015] [:error] [pid 15176] self.__populate_local_domain() [Wed Mar 18 08:10:19.541663 2015] [:error] [pid 15176] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 1136, in __populate_local_domain [Wed Mar 18 08:10:19.541666 2015] [:error] [pid 15176] ld.retrieve(installutils.get_fqdn()) [Wed Mar 18 08:10:19.541669 2015] [:error] [pid 15176] File "/usr/lib/python2.7/site-packages/ipaserver/dcerpc.py", line 826, in retrieve [Wed Mar 18 08:10:19.541672 2015] [:error] [pid 15176] raise assess_dcerpc_exception(num=num, message=message) [Wed Mar 18 08:10:19.541675 2015] [:error] [pid 15176] ACIError: Insufficient access: Gettext('CIFS server denied your credentials', domain='ipa', localedir=None) [Wed Mar 18 08:10:19.541678 2015] [:error] [pid 15176] [Wed Mar 18 08:10:19.541970 2015] [:error] [pid 15176] ipa: INFO: [jsonserver_session] admin at SOLARIS.LOCAL: trust_add(u'infra.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', all=False, raw=False, version=u'2.113'): ACIError [Wed Mar 18 08:10:19.542594 2015] [:error] [pid 15176] ipa: DEBUG: reading ccache data from file "/var/run/ipa_memcached/krbcc_15176" [Wed Mar 18 08:10:19.542847 2015] [:error] [pid 15176] ipa: DEBUG: store session: session_id=15b334c24b28c1e228c1e843efb0bf86 start_timestamp=2015-03-18T08:06:18 access_timestamp=2015-03-18T08:10:19 expiration_timestamp=2015-03-18T08:30:17 [Wed Mar 18 08:10:19.545479 2015] [:error] [pid 15176] ipa: DEBUG: Destroyed connection context.ldap2 On Tue, Mar 17, 2015 at 9:30 PM, Alexander Bokovoy wrote: > On Tue, 17 Mar 2015, Ben .T.George wrote: > >> Hi >> >> i did kinit >> >> [root at kwtpocpbis01 sssd]# kinit -kt /etc/dirsrv/ds.keytab >> kinit: Keytab contains no suitable keys for >> host/kwtpocpbis01.solaris.local at SOLARIS.LOCAL while getting initial >> credentials >> >> >> i destroyed and re-created. but still same >> > What did you destroy? > kdestroy was the command i was talking about > > Why did you need to touch /etc/dirsrv/ds.keytab at all? It contains key > for ldap/kwtpocpbis01.solaris.local at SOLARIS.LOCAL that your LDAP server > is using. It has nothing to do with your host/... principal. > > If your sssd cannot authenticate against AD DC, it means trust is *not* > working and anything else is fruitless unless you fix it. > hat do you see > in /var/log/httpd/error_log as result of dumping netr_LogonControl2Ex > structure? > > > Can you follow > http://www.freeipa.org/page/Active_Directory_trust_setup#Debugging_trust > and tell what do you see in /var/log/httpd/error_log as result of > dumping netr_LogonControl2Ex structure? > > We went through this few weeks ago and I'm not seeing what did you > broke. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 18 06:23:09 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 08:23:09 +0200 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: <3746481a704f4e68b6aea41daf62597f@greyhound.middlebury.edu> References: <1426605513212.47081@middlebury.edu> <20150317154300.GQ3878@redhat.com> <3746481a704f4e68b6aea41daf62597f@greyhound.middlebury.edu> Message-ID: <20150318062309.GV3878@redhat.com> On Tue, 17 Mar 2015, Guertin, David S. wrote: >> When you changed idrange, it helps to remove SSSD cache, both on IPA >> master and IPA clients and restart SSSD. > >OK, I cleared the cache and restarted sssd with: > >sss_cache -E >systemctl restart sssd > >Still no change in the error: Could not convert objectSID [S-1-5-21-1983215674-46037090-646806464-245906] to a UNIX ID > >FWIW, here's my sssd.conf: > >[domain/csns.middlebury.edu] >cache_credentials = True >krb5_store_password_if_offline = True >ipa_domain = csns.middlebury.edu >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = genet.csns.middlebury.edu >chpass_provider = ipa >ipa_server = genet.csns.middlebury.edu >ipa_server_mode = True >ldap_tls_cacert = /etc/ipa/ca.crt > >[domain/middlebury.edu] >id_provider = ad >auth_provider = ad >chpass_provider = ad >access_provider = ad >debug_level = 10 Wait, why do you have middlebury.edu section here at all? If middlebury is trusted by csns.middlebury.edu, you should not have a separate [domain/middlebury.edu] section at all! The whole idea is that SSSD discovers all domains over trusted forest link path automatically. -- / Alexander Bokovoy From lryznaro at redhat.com Wed Mar 18 06:24:53 2015 From: lryznaro at redhat.com (Lenka Ryznarova) Date: Wed, 18 Mar 2015 07:24:53 +0100 Subject: [Freeipa-users] freeIPA.org wiki changes Message-ID: <1426659893.6705.2.camel@dhcp130-146.brq.redhat.com> Hi, I've made a few changes (and hopefully improvements) to freeipa.org wiki concerning mainly test contribution and documentation. These changes namely consist of: - Contribute page [1] - the structure is a bit different (for previous version see [2]), and there is a new paragraph Testing that is supposed to point contributors to other pages they might need for testing or contributions - new Contribute/Tests page [3] - contains basic workflow for contributing new tests and/or test plans - Testing Documentation item on Documentation page [4] - so far pretty much empty, but it is necessary for the test contribution workflow - new Test plan template page [5] - supposed to make contributor's work a tiny bit easier, the template is based on existing test plan documentation already on the wiki If there is anything unclear or you have any questions, comments, suggestions or reservations, please let me know. Please note that this is still work in progress, our goal is to improve the wiki so that it is easily readable for users as well as contributors etc. Any feedback concerning any part of the wiki is welcome. Lenka Ryznarova [1] http://www.freeipa.org/page/Contribute [2] http://www.freeipa.org/index.php?title=Contribute&oldid=10811 [3] http://www.freeipa.org/page/Contribute/Tests [4] http://www.freeipa.org/page/Documentation#Testing_Documentation [5] http://www.freeipa.org/page/Test_plan_template From abokovoy at redhat.com Wed Mar 18 06:26:03 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 08:26:03 +0200 Subject: [Freeipa-users] sssd options ignored? In-Reply-To: References: Message-ID: <20150318062603.GW3878@redhat.com> On Tue, 17 Mar 2015, Gould, Joshua wrote: >I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need >to match whats in ipa idrange-find --all for the AD domain. > ># ipa idrange-mod --base-id=100000 --range-size=900000 --rid-base=0 >Range name: TEST.OSUWMC_id_range >---------------------------------------- >Modified ID range "TEST.OSUWMC_id_range" >---------------------------------------- >Range name: TEST.OSUWMC_id_range >First Posix ID of the range: 100000 >Number of IDs in the range: 900000 >First RID of the corresponding RID range: 0 >Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810 >Range type: Active Directory domain range > > >/etc/sssd/sssd.conf: >[domain/test.osuwmc] >ldap_idmap_range_min = 100000 >ldap_idmap_range_size = 900000 There is something completely broken here. You *shouldn't* need to add a separate domain section for any of the domains coming over the forest trust link path _at_all_. SSSD automatically derives all needed parameters for them via its IPA providers for the primary IPA domain. Jakub, what is going on? > > > > > >From: , Joshua Gould >Date: Tuesday, March 17, 2015 at 6:08 PM >To: "freeipa-users at redhat.com" >Subject: [Freeipa-users] sssd options ignored? > > >I?ve been getting messages like these when I try the id command for a test >AD domain user: > >(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] >[sdap_get_primary_name] (0x0400): Processing object farus at test.osuwmc >(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] >(0x0400): Processing user farus at test.osuwmc >(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] >(0x1000): Mapping user [farus at test.osuwmc] objectSID >[S-1-5-21-226267946-722566613-1883572810-398410] to unix ID >(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] >[sdap_idmap_sid_to_unix] (0x0080): Could not convert objectSID >[S-1-5-21-226267946-722566613-1883572810-398410] to a UNIX ID >(Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] >(0x0020): Failed to save user [adm-faru03 at test.osuwmc] > > >Various sources all inicate that its a range issue with >ldap_idmap_range_size. I?ve tried several large values of just >ldap_idmap_range_size as well as adding ldap_idmap_range_min and >ldap_idmap_range_range. All I can figure is that perhaps sssd is ignoring > the values? Between changing values I did stop sssd, delete the cache and >restart it. This is RHEL7 fully up to date. My SSSD shows 1.12.2-58. > >Here is my full sssd.conf. > >[domain/unix.test.osuwmc] >debug_level = 9 >subdomains_provider = ipa >cache_credentials = True >krb5_store_password_if_offline = True >ipa_domain = unix.test.osuwmc >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = mid-ipa-vp01.unix.test.osuwmc >chpass_provider = ipa >ipa_server = mid-ipa-vp01.unix.test.osuwmc >ipa_server_mode = True >ldap_tls_cacert = /etc/ipa/ca.crt >#ldap_idmap_range_min = 2000 >#ldap_idmap_range_size = 900000 >#ldap_idmap_range_range = 3602000 >ldap_idmap_range_size=1000000 >ldap_id_mapping = True > >[sssd] >services = nss, sudo, pam, ssh, pac >config_file_version = 2 > > >domains = unix.test.osuwmc >[nss] >homedir_substring = /home > >[pam] > >[sudo] > >[autofs] > >[ssh] > >[pac] > >[ifp] > > > > >-- >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 -- / Alexander Bokovoy From jhrozek at redhat.com Wed Mar 18 07:41:30 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 18 Mar 2015 08:41:30 +0100 Subject: [Freeipa-users] sssd options ignored? In-Reply-To: <20150318062603.GW3878@redhat.com> References: <20150318062603.GW3878@redhat.com> Message-ID: <20150318074130.GD4854@hendrix.redhat.com> On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote: > On Tue, 17 Mar 2015, Gould, Joshua wrote: > >I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need > >to match whats in ipa idrange-find --all for the AD domain. > > > ># ipa idrange-mod --base-id=100000 --range-size=900000 --rid-base=0 > >Range name: TEST.OSUWMC_id_range > >---------------------------------------- > >Modified ID range "TEST.OSUWMC_id_range" > >---------------------------------------- > >Range name: TEST.OSUWMC_id_range > >First Posix ID of the range: 100000 > >Number of IDs in the range: 900000 > >First RID of the corresponding RID range: 0 > >Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810 > >Range type: Active Directory domain range > > > > > >/etc/sssd/sssd.conf: > >[domain/test.osuwmc] > >ldap_idmap_range_min = 100000 > >ldap_idmap_range_size = 900000 > There is something completely broken here. Yes, the sssd.conf configuration :-) SSSD will not even read this sssd.conf section, it is just ignored. The subdomains are mostly auto-configured, just with several exceptions (like subdomain_homedir) where we read the subdomain config from the main domain config. > You *shouldn't* need to add a > separate domain section for any of the domains coming over the forest > trust link path _at_all_. SSSD automatically derives all needed > parameters for them via its IPA providers for the primary IPA domain. > > Jakub, what is going on? I would prefer if also Sumit can add his opinon since he authored the ID mapping code. But here's how I see it - since you use 'external ID mapping', then you should just rely on the properties from the server. The only action to take on the client side is to purge the sssd cache on the clients if the ID mapping changes, because currently SSSD doesn't handle ID changes. And because gracefully handling ID changes is not planned even for the next version (1.13), I wonder if it makes sense to add a warning after idrange-mod command is run that it's preferable to clean the caches? We might also want to add some kind of simple CLI tool (sss_delcache?) so that admins don't have to learn where are the caches stored. From sbose at redhat.com Wed Mar 18 07:55:00 2015 From: sbose at redhat.com (Sumit Bose) Date: Wed, 18 Mar 2015 08:55:00 +0100 Subject: [Freeipa-users] sssd options ignored? In-Reply-To: <20150318074130.GD4854@hendrix.redhat.com> References: <20150318062603.GW3878@redhat.com> <20150318074130.GD4854@hendrix.redhat.com> Message-ID: <20150318075500.GE9952@p.redhat.com> On Wed, Mar 18, 2015 at 08:41:30AM +0100, Jakub Hrozek wrote: > On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote: > > On Tue, 17 Mar 2015, Gould, Joshua wrote: > > >I figured out that the ldap_idmap_range_min and ldap_idmap_range_size need > > >to match whats in ipa idrange-find --all for the AD domain. > > > > > ># ipa idrange-mod --base-id=100000 --range-size=900000 --rid-base=0 > > >Range name: TEST.OSUWMC_id_range > > >---------------------------------------- > > >Modified ID range "TEST.OSUWMC_id_range" > > >---------------------------------------- > > >Range name: TEST.OSUWMC_id_range > > >First Posix ID of the range: 100000 > > >Number of IDs in the range: 900000 > > >First RID of the corresponding RID range: 0 > > >Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810 > > >Range type: Active Directory domain range > > > > > > > > >/etc/sssd/sssd.conf: > > >[domain/test.osuwmc] > > >ldap_idmap_range_min = 100000 > > >ldap_idmap_range_size = 900000 > > There is something completely broken here. > > Yes, the sssd.conf configuration :-) > > SSSD will not even read this sssd.conf section, it is just ignored. The > subdomains are mostly auto-configured, just with several exceptions > (like subdomain_homedir) where we read the subdomain config from the > main domain config. > > > You *shouldn't* need to add a > > separate domain section for any of the domains coming over the forest > > trust link path _at_all_. SSSD automatically derives all needed > > parameters for them via its IPA providers for the primary IPA domain. > > > > Jakub, what is going on? > > I would prefer if also Sumit can add his opinon since he authored the ID > mapping code. as Alexander said in the other thread, only the IPA domain should be configured if you want to use IPA and trust. AD domains will be discovered and ranges will be configured on the IPA server side and IPA clients will get all information about trusted AD domains from the IPA server. So, please remove the section for the AD completely from sssd.conf. HTH bye, Sumit > > But here's how I see it - since you use 'external ID mapping', then you > should just rely on the properties from the server. The only action to > take on the client side is to purge the sssd cache on the clients if the > ID mapping changes, because currently SSSD doesn't handle ID changes. > > And because gracefully handling ID changes is not planned even for the > next version (1.13), I wonder if it makes sense to add a warning after > idrange-mod command is run that it's preferable to clean the caches? We > might also want to add some kind of simple CLI tool (sss_delcache?) so > that admins don't have to learn where are the caches stored. > > -- > 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 ovalousek at vendavo.com Wed Mar 18 08:11:20 2015 From: ovalousek at vendavo.com (Ondrej Valousek) Date: Wed, 18 Mar 2015 08:11:20 +0000 Subject: [Freeipa-users] MIT Kerbetos & Samba 4 Message-ID: Hi list (Simo ;) Sorry for the bit off-topic question, but do we know whether Samba4 can now share the same KDC with IPA server so that it can act as AD DC? I heard MIT KDC functionality would have to be extended, but not sure whether this is on the roundmap or not. Many thanks, Ondrej Sent from my command line -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Wed Mar 18 08:19:18 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 11:19:18 +0300 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", Message-ID: Hi i am getting "ipa: ERROR: CIFS server communication error: code "-1073741771"," while doing [root at kwtpocpbis02 ~]# ipa trust-add --type=ad infra.com --admin Administrator --password Active Directory domain administrator's password: ipa: ERROR: CIFS server communication error: code "-1073741771", message "NT_STATUS_OBJECT_NAME_COLLISION" (both may be "None") i am using centos 7 and IPA 4.1.2 IPA Server [root at kwtpocpbis02 ~]# host kwtpocpbis02.solaris.com kwtpocpbis02.solaris.com has address 172.16.107.135 [root at kwtpocpbis02 ~]# host 172.16.107.135 135.107.16.172.in-addr.arpa domain name pointer kwtpocpbis02.solaris.com. AD [root at kwtpocpbis02 ~]# host 172.16.107.250 250.107.16.172.in-addr.arpa domain name pointer kwtipaad001.infra.com. [root at kwtpocpbis02 ~]# host kwtipaad001.infra.com kwtipaad001.infra.com has address 172.16.107.250 debugging is enabled and this is i am getting on error_log INFO: Current debug levels: all: 11 tdb: 11 printdrivers: 11 lanman: 11 smb: 11 rpc_parse: 11 rpc_srv: 11 rpc_cli: 11 passdb: 11 sam: 11 auth: 11 winbind: 11 vfs: 11 idmap: 11 quota: 11 acls: 11 locking: 11 msdfs: 11 dmapi: 11 registry: 11 scavenger: 11 dns: 11 ldb: 11 pm_process() returned Yes GENSEC backend 'gssapi_spnego' registered GENSEC backend 'gssapi_krb5' registered GENSEC backend 'gssapi_krb5_sasl' registered GENSEC backend 'sasl-DIGEST-MD5' registered GENSEC backend 'schannel' registered GENSEC backend 'spnego' registered GENSEC backend 'ntlmssp' registered Using binding ncacn_np:kwtpocpbis02.solaris.com[,] Mapped to DCERPC endpoint \pipe\lsarpc added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 netmask=255.255.255.0 added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 netmask=255.255.255.0 Socket options: SO_KEEPALIVE = 0 SO_REUSEADDR = 0 SO_BROADCAST = 0 TCP_NODELAY = 1 TCP_KEEPCNT = 9 TCP_KEEPIDLE = 7200 TCP_KEEPINTVL = 75 IPTOS_LOWDELAY = 0 IPTOS_THROUGHPUT = 0 SO_REUSEPORT = 0 SO_SNDBUF = 663430 SO_RCVBUF = 261942 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 Starting GENSEC mechanism spnego Starting GENSEC submechanism gssapi_krb5 Ticket in credentials cache for admin at SOLARIS.COM will expire in 81540 secs gensec_gssapi: NO credentials were delegated GSSAPI Connection will be cryptographically sealed 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 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 ........ 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 rpc reply data: [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ .....U.4 [0010] 2E 0F 00 00 00 00 00 00 ........ rpc request data: [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ .....U.4 [0010] 2E 0F 00 00 0C 00 ...... 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 rpc reply data: [0000] 00 00 02 00 0C 00 00 00 0E 00 10 00 04 00 02 00 ........ ........ [0010] 16 00 18 00 08 00 02 00 16 00 18 00 0C 00 02 00 ........ ........ [0020] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... .0l..... [0030] 10 00 02 00 08 00 00 00 00 00 00 00 07 00 00 00 ........ ........ [0040] 53 00 4F 00 4C 00 41 00 52 00 49 00 53 00 00 00 S.O.L.A. R.I.S... [0050] 0C 00 00 00 00 00 00 00 0B 00 00 00 73 00 6F 00 ........ ....s.o. [0060] 6C 00 61 00 72 00 69 00 73 00 2E 00 63 00 6F 00 l.a.r.i. s...c.o. [0070] 6D 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 m....... ........ [0080] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. r.i.s... [0090] 63 00 6F 00 6D 00 00 00 04 00 00 00 01 04 00 00 c.o.m... ........ [00A0] 00 00 00 05 15 00 00 00 5F 89 A9 B4 86 30 6C 9D ........ _....0l. [00B0] B4 09 10 02 00 00 00 00 ........ rpc request data: [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ .....U.4 [0010] 2E 0F 00 00 06 00 ...... 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 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: 11 tdb: 11 printdrivers: 11 lanman: 11 smb: 11 rpc_parse: 11 rpc_srv: 11 rpc_cli: 11 passdb: 11 sam: 11 auth: 11 winbind: 11 vfs: 11 idmap: 11 quota: 11 acls: 11 locking: 11 msdfs: 11 dmapi: 11 registry: 11 scavenger: 11 dns: 11 ldb: 11 pm_process() returned Yes added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 netmask=255.255.255.0 added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 netmask=255.255.255.0 added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 netmask=255.255.255.0 added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 netmask=255.255.255.0 finddcs: searching for a DC by DNS domain infra.com finddcs: looking for SRV records for _ldap._tcp.infra.com ads_dns_lookup_srv: 1 records returned in the answer section. ads_dns_parse_rr_srv: Parsed kwtipaad001.infra.com [0, 100, 389] Addrs = 172.16.107.250 at 389/kwtipaad001 finddcs: DNS SRV response 0 at '172.16.107.250' finddcs: performing CLDAP query on 172.16.107.250 &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX command : LOGON_SAM_LOGON_RESPONSE_EX (23) sbz : 0x0000 (0) server_type : 0x000033fd (13309) 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 1: 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 : 2b3fba2e-3635-4e27-90d3-be555b96aea1 forest : 'infra.com' dns_domain : 'infra.com' pdc_dns_name : 'kwtipaad001.infra.com' domain_name : 'INFRA' pdc_name : 'KWTIPAAD001' 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 172.16.107.250 with server_type=0x000033fd 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: 11 tdb: 11 printdrivers: 11 lanman: 11 smb: 11 rpc_parse: 11 rpc_srv: 11 rpc_cli: 11 passdb: 11 sam: 11 auth: 11 winbind: 11 vfs: 11 idmap: 11 quota: 11 acls: 11 locking: 11 msdfs: 11 dmapi: 11 registry: 11 scavenger: 11 dns: 11 ldb: 11 pm_process() returned Yes Using binding ncacn_np:kwtipaad001.infra.com[,] Mapped to DCERPC endpoint \pipe\lsarpc added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 netmask=255.255.255.0 added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 netmask=255.255.255.0 Socket options: SO_KEEPALIVE = 0 SO_REUSEADDR = 0 SO_BROADCAST = 0 TCP_NODELAY = 1 TCP_KEEPCNT = 9 TCP_KEEPIDLE = 7200 TCP_KEEPINTVL = 75 IPTOS_LOWDELAY = 0 IPTOS_THROUGHPUT = 0 SO_REUSEPORT = 0 SO_SNDBUF = 23080 SO_RCVBUF = 87380 SO_SNDLOWAT = 1 SO_RCVLOWAT = 1 SO_SNDTIMEO = 0 SO_RCVTIMEO = 0 TCP_QUICKACK = 1 TCP_DEFER_ACCEPT = 0 Starting GENSEC mechanism spnego Starting GENSEC submechanism 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 : 0x0007 (7) DomainNameMaxLen : 0x0007 (7) DomainName : * DomainName : 'SOLARIS' WorkstationLen : 0x0007 (7) WorkstationMaxLen : 0x0007 (7) Workstation : * Workstation : 'SOLARIS' smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL 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 smb_signing_sign_pdu: sent SMB signature of [0000] 42 53 52 53 50 59 4C 20 BSRSPYL smb_signing_activate: user_session_key [0000] 23 27 C0 93 E7 C8 7F B9 47 A9 FD 91 F7 73 10 6E #'...... G....s.n smb_signing_activate: NULL response_data smb_signing_md5: sequence number 1 smb_signing_check_pdu: seq 1: got good SMB signature of [0000] 71 D6 FE AD D8 76 9E B9 q....v.. smb_signing_md5: sequence number 2 smb_signing_sign_pdu: sent SMB signature of [0000] 07 24 9E 31 C2 C8 37 9D .$.1..7. smb_signing_md5: sequence number 3 smb_signing_check_pdu: seq 3: got good SMB signature of [0000] 7E F4 97 77 31 32 74 F7 ~..w12t. smb_signing_md5: sequence number 4 smb_signing_sign_pdu: sent SMB signature of [0000] 26 96 4E B8 AF B2 5C EB &.N...\. smb_signing_md5: sequence number 5 smb_signing_check_pdu: seq 5: got good SMB signature of [0000] 77 EE BD 92 63 7A F7 86 w...cz.. 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 smb_signing_md5: sequence number 6 smb_signing_sign_pdu: sent SMB signature of [0000] F2 49 18 60 8B 96 22 FB .I.`..". smb_signing_md5: sequence number 7 smb_signing_check_pdu: seq 7: got good SMB signature of [0000] 74 CA 84 E8 F0 2B 5F 93 t....+_. 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 ........ 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 smb_signing_md5: sequence number 8 smb_signing_sign_pdu: sent SMB signature of [0000] AC 94 11 10 43 F9 1B A8 ....C... smb_signing_md5: sequence number 9 smb_signing_check_pdu: seq 9: got good SMB signature of [0000] CD B6 5D F7 6A 95 70 B9 ..].j.p. rpc reply data: [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. [0010] B3 FE D1 C1 00 00 00 00 ........ rpc request data: [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. [0010] B3 FE D1 C1 0C 00 ...... 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 smb_signing_md5: sequence number 10 smb_signing_sign_pdu: sent SMB signature of [0000] 32 2D 66 66 C2 FD C7 AF 2-ff.... smb_signing_md5: sequence number 11 smb_signing_check_pdu: seq 11: got good SMB signature of [0000] DD 3C 1D 35 CD 94 09 88 .<.5.... rpc reply data: [0000] 00 00 02 00 0C 00 00 00 0A 00 0C 00 04 00 02 00 ........ ........ [0010] 12 00 14 00 08 00 02 00 12 00 14 00 0C 00 02 00 ........ ........ [0020] 2E BA 3F 2B 35 36 27 4E 90 D3 BE 55 5B 96 AE A1 ..?+56'N ...U[... [0030] 10 00 02 00 06 00 00 00 00 00 00 00 05 00 00 00 ........ ........ [0040] 49 00 4E 00 46 00 52 00 41 00 00 00 0A 00 00 00 I.N.F.R. A....... [0050] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ i.n.f.r. [0060] 61 00 2E 00 63 00 6F 00 6D 00 00 00 0A 00 00 00 a...c.o. m....... [0070] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ i.n.f.r. [0080] 61 00 2E 00 63 00 6F 00 6D 00 00 00 04 00 00 00 a...c.o. m....... [0090] 01 04 00 00 00 00 00 05 15 00 00 00 05 CF 66 0B ........ ......f. [00A0] 52 91 25 EF 02 4B 1B D6 00 00 00 00 R.%..K.. .... rpc request data: [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. [0010] B3 FE D1 C1 06 00 ...... 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 smb_signing_md5: sequence number 12 smb_signing_sign_pdu: sent SMB signature of [0000] 62 FA 51 B6 49 8C 2D 73 b.Q.I.-s smb_signing_md5: sequence number 13 smb_signing_check_pdu: seq 13: got good SMB signature of [0000] 4A E8 4A EB 69 A4 EC 5D J.J.i..] rpc reply data: [0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ ........ rpc request data: [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. [0010] B3 FE D1 C1 16 00 16 00 00 00 02 00 0B 00 00 00 ........ ........ [0020] 00 00 00 00 0B 00 00 00 73 00 6F 00 6C 00 61 00 ........ s.o.l.a. [0030] 72 00 69 00 73 00 2E 00 63 00 6F 00 6D 00 08 00 r.i.s... c.o.m... 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 smb_signing_md5: sequence number 14 smb_signing_sign_pdu: sent SMB signature of [0000] 85 6D ED 23 EB 6A 9B 42 .m.#.j.B smb_signing_md5: sequence number 15 smb_signing_check_pdu: seq 15: got good SMB signature of [0000] E3 52 D1 8E FB BD DE 9C .R...... rpc reply data: [0000] 00 00 00 00 34 00 00 C0 ....4... rpc request data: [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. [0010] B3 FE D1 C1 16 00 18 00 00 00 02 00 0E 00 10 00 ........ ........ [0020] 04 00 02 00 08 00 02 00 03 00 00 00 02 00 00 00 ........ ........ [0030] 00 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 ........ ........ [0040] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. r.i.s... [0050] 63 00 6F 00 6D 00 00 00 08 00 00 00 00 00 00 00 c.o.m... ........ [0060] 07 00 00 00 53 00 4F 00 4C 00 41 00 52 00 49 00 ....S.O. L.A.R.I. [0070] 53 00 00 00 04 00 00 00 01 04 00 00 00 00 00 05 S....... ........ [0080] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... .0l..... [0090] 40 04 00 00 0C 00 02 00 40 04 00 00 F3 EB B4 CA @....... @....... [00A0] 99 BB 60 76 9A 51 FD BE 16 00 59 56 14 B8 A4 AF ..`v.Q.. ..YV.... [00B0] 00 4F 6E C5 95 EE 75 2E BA EF 21 CF 26 B1 9E C5 .On...u. ..!.&... [00C0] 29 54 05 06 1F EB BF 90 4A F1 88 37 D3 AE B9 FB )T...... J..7.... [00D0] A0 A4 B7 C5 2A B2 38 60 3D 59 B1 14 19 5D 30 64 ....*.8` =Y...]0d [00E0] F2 82 6D DC 03 CC 19 CC D5 D1 ED A7 63 40 F0 72 ..m..... ....c at .r [00F0] E5 80 B2 FB 3E 06 95 45 76 19 0A C8 5A 83 5B 00 ....>..E v...Z.[. [0100] C7 39 27 83 43 88 98 0F 2B C5 75 D8 4C 3B 61 18 .9'.C... +.u.L;a. [0110] CF F6 1F BB 31 A9 CD FF 57 F5 EF 0B 81 B9 5F 7E ....1... W....._~ [0120] 1B 3E 00 11 92 CB 92 8C 29 D5 90 31 B7 39 B1 31 .>...... )..1.9.1 [0130] 7C C3 0C C8 E5 D0 51 AA 20 D2 A2 39 C1 52 ED 91 |.....Q. ..9.R.. [0140] 70 27 2F 7C EB 05 8F 91 AA EB 26 13 07 2C FA 62 p'/|.... ..&..,.b [0150] C3 CB 79 DD B5 DA EC 3E 78 9A D8 A1 AE 64 3C 7F ..y....> x....d<. [0160] BB CE 06 48 9A 56 6E 22 FC 6D 78 59 63 2F B8 51 ...H.Vn" .mxYc/.Q [0170] D6 81 91 1D 54 94 2D C7 69 75 B3 E4 F1 77 93 EF ....T.-. iu...w.. [0180] BB 3E 0E 80 D7 D4 DD A0 DA 3C 10 51 64 5A AA A7 .>...... .<.QdZ.. [0190] CB AE CE DA BF F8 03 10 5C DB 64 9F 32 94 D4 F2 ........ \.d.2... [01A0] 67 1F D4 E7 4E 4F A3 DA A3 1A 24 FC 47 C9 73 FD g...NO.. ..$.G.s. [01B0] AB 70 CB 34 BE 3B FF 12 A9 A3 DA 31 72 41 07 C0 .p.4.;.. ...1rA.. [01C0] 27 4A FF ED F8 C7 39 FD B6 87 2E 01 F9 0E 27 9F 'J....9. ......'. [01D0] 22 12 6B B3 A8 27 CB 86 A1 9D 8F D0 7A 70 97 66 ".k..'.. ....zp.f [01E0] D4 AD 10 FF BF 88 3A 14 A4 D6 74 E4 17 79 E2 79 ......:. ..t..y.y [01F0] A7 41 0D 2D A6 09 C5 DF 9F 85 C4 C8 E8 28 10 23 .A.-.... .....(.# [0200] B2 87 1C 8F 82 3E EC F6 BB 51 49 CD EF CF D3 95 .....>.. .QI..... [0210] 76 E5 A1 7B 6D 42 81 04 81 8D C0 9C 82 13 14 A1 v..{mB.. ........ [0220] 1C 8B B1 ED 94 D7 41 EF 43 04 49 A5 35 17 17 51 ......A. C.I.5..Q [0230] C1 D0 27 13 93 6F CF 15 15 E6 C3 32 4D 85 9D E7 ..'..o.. ...2M... [0240] FF E7 36 D9 3F CE 35 A2 DC 2D AB 06 1E 84 2B 6E ..6.?.5. .-....+n [0250] 3C D9 BF 3E 01 9E 6B 8B 5D 8D F3 98 F0 AA 1B 62 <..>..k. ]......b [0260] C4 BD D9 CB F6 F8 77 60 09 3C F1 C7 9B FA BB 6C ......w` .<.....l [0270] CF A8 6E 7C 6B 4B 20 D3 FB 1A 83 16 CC E1 2C 8D ..n|kK . ......,. [0280] 1F C0 6C 8F 93 69 7F 24 2C B4 76 9E D4 5E 2D 60 ..l..i.$ ,.v..^-` [0290] 38 3D 72 D6 07 E0 38 81 52 F1 71 06 23 07 68 18 8=r...8. R.q.#.h. [02A0] 67 7B D5 56 6B 19 E8 EF 7C 45 BB B3 7C A1 45 71 g{.Vk... |E..|.Eq [02B0] 1C 2B 27 8D 2D B0 7D 6C 0B 1E 4A 0F EC 39 C0 80 .+'.-.}l ..J..9.. [02C0] D5 3F A6 A9 01 96 BE 95 D9 8F 79 3C 9B E2 B5 77 .?...... ..y<...w [02D0] 68 BA 2B B3 F4 53 70 71 3C 78 FC 12 D5 09 3B 4F h.+..Spq . :....... 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 smb_signing_md5: sequence number 16 smb_signing_sign_pdu: sent SMB signature of [0000] 22 D2 88 02 E7 0E C2 30 "......0 smb_signing_md5: sequence number 17 smb_signing_check_pdu: seq 17: got good SMB signature of [0000] C7 4B 3C 94 92 8D 79 5F .K<...y_ rpc reply data: [0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ [0010] 00 00 00 00 35 00 00 C0 ....5... [Wed Mar 18 11:18:04.781985 2015] [:error] [pid 3831] ipa: INFO: [jsonserver_session] admin at SOLARIS.COM: trust_add(u'infra.com', trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', all=False, raw=False, version=u'2.113'): RemoteRetrieveError -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Wed Mar 18 08:24:56 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Wed, 18 Mar 2015 04:24:56 -0400 Subject: [Freeipa-users] sssd options ignored? In-Reply-To: <20150318075500.GE9952@p.redhat.com> References: <20150318062603.GW3878@redhat.com> <20150318074130.GD4854@hendrix.redhat.com> <20150318075500.GE9952@p.redhat.com> Message-ID: On 3/18/15, 3:55 AM, "Sumit Bose" wrote: >On Wed, Mar 18, 2015 at 08:41:30AM +0100, Jakub Hrozek wrote: >> On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote: >> > On Tue, 17 Mar 2015, Gould, Joshua wrote: >> >> > >/etc/sssd/sssd.conf: >> > >[domain/test.osuwmc] >> > >ldap_idmap_range_min = 100000 >> > >ldap_idmap_range_size = 900000 >> > There is something completely broken here. >> >> Yes, the sssd.conf configuration :-) >> >> SSSD will not even read this sssd.conf section, it is just ignored. The >> subdomains are mostly auto-configured, just with several exceptions >> (like subdomain_homedir) where we read the subdomain config from the >> main domain config. >> >> > You *shouldn't* need to add a >> > separate domain section for any of the domains coming over the forest >> > trust link path _at_all_. SSSD automatically derives all needed >> > parameters for them via its IPA providers for the primary IPA domain. >> > >> > Jakub, what is going on? >> >> I would prefer if also Sumit can add his opinon since he authored the ID >> mapping code. > >as Alexander said in the other thread, only the IPA domain should be >configured if you want to use IPA and trust. AD domains will be >discovered and ranges will be configured on the IPA server side and IPA >clients will get all information about trusted AD domains from the IPA >server. > >So, please remove the section for the AD completely from sssd.conf. I?ll be happy to remove the AD section from the sssd.conf file and test but I think there?s more going on. The AD section was generated from the IPA client install. I never manually added anything other than ?pac? to the services line under the [sssd] section and the two ldap_idmap_range options. From abokovoy at redhat.com Wed Mar 18 08:27:22 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 10:27:22 +0200 Subject: [Freeipa-users] MIT Kerbetos & Samba 4 In-Reply-To: References: Message-ID: <20150318082722.GX3878@redhat.com> On Wed, 18 Mar 2015, Ondrej Valousek wrote: >Hi list (Simo ;) > >Sorry for the bit off-topic question, but do we know whether Samba4 can >now share the same KDC with IPA server so that it can act as AD DC? I >heard MIT KDC functionality would have to be extended, but not sure >whether this is on the roundmap or not. We are working on porting Samba AD DC to use MIT KDC. However, this usage is not meant for having the same KDC for both FreeIPA and Samba AD DC. Instead, they will have separate deployments connected to each other with the help of cross-forest trusts. Reports on the progress in this area will be given at SambaXP conference in May'15. -- / Alexander Bokovoy From abokovoy at redhat.com Wed Mar 18 08:28:16 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 10:28:16 +0200 Subject: [Freeipa-users] sssd options ignored? In-Reply-To: References: <20150318062603.GW3878@redhat.com> <20150318074130.GD4854@hendrix.redhat.com> <20150318075500.GE9952@p.redhat.com> Message-ID: <20150318082816.GY3878@redhat.com> On Wed, 18 Mar 2015, Gould, Joshua wrote: > > >On 3/18/15, 3:55 AM, "Sumit Bose" wrote: > >>On Wed, Mar 18, 2015 at 08:41:30AM +0100, Jakub Hrozek wrote: >>> On Wed, Mar 18, 2015 at 08:26:03AM +0200, Alexander Bokovoy wrote: >>> > On Tue, 17 Mar 2015, Gould, Joshua wrote: >>> >>> > >/etc/sssd/sssd.conf: >>> > >[domain/test.osuwmc] >>> > >ldap_idmap_range_min = 100000 >>> > >ldap_idmap_range_size = 900000 >>> > There is something completely broken here. >>> >>> Yes, the sssd.conf configuration :-) >>> >>> SSSD will not even read this sssd.conf section, it is just ignored. The >>> subdomains are mostly auto-configured, just with several exceptions >>> (like subdomain_homedir) where we read the subdomain config from the >>> main domain config. >>> >>> > You *shouldn't* need to add a >>> > separate domain section for any of the domains coming over the forest >>> > trust link path _at_all_. SSSD automatically derives all needed >>> > parameters for them via its IPA providers for the primary IPA domain. >>> > >>> > Jakub, what is going on? >>> >>> I would prefer if also Sumit can add his opinon since he authored the ID >>> mapping code. >> >>as Alexander said in the other thread, only the IPA domain should be >>configured if you want to use IPA and trust. AD domains will be >>discovered and ranges will be configured on the IPA server side and IPA >>clients will get all information about trusted AD domains from the IPA >>server. >> >>So, please remove the section for the AD completely from sssd.conf. > >I?ll be happy to remove the AD section from the sssd.conf file and test >but I think there?s more going on. The AD section was generated from the >IPA client install. I never manually added anything other than ?pac? to >the services line under the [sssd] section and the two ldap_idmap_range >options. Show your /var/log/ipaclient-install.log. ipa-client-install has no support to generate sections for AD at all. -- / Alexander Bokovoy From bentech4you at gmail.com Wed Mar 18 09:00:11 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 12:00:11 +0300 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: References: Message-ID: HI i saw the this in BZ and it's closed my mentioning it's got resolved on RHEL/Centos 7. But i am already using 7 . please anyone help me to fix this? Regards, Nem On Wed, Mar 18, 2015 at 11:19 AM, Ben .T.George wrote: > Hi > > i am getting "ipa: ERROR: CIFS server communication error: code > "-1073741771"," > > while doing > > [root at kwtpocpbis02 ~]# ipa trust-add --type=ad infra.com --admin > Administrator --password > Active Directory domain administrator's password: > ipa: ERROR: CIFS server communication error: code "-1073741771", > message "NT_STATUS_OBJECT_NAME_COLLISION" (both may be > "None") > > i am using centos 7 and IPA 4.1.2 > > IPA Server > > [root at kwtpocpbis02 ~]# host kwtpocpbis02.solaris.com > kwtpocpbis02.solaris.com has address 172.16.107.135 > [root at kwtpocpbis02 ~]# host 172.16.107.135 > 135.107.16.172.in-addr.arpa domain name pointer kwtpocpbis02.solaris.com. > > > AD > > [root at kwtpocpbis02 ~]# host 172.16.107.250 > 250.107.16.172.in-addr.arpa domain name pointer kwtipaad001.infra.com. > [root at kwtpocpbis02 ~]# host kwtipaad001.infra.com > kwtipaad001.infra.com has address 172.16.107.250 > > debugging is enabled and this is i am getting on error_log > > INFO: Current debug levels: > all: 11 > tdb: 11 > printdrivers: 11 > lanman: 11 > smb: 11 > rpc_parse: 11 > rpc_srv: 11 > rpc_cli: 11 > passdb: 11 > sam: 11 > auth: 11 > winbind: 11 > vfs: 11 > idmap: 11 > quota: 11 > acls: 11 > locking: 11 > msdfs: 11 > dmapi: 11 > registry: 11 > scavenger: 11 > dns: 11 > ldb: 11 > pm_process() returned Yes > GENSEC backend 'gssapi_spnego' registered > GENSEC backend 'gssapi_krb5' registered > GENSEC backend 'gssapi_krb5_sasl' registered > GENSEC backend 'sasl-DIGEST-MD5' registered > GENSEC backend 'schannel' registered > GENSEC backend 'spnego' registered > GENSEC backend 'ntlmssp' registered > Using binding ncacn_np:kwtpocpbis02.solaris.com[,] > Mapped to DCERPC endpoint \pipe\lsarpc > added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 > netmask=255.255.255.0 > added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 > netmask=255.255.255.0 > Socket options: > SO_KEEPALIVE = 0 > SO_REUSEADDR = 0 > SO_BROADCAST = 0 > TCP_NODELAY = 1 > TCP_KEEPCNT = 9 > TCP_KEEPIDLE = 7200 > TCP_KEEPINTVL = 75 > IPTOS_LOWDELAY = 0 > IPTOS_THROUGHPUT = 0 > SO_REUSEPORT = 0 > SO_SNDBUF = 663430 > SO_RCVBUF = 261942 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 > Starting GENSEC mechanism spnego > Starting GENSEC submechanism gssapi_krb5 > Ticket in credentials cache for admin at SOLARIS.COM will expire in 81540 > secs > gensec_gssapi: NO credentials were delegated > GSSAPI Connection will be cryptographically sealed > 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 > 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 ........ > 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 > rpc reply data: > [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ > .....U.4 > [0010] 2E 0F 00 00 00 00 00 00 ........ > rpc request data: > [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ > .....U.4 > [0010] 2E 0F 00 00 0C 00 ...... > 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 > rpc reply data: > [0000] 00 00 02 00 0C 00 00 00 0E 00 10 00 04 00 02 00 ........ > ........ > [0010] 16 00 18 00 08 00 02 00 16 00 18 00 0C 00 02 00 ........ > ........ > [0020] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... > .0l..... > [0030] 10 00 02 00 08 00 00 00 00 00 00 00 07 00 00 00 ........ > ........ > [0040] 53 00 4F 00 4C 00 41 00 52 00 49 00 53 00 00 00 S.O.L.A. > R.I.S... > [0050] 0C 00 00 00 00 00 00 00 0B 00 00 00 73 00 6F 00 ........ > ....s.o. > [0060] 6C 00 61 00 72 00 69 00 73 00 2E 00 63 00 6F 00 l.a.r.i. > s...c.o. > [0070] 6D 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 m....... > ........ > [0080] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. > r.i.s... > [0090] 63 00 6F 00 6D 00 00 00 04 00 00 00 01 04 00 00 c.o.m... > ........ > [00A0] 00 00 00 05 15 00 00 00 5F 89 A9 B4 86 30 6C 9D ........ > _....0l. > [00B0] B4 09 10 02 00 00 00 00 ........ > rpc request data: > [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ > .....U.4 > [0010] 2E 0F 00 00 06 00 ...... > 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 > 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: 11 > tdb: 11 > printdrivers: 11 > lanman: 11 > smb: 11 > rpc_parse: 11 > rpc_srv: 11 > rpc_cli: 11 > passdb: 11 > sam: 11 > auth: 11 > winbind: 11 > vfs: 11 > idmap: 11 > quota: 11 > acls: 11 > locking: 11 > msdfs: 11 > dmapi: 11 > registry: 11 > scavenger: 11 > dns: 11 > ldb: 11 > pm_process() returned Yes > added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 > netmask=255.255.255.0 > added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 > netmask=255.255.255.0 > added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 > netmask=255.255.255.0 > added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 > netmask=255.255.255.0 > finddcs: searching for a DC by DNS domain infra.com > finddcs: looking for SRV records for _ldap._tcp.infra.com > ads_dns_lookup_srv: 1 records returned in the answer section. > ads_dns_parse_rr_srv: Parsed kwtipaad001.infra.com [0, 100, 389] > Addrs = 172.16.107.250 at 389/kwtipaad001 > finddcs: DNS SRV response 0 at '172.16.107.250' > finddcs: performing CLDAP query on 172.16.107.250 > &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX > command : LOGON_SAM_LOGON_RESPONSE_EX (23) > sbz : 0x0000 (0) > server_type : 0x000033fd (13309) > 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 > 1: 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 : 2b3fba2e-3635-4e27-90d3-be555b96aea1 > forest : 'infra.com' > dns_domain : 'infra.com' > pdc_dns_name : 'kwtipaad001.infra.com' > domain_name : 'INFRA' > pdc_name : 'KWTIPAAD001' > 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 172.16.107.250 with server_type=0x000033fd > 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: 11 > tdb: 11 > printdrivers: 11 > lanman: 11 > smb: 11 > rpc_parse: 11 > rpc_srv: 11 > rpc_cli: 11 > passdb: 11 > sam: 11 > auth: 11 > winbind: 11 > vfs: 11 > idmap: 11 > quota: 11 > acls: 11 > locking: 11 > msdfs: 11 > dmapi: 11 > registry: 11 > scavenger: 11 > dns: 11 > ldb: 11 > pm_process() returned Yes > Using binding ncacn_np:kwtipaad001.infra.com[,] > Mapped to DCERPC endpoint \pipe\lsarpc > added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 > netmask=255.255.255.0 > added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 > netmask=255.255.255.0 > Socket options: > SO_KEEPALIVE = 0 > SO_REUSEADDR = 0 > SO_BROADCAST = 0 > TCP_NODELAY = 1 > TCP_KEEPCNT = 9 > TCP_KEEPIDLE = 7200 > TCP_KEEPINTVL = 75 > IPTOS_LOWDELAY = 0 > IPTOS_THROUGHPUT = 0 > SO_REUSEPORT = 0 > SO_SNDBUF = 23080 > SO_RCVBUF = 87380 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 > Starting GENSEC mechanism spnego > Starting GENSEC submechanism 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 : 0x0007 (7) > DomainNameMaxLen : 0x0007 (7) > DomainName : * > DomainName : 'SOLARIS' > WorkstationLen : 0x0007 (7) > WorkstationMaxLen : 0x0007 (7) > Workstation : * > Workstation : 'SOLARIS' > smb_signing_sign_pdu: sent SMB signature of > [0000] 42 53 52 53 50 59 4C 20 BSRSPYL > 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 > smb_signing_sign_pdu: sent SMB signature of > [0000] 42 53 52 53 50 59 4C 20 BSRSPYL > smb_signing_activate: user_session_key > [0000] 23 27 C0 93 E7 C8 7F B9 47 A9 FD 91 F7 73 10 6E #'...... > G....s.n > smb_signing_activate: NULL response_data > smb_signing_md5: sequence number 1 > smb_signing_check_pdu: seq 1: got good SMB signature of > [0000] 71 D6 FE AD D8 76 9E B9 q....v.. > smb_signing_md5: sequence number 2 > smb_signing_sign_pdu: sent SMB signature of > [0000] 07 24 9E 31 C2 C8 37 9D .$.1..7. > smb_signing_md5: sequence number 3 > smb_signing_check_pdu: seq 3: got good SMB signature of > [0000] 7E F4 97 77 31 32 74 F7 ~..w12t. > smb_signing_md5: sequence number 4 > smb_signing_sign_pdu: sent SMB signature of > [0000] 26 96 4E B8 AF B2 5C EB &.N...\. > smb_signing_md5: sequence number 5 > smb_signing_check_pdu: seq 5: got good SMB signature of > [0000] 77 EE BD 92 63 7A F7 86 w...cz.. > 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 > smb_signing_md5: sequence number 6 > smb_signing_sign_pdu: sent SMB signature of > [0000] F2 49 18 60 8B 96 22 FB .I.`..". > smb_signing_md5: sequence number 7 > smb_signing_check_pdu: seq 7: got good SMB signature of > [0000] 74 CA 84 E8 F0 2B 5F 93 t....+_. > 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 ........ > 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 > smb_signing_md5: sequence number 8 > smb_signing_sign_pdu: sent SMB signature of > [0000] AC 94 11 10 43 F9 1B A8 ....C... > smb_signing_md5: sequence number 9 > smb_signing_check_pdu: seq 9: got good SMB signature of > [0000] CD B6 5D F7 6A 95 70 B9 ..].j.p. > rpc reply data: > [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). > &..M..f. > [0010] B3 FE D1 C1 00 00 00 00 ........ > rpc request data: > [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). > &..M..f. > [0010] B3 FE D1 C1 0C 00 ...... > 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 > smb_signing_md5: sequence number 10 > smb_signing_sign_pdu: sent SMB signature of > [0000] 32 2D 66 66 C2 FD C7 AF 2-ff.... > smb_signing_md5: sequence number 11 > smb_signing_check_pdu: seq 11: got good SMB signature of > [0000] DD 3C 1D 35 CD 94 09 88 .<.5.... > rpc reply data: > [0000] 00 00 02 00 0C 00 00 00 0A 00 0C 00 04 00 02 00 ........ > ........ > [0010] 12 00 14 00 08 00 02 00 12 00 14 00 0C 00 02 00 ........ > ........ > [0020] 2E BA 3F 2B 35 36 27 4E 90 D3 BE 55 5B 96 AE A1 ..?+56'N > ...U[... > [0030] 10 00 02 00 06 00 00 00 00 00 00 00 05 00 00 00 ........ > ........ > [0040] 49 00 4E 00 46 00 52 00 41 00 00 00 0A 00 00 00 I.N.F.R. > A....... > [0050] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ > i.n.f.r. > [0060] 61 00 2E 00 63 00 6F 00 6D 00 00 00 0A 00 00 00 a...c.o. > m....... > [0070] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ > i.n.f.r. > [0080] 61 00 2E 00 63 00 6F 00 6D 00 00 00 04 00 00 00 a...c.o. > m....... > [0090] 01 04 00 00 00 00 00 05 15 00 00 00 05 CF 66 0B ........ > ......f. > [00A0] 52 91 25 EF 02 4B 1B D6 00 00 00 00 R.%..K.. .... > rpc request data: > [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). > &..M..f. > [0010] B3 FE D1 C1 06 00 ...... > 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 > smb_signing_md5: sequence number 12 > smb_signing_sign_pdu: sent SMB signature of > [0000] 62 FA 51 B6 49 8C 2D 73 b.Q.I.-s > smb_signing_md5: sequence number 13 > smb_signing_check_pdu: seq 13: got good SMB signature of > [0000] 4A E8 4A EB 69 A4 EC 5D J.J.i..] > rpc reply data: > [0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ > ........ > rpc request data: > [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). > &..M..f. > [0010] B3 FE D1 C1 16 00 16 00 00 00 02 00 0B 00 00 00 ........ > ........ > [0020] 00 00 00 00 0B 00 00 00 73 00 6F 00 6C 00 61 00 ........ > s.o.l.a. > [0030] 72 00 69 00 73 00 2E 00 63 00 6F 00 6D 00 08 00 r.i.s... > c.o.m... > 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 > smb_signing_md5: sequence number 14 > smb_signing_sign_pdu: sent SMB signature of > [0000] 85 6D ED 23 EB 6A 9B 42 .m.#.j.B > smb_signing_md5: sequence number 15 > smb_signing_check_pdu: seq 15: got good SMB signature of > [0000] E3 52 D1 8E FB BD DE 9C .R...... > rpc reply data: > [0000] 00 00 00 00 34 00 00 C0 ....4... > rpc request data: > [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). > &..M..f. > [0010] B3 FE D1 C1 16 00 18 00 00 00 02 00 0E 00 10 00 ........ > ........ > [0020] 04 00 02 00 08 00 02 00 03 00 00 00 02 00 00 00 ........ > ........ > [0030] 00 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 ........ > ........ > [0040] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. > r.i.s... > [0050] 63 00 6F 00 6D 00 00 00 08 00 00 00 00 00 00 00 c.o.m... > ........ > [0060] 07 00 00 00 53 00 4F 00 4C 00 41 00 52 00 49 00 ....S.O. > L.A.R.I. > [0070] 53 00 00 00 04 00 00 00 01 04 00 00 00 00 00 05 S....... > ........ > [0080] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... > .0l..... > [0090] 40 04 00 00 0C 00 02 00 40 04 00 00 F3 EB B4 CA @....... > @....... > [00A0] 99 BB 60 76 9A 51 FD BE 16 00 59 56 14 B8 A4 AF ..`v.Q.. > ..YV.... > [00B0] 00 4F 6E C5 95 EE 75 2E BA EF 21 CF 26 B1 9E C5 .On...u. > ..!.&... > [00C0] 29 54 05 06 1F EB BF 90 4A F1 88 37 D3 AE B9 FB )T...... > J..7.... > [00D0] A0 A4 B7 C5 2A B2 38 60 3D 59 B1 14 19 5D 30 64 ....*.8` > =Y...]0d > [00E0] F2 82 6D DC 03 CC 19 CC D5 D1 ED A7 63 40 F0 72 ..m..... ....c@ > .r > [00F0] E5 80 B2 FB 3E 06 95 45 76 19 0A C8 5A 83 5B 00 ....>..E > v...Z.[. > [0100] C7 39 27 83 43 88 98 0F 2B C5 75 D8 4C 3B 61 18 .9'.C... > +.u.L;a. > [0110] CF F6 1F BB 31 A9 CD FF 57 F5 EF 0B 81 B9 5F 7E ....1... > W....._~ > [0120] 1B 3E 00 11 92 CB 92 8C 29 D5 90 31 B7 39 B1 31 .>...... > )..1.9.1 > [0130] 7C C3 0C C8 E5 D0 51 AA 20 D2 A2 39 C1 52 ED 91 |.....Q. > ..9.R.. > [0140] 70 27 2F 7C EB 05 8F 91 AA EB 26 13 07 2C FA 62 p'/|.... > ..&..,.b > [0150] C3 CB 79 DD B5 DA EC 3E 78 9A D8 A1 AE 64 3C 7F ..y....> > x....d<. > [0160] BB CE 06 48 9A 56 6E 22 FC 6D 78 59 63 2F B8 51 ...H.Vn" > .mxYc/.Q > [0170] D6 81 91 1D 54 94 2D C7 69 75 B3 E4 F1 77 93 EF ....T.-. > iu...w.. > [0180] BB 3E 0E 80 D7 D4 DD A0 DA 3C 10 51 64 5A AA A7 .>...... > .<.QdZ.. > [0190] CB AE CE DA BF F8 03 10 5C DB 64 9F 32 94 D4 F2 ........ > \.d.2... > [01A0] 67 1F D4 E7 4E 4F A3 DA A3 1A 24 FC 47 C9 73 FD g...NO.. > ..$.G.s. > [01B0] AB 70 CB 34 BE 3B FF 12 A9 A3 DA 31 72 41 07 C0 .p.4.;.. > ...1rA.. > [01C0] 27 4A FF ED F8 C7 39 FD B6 87 2E 01 F9 0E 27 9F 'J....9. > ......'. > [01D0] 22 12 6B B3 A8 27 CB 86 A1 9D 8F D0 7A 70 97 66 ".k..'.. > ....zp.f > [01E0] D4 AD 10 FF BF 88 3A 14 A4 D6 74 E4 17 79 E2 79 ......:. > ..t..y.y > [01F0] A7 41 0D 2D A6 09 C5 DF 9F 85 C4 C8 E8 28 10 23 .A.-.... > .....(.# > [0200] B2 87 1C 8F 82 3E EC F6 BB 51 49 CD EF CF D3 95 .....>.. > .QI..... > [0210] 76 E5 A1 7B 6D 42 81 04 81 8D C0 9C 82 13 14 A1 v..{mB.. > ........ > [0220] 1C 8B B1 ED 94 D7 41 EF 43 04 49 A5 35 17 17 51 ......A. > C.I.5..Q > [0230] C1 D0 27 13 93 6F CF 15 15 E6 C3 32 4D 85 9D E7 ..'..o.. > ...2M... > [0240] FF E7 36 D9 3F CE 35 A2 DC 2D AB 06 1E 84 2B 6E ..6.?.5. > .-....+n > [0250] 3C D9 BF 3E 01 9E 6B 8B 5D 8D F3 98 F0 AA 1B 62 <..>..k. > ]......b > [0260] C4 BD D9 CB F6 F8 77 60 09 3C F1 C7 9B FA BB 6C ......w` > .<.....l > [0270] CF A8 6E 7C 6B 4B 20 D3 FB 1A 83 16 CC E1 2C 8D ..n|kK . > ......,. > [0280] 1F C0 6C 8F 93 69 7F 24 2C B4 76 9E D4 5E 2D 60 ..l..i.$ > ,.v..^-` > [0290] 38 3D 72 D6 07 E0 38 81 52 F1 71 06 23 07 68 18 8=r...8. > R.q.#.h. > [02A0] 67 7B D5 56 6B 19 E8 EF 7C 45 BB B3 7C A1 45 71 g{.Vk... > |E..|.Eq > [02B0] 1C 2B 27 8D 2D B0 7D 6C 0B 1E 4A 0F EC 39 C0 80 .+'.-.}l > ..J..9.. > [02C0] D5 3F A6 A9 01 96 BE 95 D9 8F 79 3C 9B E2 B5 77 .?...... > ..y<...w > [02D0] 68 BA 2B B3 F4 53 70 71 3C 78 FC 12 D5 09 3B 4F h.+..Spq > [02E0] 54 56 A3 73 63 E7 3A AE 29 F4 64 59 2E 74 BE B9 TV.sc.:. > ).dY.t.. > [02F0] 36 57 80 7B C8 5D 7A F1 92 B9 B9 98 33 62 2C 02 6W.{.]z. > ....3b,. > [0300] 2E 57 41 01 19 67 51 5D 57 FF FF 78 43 B2 27 00 .WA..gQ] > W..xC.'. > [0310] 49 E7 94 17 BC 69 AD 56 7D 51 65 F0 59 DB 41 15 I....i.V > }Qe.Y.A. > [0320] 94 8C 69 BE 1E 1D 35 1E 2F 60 EF B4 5C 43 A0 F5 ..i...5. > /`..\C.. > [0330] D3 6F 7E A1 42 2D 75 56 37 78 54 F4 9D AA A1 BB .o~.B-uV > 7xT..... > [0340] 31 7F DB AF 4A 7D EA 03 B2 64 06 84 F1 69 93 6F 1...J}.. > .d...i.o > [0350] D1 26 D6 3C CB E0 6F 8C 72 38 00 65 12 5D 3F 5E .&.<..o. > r8.e.]?^ > [0360] 8A 9B 36 AB FB 53 85 19 59 2B D7 9E 4B 9C DE 4E ..6..S.. > Y+..K..N > [0370] 6E 9B CA F1 8E CC 25 B5 7D 79 86 F3 0F 2B 9A D3 n.....%. > }y...+.. > [0380] 5F 47 6C DC AD 2F 6A 87 04 D1 C3 90 96 13 A0 4D _Gl../j. > .......M > [0390] 6A CC 05 74 0C E1 57 26 96 EC 72 53 93 BC 99 FA j..t..W& > ..rS.... > [03A0] 4C E9 17 2F 40 A8 B8 0A 77 D1 A5 D6 08 0B A1 69 L../@... > w......i > [03B0] 1D D9 3A EE BA A3 20 56 3F B0 48 9A AF EC CE 22 ..:... V > ?.H...." > [03C0] 03 B4 CC CF BC A7 38 CB CC 99 A8 CB C7 BE 54 6F ......8. > ......To > [03D0] 7B C8 DB 38 52 D5 F4 DB F1 E2 45 7B D1 56 C7 73 {..8R... > ..E{.V.s > [03E0] 91 08 64 7A 79 A9 49 3F 7F F4 41 1B 72 CB F0 E0 ..dzy.I? > ..A.r... > [03F0] B7 C1 69 50 4C 85 94 6B 75 AA CB BA A5 58 CA 9A ..iPL..k > u....X.. > [0400] 84 96 52 AA E2 F0 94 95 65 0A 03 06 C9 A5 A4 3F ..R..... > e......? > [0410] 78 46 4D 39 4B 64 88 4B A9 CA BB 2F 7C 65 B4 6E xFM9Kd.K > .../|e.n > [0420] D0 3D C7 19 29 50 A6 3D D3 A7 19 7C 9C 7C 82 06 .=..)P.= > ...|.|.. > [0430] 2B 3B E3 50 B9 CF 5F 31 03 31 AC 3D CF 57 45 32 +;.P.._1 > .1.=.WE2 > [0440] 32 F4 9C 9C 88 EE 93 63 F0 21 41 3A CA BA 22 95 2......c > .!A:..". > [0450] 38 DB 0F 10 3A AF C5 74 C7 07 85 B2 07 22 53 8F 8...:..t > ....."S. > [0460] 31 74 71 5A E5 92 5B 4E DE F0 DB 38 D9 A0 20 E2 1tqZ..[N ...8.. > . > [0470] 39 F7 79 BB B6 92 D0 D5 19 DB 14 EF F6 DD 6A 2C 9.y..... > ......j, > [0480] 4A 11 1E F2 DD 89 13 98 7E 19 FC CD 75 BF E8 57 J....... > ~...u..W > [0490] A9 EF B3 34 60 01 EF 7B 2C BC E4 8D A7 DD 06 05 ...4`..{ > ,....... > [04A0] A8 4B A6 B8 F4 C6 5B B2 AF 4D 3A BB 35 74 18 91 .K....[. > .M:.5t.. > [04B0] 54 A2 38 95 F1 8F CD 13 A1 F6 7B 4C 4D A5 04 73 T.8..... > ..{LM..s > [04C0] 12 DE DC A5 C9 9E B2 73 53 F2 A9 94 A7 4B 65 52 .......s > S....KeR > [04D0] 15 C6 84 70 4A 5B 3E 17 3A 96 AF D1 00 00 01 00 ...pJ[>. > :....... > 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 > smb_signing_md5: sequence number 16 > smb_signing_sign_pdu: sent SMB signature of > [0000] 22 D2 88 02 E7 0E C2 30 "......0 > smb_signing_md5: sequence number 17 > smb_signing_check_pdu: seq 17: got good SMB signature of > [0000] C7 4B 3C 94 92 8D 79 5F .K<...y_ > rpc reply data: > [0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ > ........ > [0010] 00 00 00 00 35 00 00 C0 ....5... > [Wed Mar 18 11:18:04.781985 2015] [:error] [pid 3831] ipa: INFO: > [jsonserver_session] admin at SOLARIS.COM: trust_add(u'infra.com', > trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', > all=False, raw=False, version=u'2.113'): RemoteRetrieveError > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Wed Mar 18 09:05:30 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 18 Mar 2015 05:05:30 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: References: Message-ID: I ran some more tests and I've found that it's a general sssd issue which affects everything handled by sssd (pam, ssh, sudo). I see similar problems with 'su - username'. I'm guessing that kinit works since it bypasses sssd. Does anyone have any ideas on debugging this? On Tue, Mar 17, 2015 at 2:54 PM, Prasun Gera wrote: > Sorry, the message got sent accidentally earlier before I could provide > all the details. > > Version: 4.1.0 on RHEL 7.1 x86_64 > > Steps: > 1. ipa-server-install > 2. service sshd restart > 3. kinit admin <- This always works > 4. ssh admin at localhost <- This works for the first time, > fails second time onwards > ssh admin at host_addr from external system <- This also works the > first time, fails second time onwards > > 5. ipa-server-install --uninstall > 6. go to 1 > > The log messages in /var/log/messages point to [sssd[krb5_child[21029]]]: > Decrypt integrity check failed at the point of the authentication failure > sssd's log's have a lot of "No matching domain found for user" messages. > /var/log/krb5kdc.log has a lot of error decoding FAST: > for , Decrypt integrity check failed while handling > ap-request armor > > The only ERROR I can see in /var/log/ipaserver-uninstall.log is > pkidestroy : ERROR ....... subprocess.CalledProcessError: Command > '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', ......returned > non-zero exit status 6! > > > It appears that the uninstall process is leaving some residual > configuration behind which is conflicting with the subsequent installation > with the same domain name > > > Regards, > Prasun > > > > > > > > On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera > wrote: > >> Hello, >> I installed the ipa-server on an RHEL 7.1 system, uninstalled it and >> reinstalled it with the same domain name as the first time. This somehow >> creates problems with ssh authentication on the server from external >> systems as well as from the server itself. >> >> Steps: >> 1. ipa-server-install >> 2. service sshd restart >> 3. kinit admin >> 4. ssh admin at localhost >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 18 09:15:00 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 11:15:00 +0200 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: References: Message-ID: <20150318091500.GZ3878@redhat.com> On Wed, 18 Mar 2015, Ben .T.George wrote: >Hi > >i am getting "ipa: ERROR: CIFS server communication error: code >"-1073741771"," > >while doing > >[root at kwtpocpbis02 ~]# ipa trust-add --type=ad infra.com --admin >Administrator --password >Active Directory domain administrator's password: >ipa: ERROR: CIFS server communication error: code "-1073741771", > message "NT_STATUS_OBJECT_NAME_COLLISION" (both may be >"None") > >i am using centos 7 and IPA 4.1.2 NT_STATUS_OBJECT_NAME_COLLISION means AD thinks you have hosts in AD that belong to the solaris.com domain which 'trust-ad' operation claims to belong to IPA realm. AD denies operating the trust in this case. > >IPA Server > >[root at kwtpocpbis02 ~]# host kwtpocpbis02.solaris.com >kwtpocpbis02.solaris.com has address 172.16.107.135 >[root at kwtpocpbis02 ~]# host 172.16.107.135 >135.107.16.172.in-addr.arpa domain name pointer kwtpocpbis02.solaris.com. > > >AD > >[root at kwtpocpbis02 ~]# host 172.16.107.250 >250.107.16.172.in-addr.arpa domain name pointer kwtipaad001.infra.com. >[root at kwtpocpbis02 ~]# host kwtipaad001.infra.com >kwtipaad001.infra.com has address 172.16.107.250 > >debugging is enabled and this is i am getting on error_log > >INFO: Current debug levels: > all: 11 > tdb: 11 > printdrivers: 11 > lanman: 11 > smb: 11 > rpc_parse: 11 > rpc_srv: 11 > rpc_cli: 11 > passdb: 11 > sam: 11 > auth: 11 > winbind: 11 > vfs: 11 > idmap: 11 > quota: 11 > acls: 11 > locking: 11 > msdfs: 11 > dmapi: 11 > registry: 11 > scavenger: 11 > dns: 11 > ldb: 11 >pm_process() returned Yes >GENSEC backend 'gssapi_spnego' registered >GENSEC backend 'gssapi_krb5' registered >GENSEC backend 'gssapi_krb5_sasl' registered >GENSEC backend 'sasl-DIGEST-MD5' registered >GENSEC backend 'schannel' registered >GENSEC backend 'spnego' registered >GENSEC backend 'ntlmssp' registered >Using binding ncacn_np:kwtpocpbis02.solaris.com[,] >Mapped to DCERPC endpoint \pipe\lsarpc >added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >netmask=255.255.255.0 >added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >netmask=255.255.255.0 >Socket options: > SO_KEEPALIVE = 0 > SO_REUSEADDR = 0 > SO_BROADCAST = 0 > TCP_NODELAY = 1 > TCP_KEEPCNT = 9 > TCP_KEEPIDLE = 7200 > TCP_KEEPINTVL = 75 > IPTOS_LOWDELAY = 0 > IPTOS_THROUGHPUT = 0 > SO_REUSEPORT = 0 > SO_SNDBUF = 663430 > SO_RCVBUF = 261942 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 >Starting GENSEC mechanism spnego >Starting GENSEC submechanism gssapi_krb5 >Ticket in credentials cache for admin at SOLARIS.COM will expire in 81540 secs >gensec_gssapi: NO credentials were delegated >GSSAPI Connection will be cryptographically sealed >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 >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 ........ >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 >rpc reply data: >[0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ .....U.4 >[0010] 2E 0F 00 00 00 00 00 00 ........ >rpc request data: >[0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ .....U.4 >[0010] 2E 0F 00 00 0C 00 ...... >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 >rpc reply data: >[0000] 00 00 02 00 0C 00 00 00 0E 00 10 00 04 00 02 00 ........ ........ >[0010] 16 00 18 00 08 00 02 00 16 00 18 00 0C 00 02 00 ........ ........ >[0020] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... .0l..... >[0030] 10 00 02 00 08 00 00 00 00 00 00 00 07 00 00 00 ........ ........ >[0040] 53 00 4F 00 4C 00 41 00 52 00 49 00 53 00 00 00 S.O.L.A. R.I.S... >[0050] 0C 00 00 00 00 00 00 00 0B 00 00 00 73 00 6F 00 ........ ....s.o. >[0060] 6C 00 61 00 72 00 69 00 73 00 2E 00 63 00 6F 00 l.a.r.i. s...c.o. >[0070] 6D 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 m....... ........ >[0080] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. r.i.s... >[0090] 63 00 6F 00 6D 00 00 00 04 00 00 00 01 04 00 00 c.o.m... ........ >[00A0] 00 00 00 05 15 00 00 00 5F 89 A9 B4 86 30 6C 9D ........ _....0l. >[00B0] B4 09 10 02 00 00 00 00 ........ >rpc request data: >[0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ .....U.4 >[0010] 2E 0F 00 00 06 00 ...... >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 >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: 11 > tdb: 11 > printdrivers: 11 > lanman: 11 > smb: 11 > rpc_parse: 11 > rpc_srv: 11 > rpc_cli: 11 > passdb: 11 > sam: 11 > auth: 11 > winbind: 11 > vfs: 11 > idmap: 11 > quota: 11 > acls: 11 > locking: 11 > msdfs: 11 > dmapi: 11 > registry: 11 > scavenger: 11 > dns: 11 > ldb: 11 >pm_process() returned Yes >added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >netmask=255.255.255.0 >added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >netmask=255.255.255.0 >added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >netmask=255.255.255.0 >added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >netmask=255.255.255.0 >finddcs: searching for a DC by DNS domain infra.com >finddcs: looking for SRV records for _ldap._tcp.infra.com >ads_dns_lookup_srv: 1 records returned in the answer section. >ads_dns_parse_rr_srv: Parsed kwtipaad001.infra.com [0, 100, 389] >Addrs = 172.16.107.250 at 389/kwtipaad001 >finddcs: DNS SRV response 0 at '172.16.107.250' >finddcs: performing CLDAP query on 172.16.107.250 > &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX > command : LOGON_SAM_LOGON_RESPONSE_EX (23) > sbz : 0x0000 (0) > server_type : 0x000033fd (13309) > 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 > 1: 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 : 2b3fba2e-3635-4e27-90d3-be555b96aea1 > forest : 'infra.com' > dns_domain : 'infra.com' > pdc_dns_name : 'kwtipaad001.infra.com' > domain_name : 'INFRA' > pdc_name : 'KWTIPAAD001' > 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 172.16.107.250 with server_type=0x000033fd >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: 11 > tdb: 11 > printdrivers: 11 > lanman: 11 > smb: 11 > rpc_parse: 11 > rpc_srv: 11 > rpc_cli: 11 > passdb: 11 > sam: 11 > auth: 11 > winbind: 11 > vfs: 11 > idmap: 11 > quota: 11 > acls: 11 > locking: 11 > msdfs: 11 > dmapi: 11 > registry: 11 > scavenger: 11 > dns: 11 > ldb: 11 >pm_process() returned Yes >Using binding ncacn_np:kwtipaad001.infra.com[,] >Mapped to DCERPC endpoint \pipe\lsarpc >added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >netmask=255.255.255.0 >added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >netmask=255.255.255.0 >Socket options: > SO_KEEPALIVE = 0 > SO_REUSEADDR = 0 > SO_BROADCAST = 0 > TCP_NODELAY = 1 > TCP_KEEPCNT = 9 > TCP_KEEPIDLE = 7200 > TCP_KEEPINTVL = 75 > IPTOS_LOWDELAY = 0 > IPTOS_THROUGHPUT = 0 > SO_REUSEPORT = 0 > SO_SNDBUF = 23080 > SO_RCVBUF = 87380 > SO_SNDLOWAT = 1 > SO_RCVLOWAT = 1 > SO_SNDTIMEO = 0 > SO_RCVTIMEO = 0 > TCP_QUICKACK = 1 > TCP_DEFER_ACCEPT = 0 >Starting GENSEC mechanism spnego >Starting GENSEC submechanism 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 : 0x0007 (7) > DomainNameMaxLen : 0x0007 (7) > DomainName : * > DomainName : 'SOLARIS' > WorkstationLen : 0x0007 (7) > WorkstationMaxLen : 0x0007 (7) > Workstation : * > Workstation : 'SOLARIS' >smb_signing_sign_pdu: sent SMB signature of >[0000] 42 53 52 53 50 59 4C 20 BSRSPYL >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 >smb_signing_sign_pdu: sent SMB signature of >[0000] 42 53 52 53 50 59 4C 20 BSRSPYL >smb_signing_activate: user_session_key >[0000] 23 27 C0 93 E7 C8 7F B9 47 A9 FD 91 F7 73 10 6E #'...... G....s.n >smb_signing_activate: NULL response_data >smb_signing_md5: sequence number 1 >smb_signing_check_pdu: seq 1: got good SMB signature of >[0000] 71 D6 FE AD D8 76 9E B9 q....v.. >smb_signing_md5: sequence number 2 >smb_signing_sign_pdu: sent SMB signature of >[0000] 07 24 9E 31 C2 C8 37 9D .$.1..7. >smb_signing_md5: sequence number 3 >smb_signing_check_pdu: seq 3: got good SMB signature of >[0000] 7E F4 97 77 31 32 74 F7 ~..w12t. >smb_signing_md5: sequence number 4 >smb_signing_sign_pdu: sent SMB signature of >[0000] 26 96 4E B8 AF B2 5C EB &.N...\. >smb_signing_md5: sequence number 5 >smb_signing_check_pdu: seq 5: got good SMB signature of >[0000] 77 EE BD 92 63 7A F7 86 w...cz.. >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 >smb_signing_md5: sequence number 6 >smb_signing_sign_pdu: sent SMB signature of >[0000] F2 49 18 60 8B 96 22 FB .I.`..". >smb_signing_md5: sequence number 7 >smb_signing_check_pdu: seq 7: got good SMB signature of >[0000] 74 CA 84 E8 F0 2B 5F 93 t....+_. >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 ........ >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 >smb_signing_md5: sequence number 8 >smb_signing_sign_pdu: sent SMB signature of >[0000] AC 94 11 10 43 F9 1B A8 ....C... >smb_signing_md5: sequence number 9 >smb_signing_check_pdu: seq 9: got good SMB signature of >[0000] CD B6 5D F7 6A 95 70 B9 ..].j.p. >rpc reply data: >[0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. >[0010] B3 FE D1 C1 00 00 00 00 ........ >rpc request data: >[0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. >[0010] B3 FE D1 C1 0C 00 ...... >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 >smb_signing_md5: sequence number 10 >smb_signing_sign_pdu: sent SMB signature of >[0000] 32 2D 66 66 C2 FD C7 AF 2-ff.... >smb_signing_md5: sequence number 11 >smb_signing_check_pdu: seq 11: got good SMB signature of >[0000] DD 3C 1D 35 CD 94 09 88 .<.5.... >rpc reply data: >[0000] 00 00 02 00 0C 00 00 00 0A 00 0C 00 04 00 02 00 ........ ........ >[0010] 12 00 14 00 08 00 02 00 12 00 14 00 0C 00 02 00 ........ ........ >[0020] 2E BA 3F 2B 35 36 27 4E 90 D3 BE 55 5B 96 AE A1 ..?+56'N ...U[... >[0030] 10 00 02 00 06 00 00 00 00 00 00 00 05 00 00 00 ........ ........ >[0040] 49 00 4E 00 46 00 52 00 41 00 00 00 0A 00 00 00 I.N.F.R. A....... >[0050] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ i.n.f.r. >[0060] 61 00 2E 00 63 00 6F 00 6D 00 00 00 0A 00 00 00 a...c.o. m....... >[0070] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ i.n.f.r. >[0080] 61 00 2E 00 63 00 6F 00 6D 00 00 00 04 00 00 00 a...c.o. m....... >[0090] 01 04 00 00 00 00 00 05 15 00 00 00 05 CF 66 0B ........ ......f. >[00A0] 52 91 25 EF 02 4B 1B D6 00 00 00 00 R.%..K.. .... >rpc request data: >[0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. >[0010] B3 FE D1 C1 06 00 ...... >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 >smb_signing_md5: sequence number 12 >smb_signing_sign_pdu: sent SMB signature of >[0000] 62 FA 51 B6 49 8C 2D 73 b.Q.I.-s >smb_signing_md5: sequence number 13 >smb_signing_check_pdu: seq 13: got good SMB signature of >[0000] 4A E8 4A EB 69 A4 EC 5D J.J.i..] >rpc reply data: >[0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ ........ >rpc request data: >[0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. >[0010] B3 FE D1 C1 16 00 16 00 00 00 02 00 0B 00 00 00 ........ ........ >[0020] 00 00 00 00 0B 00 00 00 73 00 6F 00 6C 00 61 00 ........ s.o.l.a. >[0030] 72 00 69 00 73 00 2E 00 63 00 6F 00 6D 00 08 00 r.i.s... c.o.m... >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 >smb_signing_md5: sequence number 14 >smb_signing_sign_pdu: sent SMB signature of >[0000] 85 6D ED 23 EB 6A 9B 42 .m.#.j.B >smb_signing_md5: sequence number 15 >smb_signing_check_pdu: seq 15: got good SMB signature of >[0000] E3 52 D1 8E FB BD DE 9C .R...... >rpc reply data: >[0000] 00 00 00 00 34 00 00 C0 ....4... >rpc request data: >[0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). &..M..f. >[0010] B3 FE D1 C1 16 00 18 00 00 00 02 00 0E 00 10 00 ........ ........ >[0020] 04 00 02 00 08 00 02 00 03 00 00 00 02 00 00 00 ........ ........ >[0030] 00 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 ........ ........ >[0040] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. r.i.s... >[0050] 63 00 6F 00 6D 00 00 00 08 00 00 00 00 00 00 00 c.o.m... ........ >[0060] 07 00 00 00 53 00 4F 00 4C 00 41 00 52 00 49 00 ....S.O. L.A.R.I. >[0070] 53 00 00 00 04 00 00 00 01 04 00 00 00 00 00 05 S....... ........ >[0080] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... .0l..... >[0090] 40 04 00 00 0C 00 02 00 40 04 00 00 F3 EB B4 CA @....... @....... >[00A0] 99 BB 60 76 9A 51 FD BE 16 00 59 56 14 B8 A4 AF ..`v.Q.. ..YV.... >[00B0] 00 4F 6E C5 95 EE 75 2E BA EF 21 CF 26 B1 9E C5 .On...u. ..!.&... >[00C0] 29 54 05 06 1F EB BF 90 4A F1 88 37 D3 AE B9 FB )T...... J..7.... >[00D0] A0 A4 B7 C5 2A B2 38 60 3D 59 B1 14 19 5D 30 64 ....*.8` =Y...]0d >[00E0] F2 82 6D DC 03 CC 19 CC D5 D1 ED A7 63 40 F0 72 ..m..... ....c at .r >[00F0] E5 80 B2 FB 3E 06 95 45 76 19 0A C8 5A 83 5B 00 ....>..E v...Z.[. >[0100] C7 39 27 83 43 88 98 0F 2B C5 75 D8 4C 3B 61 18 .9'.C... +.u.L;a. >[0110] CF F6 1F BB 31 A9 CD FF 57 F5 EF 0B 81 B9 5F 7E ....1... W....._~ >[0120] 1B 3E 00 11 92 CB 92 8C 29 D5 90 31 B7 39 B1 31 .>...... )..1.9.1 >[0130] 7C C3 0C C8 E5 D0 51 AA 20 D2 A2 39 C1 52 ED 91 |.....Q. ..9.R.. >[0140] 70 27 2F 7C EB 05 8F 91 AA EB 26 13 07 2C FA 62 p'/|.... ..&..,.b >[0150] C3 CB 79 DD B5 DA EC 3E 78 9A D8 A1 AE 64 3C 7F ..y....> x....d<. >[0160] BB CE 06 48 9A 56 6E 22 FC 6D 78 59 63 2F B8 51 ...H.Vn" .mxYc/.Q >[0170] D6 81 91 1D 54 94 2D C7 69 75 B3 E4 F1 77 93 EF ....T.-. iu...w.. >[0180] BB 3E 0E 80 D7 D4 DD A0 DA 3C 10 51 64 5A AA A7 .>...... .<.QdZ.. >[0190] CB AE CE DA BF F8 03 10 5C DB 64 9F 32 94 D4 F2 ........ \.d.2... >[01A0] 67 1F D4 E7 4E 4F A3 DA A3 1A 24 FC 47 C9 73 FD g...NO.. ..$.G.s. >[01B0] AB 70 CB 34 BE 3B FF 12 A9 A3 DA 31 72 41 07 C0 .p.4.;.. ...1rA.. >[01C0] 27 4A FF ED F8 C7 39 FD B6 87 2E 01 F9 0E 27 9F 'J....9. ......'. >[01D0] 22 12 6B B3 A8 27 CB 86 A1 9D 8F D0 7A 70 97 66 ".k..'.. ....zp.f >[01E0] D4 AD 10 FF BF 88 3A 14 A4 D6 74 E4 17 79 E2 79 ......:. ..t..y.y >[01F0] A7 41 0D 2D A6 09 C5 DF 9F 85 C4 C8 E8 28 10 23 .A.-.... .....(.# >[0200] B2 87 1C 8F 82 3E EC F6 BB 51 49 CD EF CF D3 95 .....>.. .QI..... >[0210] 76 E5 A1 7B 6D 42 81 04 81 8D C0 9C 82 13 14 A1 v..{mB.. ........ >[0220] 1C 8B B1 ED 94 D7 41 EF 43 04 49 A5 35 17 17 51 ......A. C.I.5..Q >[0230] C1 D0 27 13 93 6F CF 15 15 E6 C3 32 4D 85 9D E7 ..'..o.. ...2M... >[0240] FF E7 36 D9 3F CE 35 A2 DC 2D AB 06 1E 84 2B 6E ..6.?.5. .-....+n >[0250] 3C D9 BF 3E 01 9E 6B 8B 5D 8D F3 98 F0 AA 1B 62 <..>..k. ]......b >[0260] C4 BD D9 CB F6 F8 77 60 09 3C F1 C7 9B FA BB 6C ......w` .<.....l >[0270] CF A8 6E 7C 6B 4B 20 D3 FB 1A 83 16 CC E1 2C 8D ..n|kK . ......,. >[0280] 1F C0 6C 8F 93 69 7F 24 2C B4 76 9E D4 5E 2D 60 ..l..i.$ ,.v..^-` >[0290] 38 3D 72 D6 07 E0 38 81 52 F1 71 06 23 07 68 18 8=r...8. R.q.#.h. >[02A0] 67 7B D5 56 6B 19 E8 EF 7C 45 BB B3 7C A1 45 71 g{.Vk... |E..|.Eq >[02B0] 1C 2B 27 8D 2D B0 7D 6C 0B 1E 4A 0F EC 39 C0 80 .+'.-.}l ..J..9.. >[02C0] D5 3F A6 A9 01 96 BE 95 D9 8F 79 3C 9B E2 B5 77 .?...... ..y<...w >[02D0] 68 BA 2B B3 F4 53 70 71 3C 78 FC 12 D5 09 3B 4F h.+..Spq [02E0] 54 56 A3 73 63 E7 3A AE 29 F4 64 59 2E 74 BE B9 TV.sc.:. ).dY.t.. >[02F0] 36 57 80 7B C8 5D 7A F1 92 B9 B9 98 33 62 2C 02 6W.{.]z. ....3b,. >[0300] 2E 57 41 01 19 67 51 5D 57 FF FF 78 43 B2 27 00 .WA..gQ] W..xC.'. >[0310] 49 E7 94 17 BC 69 AD 56 7D 51 65 F0 59 DB 41 15 I....i.V }Qe.Y.A. >[0320] 94 8C 69 BE 1E 1D 35 1E 2F 60 EF B4 5C 43 A0 F5 ..i...5. /`..\C.. >[0330] D3 6F 7E A1 42 2D 75 56 37 78 54 F4 9D AA A1 BB .o~.B-uV 7xT..... >[0340] 31 7F DB AF 4A 7D EA 03 B2 64 06 84 F1 69 93 6F 1...J}.. .d...i.o >[0350] D1 26 D6 3C CB E0 6F 8C 72 38 00 65 12 5D 3F 5E .&.<..o. r8.e.]?^ >[0360] 8A 9B 36 AB FB 53 85 19 59 2B D7 9E 4B 9C DE 4E ..6..S.. Y+..K..N >[0370] 6E 9B CA F1 8E CC 25 B5 7D 79 86 F3 0F 2B 9A D3 n.....%. }y...+.. >[0380] 5F 47 6C DC AD 2F 6A 87 04 D1 C3 90 96 13 A0 4D _Gl../j. .......M >[0390] 6A CC 05 74 0C E1 57 26 96 EC 72 53 93 BC 99 FA j..t..W& ..rS.... >[03A0] 4C E9 17 2F 40 A8 B8 0A 77 D1 A5 D6 08 0B A1 69 L../@... w......i >[03B0] 1D D9 3A EE BA A3 20 56 3F B0 48 9A AF EC CE 22 ..:... V ?.H...." >[03C0] 03 B4 CC CF BC A7 38 CB CC 99 A8 CB C7 BE 54 6F ......8. ......To >[03D0] 7B C8 DB 38 52 D5 F4 DB F1 E2 45 7B D1 56 C7 73 {..8R... ..E{.V.s >[03E0] 91 08 64 7A 79 A9 49 3F 7F F4 41 1B 72 CB F0 E0 ..dzy.I? ..A.r... >[03F0] B7 C1 69 50 4C 85 94 6B 75 AA CB BA A5 58 CA 9A ..iPL..k u....X.. >[0400] 84 96 52 AA E2 F0 94 95 65 0A 03 06 C9 A5 A4 3F ..R..... e......? >[0410] 78 46 4D 39 4B 64 88 4B A9 CA BB 2F 7C 65 B4 6E xFM9Kd.K .../|e.n >[0420] D0 3D C7 19 29 50 A6 3D D3 A7 19 7C 9C 7C 82 06 .=..)P.= ...|.|.. >[0430] 2B 3B E3 50 B9 CF 5F 31 03 31 AC 3D CF 57 45 32 +;.P.._1 .1.=.WE2 >[0440] 32 F4 9C 9C 88 EE 93 63 F0 21 41 3A CA BA 22 95 2......c .!A:..". >[0450] 38 DB 0F 10 3A AF C5 74 C7 07 85 B2 07 22 53 8F 8...:..t ....."S. >[0460] 31 74 71 5A E5 92 5B 4E DE F0 DB 38 D9 A0 20 E2 1tqZ..[N ...8.. . >[0470] 39 F7 79 BB B6 92 D0 D5 19 DB 14 EF F6 DD 6A 2C 9.y..... ......j, >[0480] 4A 11 1E F2 DD 89 13 98 7E 19 FC CD 75 BF E8 57 J....... ~...u..W >[0490] A9 EF B3 34 60 01 EF 7B 2C BC E4 8D A7 DD 06 05 ...4`..{ ,....... >[04A0] A8 4B A6 B8 F4 C6 5B B2 AF 4D 3A BB 35 74 18 91 .K....[. .M:.5t.. >[04B0] 54 A2 38 95 F1 8F CD 13 A1 F6 7B 4C 4D A5 04 73 T.8..... ..{LM..s >[04C0] 12 DE DC A5 C9 9E B2 73 53 F2 A9 94 A7 4B 65 52 .......s S....KeR >[04D0] 15 C6 84 70 4A 5B 3E 17 3A 96 AF D1 00 00 01 00 ...pJ[>. :....... >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 >smb_signing_md5: sequence number 16 >smb_signing_sign_pdu: sent SMB signature of >[0000] 22 D2 88 02 E7 0E C2 30 "......0 >smb_signing_md5: sequence number 17 >smb_signing_check_pdu: seq 17: got good SMB signature of >[0000] C7 4B 3C 94 92 8D 79 5F .K<...y_ >rpc reply data: >[0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ >[0010] 00 00 00 00 35 00 00 C0 ....5... >[Wed Mar 18 11:18:04.781985 2015] [:error] [pid 3831] ipa: INFO: >[jsonserver_session] admin at SOLARIS.COM: trust_add(u'infra.com', >trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', >all=False, raw=False, version=u'2.113'): RemoteRetrieveError >-- >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 -- / Alexander Bokovoy From bentech4you at gmail.com Wed Mar 18 09:21:03 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 12:21:03 +0300 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: <20150318091500.GZ3878@redhat.com> References: <20150318091500.GZ3878@redhat.com> Message-ID: HI thanks for the reply i have created PTR record for IPA server under reverse lookup zone manually and ipa server resolving from AD how can i solve trhis issue.? On Wed, Mar 18, 2015 at 12:15 PM, Alexander Bokovoy wrote: > On Wed, 18 Mar 2015, Ben .T.George wrote: > >> Hi >> >> i am getting "ipa: ERROR: CIFS server communication error: code >> "-1073741771"," >> >> while doing >> >> [root at kwtpocpbis02 ~]# ipa trust-add --type=ad infra.com --admin >> Administrator --password >> Active Directory domain administrator's password: >> ipa: ERROR: CIFS server communication error: code "-1073741771", >> message "NT_STATUS_OBJECT_NAME_COLLISION" (both may be >> "None") >> >> i am using centos 7 and IPA 4.1.2 >> > NT_STATUS_OBJECT_NAME_COLLISION means AD thinks you have hosts in AD > that belong to the solaris.com domain which 'trust-ad' operation claims > to belong to IPA realm. AD denies operating the trust in this case. > > > >> IPA Server >> >> [root at kwtpocpbis02 ~]# host kwtpocpbis02.solaris.com >> kwtpocpbis02.solaris.com has address 172.16.107.135 >> [root at kwtpocpbis02 ~]# host 172.16.107.135 >> 135.107.16.172.in-addr.arpa domain name pointer kwtpocpbis02.solaris.com. >> >> >> AD >> >> [root at kwtpocpbis02 ~]# host 172.16.107.250 >> 250.107.16.172.in-addr.arpa domain name pointer kwtipaad001.infra.com. >> [root at kwtpocpbis02 ~]# host kwtipaad001.infra.com >> kwtipaad001.infra.com has address 172.16.107.250 >> >> debugging is enabled and this is i am getting on error_log >> >> INFO: Current debug levels: >> all: 11 >> tdb: 11 >> printdrivers: 11 >> lanman: 11 >> smb: 11 >> rpc_parse: 11 >> rpc_srv: 11 >> rpc_cli: 11 >> passdb: 11 >> sam: 11 >> auth: 11 >> winbind: 11 >> vfs: 11 >> idmap: 11 >> quota: 11 >> acls: 11 >> locking: 11 >> msdfs: 11 >> dmapi: 11 >> registry: 11 >> scavenger: 11 >> dns: 11 >> ldb: 11 >> pm_process() returned Yes >> GENSEC backend 'gssapi_spnego' registered >> GENSEC backend 'gssapi_krb5' registered >> GENSEC backend 'gssapi_krb5_sasl' registered >> GENSEC backend 'sasl-DIGEST-MD5' registered >> GENSEC backend 'schannel' registered >> GENSEC backend 'spnego' registered >> GENSEC backend 'ntlmssp' registered >> Using binding ncacn_np:kwtpocpbis02.solaris.com[,] >> Mapped to DCERPC endpoint \pipe\lsarpc >> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >> netmask=255.255.255.0 >> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >> netmask=255.255.255.0 >> Socket options: >> SO_KEEPALIVE = 0 >> SO_REUSEADDR = 0 >> SO_BROADCAST = 0 >> TCP_NODELAY = 1 >> TCP_KEEPCNT = 9 >> TCP_KEEPIDLE = 7200 >> TCP_KEEPINTVL = 75 >> IPTOS_LOWDELAY = 0 >> IPTOS_THROUGHPUT = 0 >> SO_REUSEPORT = 0 >> SO_SNDBUF = 663430 >> SO_RCVBUF = 261942 >> SO_SNDLOWAT = 1 >> SO_RCVLOWAT = 1 >> SO_SNDTIMEO = 0 >> SO_RCVTIMEO = 0 >> TCP_QUICKACK = 1 >> TCP_DEFER_ACCEPT = 0 >> Starting GENSEC mechanism spnego >> Starting GENSEC submechanism gssapi_krb5 >> Ticket in credentials cache for admin at SOLARIS.COM will expire in 81540 >> secs >> gensec_gssapi: NO credentials were delegated >> GSSAPI Connection will be cryptographically sealed >> 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 >> 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 ........ >> 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 >> rpc reply data: >> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >> .....U.4 >> [0010] 2E 0F 00 00 00 00 00 00 ........ >> rpc request data: >> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >> .....U.4 >> [0010] 2E 0F 00 00 0C 00 ...... >> 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 >> rpc reply data: >> [0000] 00 00 02 00 0C 00 00 00 0E 00 10 00 04 00 02 00 ........ >> ........ >> [0010] 16 00 18 00 08 00 02 00 16 00 18 00 0C 00 02 00 ........ >> ........ >> [0020] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... >> .0l..... >> [0030] 10 00 02 00 08 00 00 00 00 00 00 00 07 00 00 00 ........ >> ........ >> [0040] 53 00 4F 00 4C 00 41 00 52 00 49 00 53 00 00 00 S.O.L.A. >> R.I.S... >> [0050] 0C 00 00 00 00 00 00 00 0B 00 00 00 73 00 6F 00 ........ >> ....s.o. >> [0060] 6C 00 61 00 72 00 69 00 73 00 2E 00 63 00 6F 00 l.a.r.i. >> s...c.o. >> [0070] 6D 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 m....... >> ........ >> [0080] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. >> r.i.s... >> [0090] 63 00 6F 00 6D 00 00 00 04 00 00 00 01 04 00 00 c.o.m... >> ........ >> [00A0] 00 00 00 05 15 00 00 00 5F 89 A9 B4 86 30 6C 9D ........ >> _....0l. >> [00B0] B4 09 10 02 00 00 00 00 ........ >> rpc request data: >> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >> .....U.4 >> [0010] 2E 0F 00 00 06 00 ...... >> 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 >> 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: 11 >> tdb: 11 >> printdrivers: 11 >> lanman: 11 >> smb: 11 >> rpc_parse: 11 >> rpc_srv: 11 >> rpc_cli: 11 >> passdb: 11 >> sam: 11 >> auth: 11 >> winbind: 11 >> vfs: 11 >> idmap: 11 >> quota: 11 >> acls: 11 >> locking: 11 >> msdfs: 11 >> dmapi: 11 >> registry: 11 >> scavenger: 11 >> dns: 11 >> ldb: 11 >> pm_process() returned Yes >> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >> netmask=255.255.255.0 >> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >> netmask=255.255.255.0 >> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >> netmask=255.255.255.0 >> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >> netmask=255.255.255.0 >> finddcs: searching for a DC by DNS domain infra.com >> finddcs: looking for SRV records for _ldap._tcp.infra.com >> ads_dns_lookup_srv: 1 records returned in the answer section. >> ads_dns_parse_rr_srv: Parsed kwtipaad001.infra.com [0, 100, 389] >> Addrs = 172.16.107.250 at 389/kwtipaad001 >> finddcs: DNS SRV response 0 at '172.16.107.250' >> finddcs: performing CLDAP query on 172.16.107.250 >> &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX >> command : LOGON_SAM_LOGON_RESPONSE_EX (23) >> sbz : 0x0000 (0) >> server_type : 0x000033fd (13309) >> 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 >> 1: 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 : 2b3fba2e-3635-4e27-90d3-be555b96aea1 >> forest : 'infra.com' >> dns_domain : 'infra.com' >> pdc_dns_name : 'kwtipaad001.infra.com' >> domain_name : 'INFRA' >> pdc_name : 'KWTIPAAD001' >> 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 172.16.107.250 with server_type=0x000033fd >> 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: 11 >> tdb: 11 >> printdrivers: 11 >> lanman: 11 >> smb: 11 >> rpc_parse: 11 >> rpc_srv: 11 >> rpc_cli: 11 >> passdb: 11 >> sam: 11 >> auth: 11 >> winbind: 11 >> vfs: 11 >> idmap: 11 >> quota: 11 >> acls: 11 >> locking: 11 >> msdfs: 11 >> dmapi: 11 >> registry: 11 >> scavenger: 11 >> dns: 11 >> ldb: 11 >> pm_process() returned Yes >> Using binding ncacn_np:kwtipaad001.infra.com[,] >> Mapped to DCERPC endpoint \pipe\lsarpc >> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >> netmask=255.255.255.0 >> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >> netmask=255.255.255.0 >> Socket options: >> SO_KEEPALIVE = 0 >> SO_REUSEADDR = 0 >> SO_BROADCAST = 0 >> TCP_NODELAY = 1 >> TCP_KEEPCNT = 9 >> TCP_KEEPIDLE = 7200 >> TCP_KEEPINTVL = 75 >> IPTOS_LOWDELAY = 0 >> IPTOS_THROUGHPUT = 0 >> SO_REUSEPORT = 0 >> SO_SNDBUF = 23080 >> SO_RCVBUF = 87380 >> SO_SNDLOWAT = 1 >> SO_RCVLOWAT = 1 >> SO_SNDTIMEO = 0 >> SO_RCVTIMEO = 0 >> TCP_QUICKACK = 1 >> TCP_DEFER_ACCEPT = 0 >> Starting GENSEC mechanism spnego >> Starting GENSEC submechanism 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 : 0x0007 (7) >> DomainNameMaxLen : 0x0007 (7) >> DomainName : * >> DomainName : 'SOLARIS' >> WorkstationLen : 0x0007 (7) >> WorkstationMaxLen : 0x0007 (7) >> Workstation : * >> Workstation : 'SOLARIS' >> smb_signing_sign_pdu: sent SMB signature of >> [0000] 42 53 52 53 50 59 4C 20 BSRSPYL >> 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 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] 42 53 52 53 50 59 4C 20 BSRSPYL >> smb_signing_activate: user_session_key >> [0000] 23 27 C0 93 E7 C8 7F B9 47 A9 FD 91 F7 73 10 6E #'...... >> G....s.n >> smb_signing_activate: NULL response_data >> smb_signing_md5: sequence number 1 >> smb_signing_check_pdu: seq 1: got good SMB signature of >> [0000] 71 D6 FE AD D8 76 9E B9 q....v.. >> smb_signing_md5: sequence number 2 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] 07 24 9E 31 C2 C8 37 9D .$.1..7. >> smb_signing_md5: sequence number 3 >> smb_signing_check_pdu: seq 3: got good SMB signature of >> [0000] 7E F4 97 77 31 32 74 F7 ~..w12t. >> smb_signing_md5: sequence number 4 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] 26 96 4E B8 AF B2 5C EB &.N...\. >> smb_signing_md5: sequence number 5 >> smb_signing_check_pdu: seq 5: got good SMB signature of >> [0000] 77 EE BD 92 63 7A F7 86 w...cz.. >> 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 >> smb_signing_md5: sequence number 6 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] F2 49 18 60 8B 96 22 FB .I.`..". >> smb_signing_md5: sequence number 7 >> smb_signing_check_pdu: seq 7: got good SMB signature of >> [0000] 74 CA 84 E8 F0 2B 5F 93 t....+_. >> 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 ........ >> 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 >> smb_signing_md5: sequence number 8 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] AC 94 11 10 43 F9 1B A8 ....C... >> smb_signing_md5: sequence number 9 >> smb_signing_check_pdu: seq 9: got good SMB signature of >> [0000] CD B6 5D F7 6A 95 70 B9 ..].j.p. >> rpc reply data: >> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >> &..M..f. >> [0010] B3 FE D1 C1 00 00 00 00 ........ >> rpc request data: >> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >> &..M..f. >> [0010] B3 FE D1 C1 0C 00 ...... >> 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 >> smb_signing_md5: sequence number 10 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] 32 2D 66 66 C2 FD C7 AF 2-ff.... >> smb_signing_md5: sequence number 11 >> smb_signing_check_pdu: seq 11: got good SMB signature of >> [0000] DD 3C 1D 35 CD 94 09 88 .<.5.... >> rpc reply data: >> [0000] 00 00 02 00 0C 00 00 00 0A 00 0C 00 04 00 02 00 ........ >> ........ >> [0010] 12 00 14 00 08 00 02 00 12 00 14 00 0C 00 02 00 ........ >> ........ >> [0020] 2E BA 3F 2B 35 36 27 4E 90 D3 BE 55 5B 96 AE A1 ..?+56'N >> ...U[... >> [0030] 10 00 02 00 06 00 00 00 00 00 00 00 05 00 00 00 ........ >> ........ >> [0040] 49 00 4E 00 46 00 52 00 41 00 00 00 0A 00 00 00 I.N.F.R. >> A....... >> [0050] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ >> i.n.f.r. >> [0060] 61 00 2E 00 63 00 6F 00 6D 00 00 00 0A 00 00 00 a...c.o. >> m....... >> [0070] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ >> i.n.f.r. >> [0080] 61 00 2E 00 63 00 6F 00 6D 00 00 00 04 00 00 00 a...c.o. >> m....... >> [0090] 01 04 00 00 00 00 00 05 15 00 00 00 05 CF 66 0B ........ >> ......f. >> [00A0] 52 91 25 EF 02 4B 1B D6 00 00 00 00 R.%..K.. .... >> rpc request data: >> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >> &..M..f. >> [0010] B3 FE D1 C1 06 00 ...... >> 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 >> smb_signing_md5: sequence number 12 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] 62 FA 51 B6 49 8C 2D 73 b.Q.I.-s >> smb_signing_md5: sequence number 13 >> smb_signing_check_pdu: seq 13: got good SMB signature of >> [0000] 4A E8 4A EB 69 A4 EC 5D J.J.i..] >> rpc reply data: >> [0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ >> ........ >> rpc request data: >> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >> &..M..f. >> [0010] B3 FE D1 C1 16 00 16 00 00 00 02 00 0B 00 00 00 ........ >> ........ >> [0020] 00 00 00 00 0B 00 00 00 73 00 6F 00 6C 00 61 00 ........ >> s.o.l.a. >> [0030] 72 00 69 00 73 00 2E 00 63 00 6F 00 6D 00 08 00 r.i.s... >> c.o.m... >> 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 >> smb_signing_md5: sequence number 14 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] 85 6D ED 23 EB 6A 9B 42 .m.#.j.B >> smb_signing_md5: sequence number 15 >> smb_signing_check_pdu: seq 15: got good SMB signature of >> [0000] E3 52 D1 8E FB BD DE 9C .R...... >> rpc reply data: >> [0000] 00 00 00 00 34 00 00 C0 ....4... >> rpc request data: >> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >> &..M..f. >> [0010] B3 FE D1 C1 16 00 18 00 00 00 02 00 0E 00 10 00 ........ >> ........ >> [0020] 04 00 02 00 08 00 02 00 03 00 00 00 02 00 00 00 ........ >> ........ >> [0030] 00 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 ........ >> ........ >> [0040] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. >> r.i.s... >> [0050] 63 00 6F 00 6D 00 00 00 08 00 00 00 00 00 00 00 c.o.m... >> ........ >> [0060] 07 00 00 00 53 00 4F 00 4C 00 41 00 52 00 49 00 ....S.O. >> L.A.R.I. >> [0070] 53 00 00 00 04 00 00 00 01 04 00 00 00 00 00 05 S....... >> ........ >> [0080] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... >> .0l..... >> [0090] 40 04 00 00 0C 00 02 00 40 04 00 00 F3 EB B4 CA @....... >> @....... >> [00A0] 99 BB 60 76 9A 51 FD BE 16 00 59 56 14 B8 A4 AF ..`v.Q.. >> ..YV.... >> [00B0] 00 4F 6E C5 95 EE 75 2E BA EF 21 CF 26 B1 9E C5 .On...u. >> ..!.&... >> [00C0] 29 54 05 06 1F EB BF 90 4A F1 88 37 D3 AE B9 FB )T...... >> J..7.... >> [00D0] A0 A4 B7 C5 2A B2 38 60 3D 59 B1 14 19 5D 30 64 ....*.8` >> =Y...]0d >> [00E0] F2 82 6D DC 03 CC 19 CC D5 D1 ED A7 63 40 F0 72 ..m..... ....c@ >> .r >> [00F0] E5 80 B2 FB 3E 06 95 45 76 19 0A C8 5A 83 5B 00 ....>..E >> v...Z.[. >> [0100] C7 39 27 83 43 88 98 0F 2B C5 75 D8 4C 3B 61 18 .9'.C... >> +.u.L;a. >> [0110] CF F6 1F BB 31 A9 CD FF 57 F5 EF 0B 81 B9 5F 7E ....1... >> W....._~ >> [0120] 1B 3E 00 11 92 CB 92 8C 29 D5 90 31 B7 39 B1 31 .>...... >> )..1.9.1 >> [0130] 7C C3 0C C8 E5 D0 51 AA 20 D2 A2 39 C1 52 ED 91 |.....Q. >> ..9.R.. >> [0140] 70 27 2F 7C EB 05 8F 91 AA EB 26 13 07 2C FA 62 p'/|.... >> ..&..,.b >> [0150] C3 CB 79 DD B5 DA EC 3E 78 9A D8 A1 AE 64 3C 7F ..y....> >> x....d<. >> [0160] BB CE 06 48 9A 56 6E 22 FC 6D 78 59 63 2F B8 51 ...H.Vn" >> .mxYc/.Q >> [0170] D6 81 91 1D 54 94 2D C7 69 75 B3 E4 F1 77 93 EF ....T.-. >> iu...w.. >> [0180] BB 3E 0E 80 D7 D4 DD A0 DA 3C 10 51 64 5A AA A7 .>...... >> .<.QdZ.. >> [0190] CB AE CE DA BF F8 03 10 5C DB 64 9F 32 94 D4 F2 ........ >> \.d.2... >> [01A0] 67 1F D4 E7 4E 4F A3 DA A3 1A 24 FC 47 C9 73 FD g...NO.. >> ..$.G.s. >> [01B0] AB 70 CB 34 BE 3B FF 12 A9 A3 DA 31 72 41 07 C0 .p.4.;.. >> ...1rA.. >> [01C0] 27 4A FF ED F8 C7 39 FD B6 87 2E 01 F9 0E 27 9F 'J....9. >> ......'. >> [01D0] 22 12 6B B3 A8 27 CB 86 A1 9D 8F D0 7A 70 97 66 ".k..'.. >> ....zp.f >> [01E0] D4 AD 10 FF BF 88 3A 14 A4 D6 74 E4 17 79 E2 79 ......:. >> ..t..y.y >> [01F0] A7 41 0D 2D A6 09 C5 DF 9F 85 C4 C8 E8 28 10 23 .A.-.... >> .....(.# >> [0200] B2 87 1C 8F 82 3E EC F6 BB 51 49 CD EF CF D3 95 .....>.. >> .QI..... >> [0210] 76 E5 A1 7B 6D 42 81 04 81 8D C0 9C 82 13 14 A1 v..{mB.. >> ........ >> [0220] 1C 8B B1 ED 94 D7 41 EF 43 04 49 A5 35 17 17 51 ......A. >> C.I.5..Q >> [0230] C1 D0 27 13 93 6F CF 15 15 E6 C3 32 4D 85 9D E7 ..'..o.. >> ...2M... >> [0240] FF E7 36 D9 3F CE 35 A2 DC 2D AB 06 1E 84 2B 6E ..6.?.5. >> .-....+n >> [0250] 3C D9 BF 3E 01 9E 6B 8B 5D 8D F3 98 F0 AA 1B 62 <..>..k. >> ]......b >> [0260] C4 BD D9 CB F6 F8 77 60 09 3C F1 C7 9B FA BB 6C ......w` >> .<.....l >> [0270] CF A8 6E 7C 6B 4B 20 D3 FB 1A 83 16 CC E1 2C 8D ..n|kK . >> ......,. >> [0280] 1F C0 6C 8F 93 69 7F 24 2C B4 76 9E D4 5E 2D 60 ..l..i.$ >> ,.v..^-` >> [0290] 38 3D 72 D6 07 E0 38 81 52 F1 71 06 23 07 68 18 8=r...8. >> R.q.#.h. >> [02A0] 67 7B D5 56 6B 19 E8 EF 7C 45 BB B3 7C A1 45 71 g{.Vk... >> |E..|.Eq >> [02B0] 1C 2B 27 8D 2D B0 7D 6C 0B 1E 4A 0F EC 39 C0 80 .+'.-.}l >> ..J..9.. >> [02C0] D5 3F A6 A9 01 96 BE 95 D9 8F 79 3C 9B E2 B5 77 .?...... >> ..y<...w >> [02D0] 68 BA 2B B3 F4 53 70 71 3C 78 FC 12 D5 09 3B 4F h.+..Spq >> > [02E0] 54 56 A3 73 63 E7 3A AE 29 F4 64 59 2E 74 BE B9 TV.sc.:. >> ).dY.t.. >> [02F0] 36 57 80 7B C8 5D 7A F1 92 B9 B9 98 33 62 2C 02 6W.{.]z. >> ....3b,. >> [0300] 2E 57 41 01 19 67 51 5D 57 FF FF 78 43 B2 27 00 .WA..gQ] >> W..xC.'. >> [0310] 49 E7 94 17 BC 69 AD 56 7D 51 65 F0 59 DB 41 15 I....i.V >> }Qe.Y.A. >> [0320] 94 8C 69 BE 1E 1D 35 1E 2F 60 EF B4 5C 43 A0 F5 ..i...5. >> /`..\C.. >> [0330] D3 6F 7E A1 42 2D 75 56 37 78 54 F4 9D AA A1 BB .o~.B-uV >> 7xT..... >> [0340] 31 7F DB AF 4A 7D EA 03 B2 64 06 84 F1 69 93 6F 1...J}.. >> .d...i.o >> [0350] D1 26 D6 3C CB E0 6F 8C 72 38 00 65 12 5D 3F 5E .&.<..o. >> r8.e.]?^ >> [0360] 8A 9B 36 AB FB 53 85 19 59 2B D7 9E 4B 9C DE 4E ..6..S.. >> Y+..K..N >> [0370] 6E 9B CA F1 8E CC 25 B5 7D 79 86 F3 0F 2B 9A D3 n.....%. >> }y...+.. >> [0380] 5F 47 6C DC AD 2F 6A 87 04 D1 C3 90 96 13 A0 4D _Gl../j. >> .......M >> [0390] 6A CC 05 74 0C E1 57 26 96 EC 72 53 93 BC 99 FA j..t..W& >> ..rS.... >> [03A0] 4C E9 17 2F 40 A8 B8 0A 77 D1 A5 D6 08 0B A1 69 L../@... >> w......i >> [03B0] 1D D9 3A EE BA A3 20 56 3F B0 48 9A AF EC CE 22 ..:... V >> ?.H...." >> [03C0] 03 B4 CC CF BC A7 38 CB CC 99 A8 CB C7 BE 54 6F ......8. >> ......To >> [03D0] 7B C8 DB 38 52 D5 F4 DB F1 E2 45 7B D1 56 C7 73 {..8R... >> ..E{.V.s >> [03E0] 91 08 64 7A 79 A9 49 3F 7F F4 41 1B 72 CB F0 E0 ..dzy.I? >> ..A.r... >> [03F0] B7 C1 69 50 4C 85 94 6B 75 AA CB BA A5 58 CA 9A ..iPL..k >> u....X.. >> [0400] 84 96 52 AA E2 F0 94 95 65 0A 03 06 C9 A5 A4 3F ..R..... >> e......? >> [0410] 78 46 4D 39 4B 64 88 4B A9 CA BB 2F 7C 65 B4 6E xFM9Kd.K >> .../|e.n >> [0420] D0 3D C7 19 29 50 A6 3D D3 A7 19 7C 9C 7C 82 06 .=..)P.= >> ...|.|.. >> [0430] 2B 3B E3 50 B9 CF 5F 31 03 31 AC 3D CF 57 45 32 +;.P.._1 >> .1.=.WE2 >> [0440] 32 F4 9C 9C 88 EE 93 63 F0 21 41 3A CA BA 22 95 2......c >> .!A:..". >> [0450] 38 DB 0F 10 3A AF C5 74 C7 07 85 B2 07 22 53 8F 8...:..t >> ....."S. >> [0460] 31 74 71 5A E5 92 5B 4E DE F0 DB 38 D9 A0 20 E2 1tqZ..[N >> ...8.. . >> [0470] 39 F7 79 BB B6 92 D0 D5 19 DB 14 EF F6 DD 6A 2C 9.y..... >> ......j, >> [0480] 4A 11 1E F2 DD 89 13 98 7E 19 FC CD 75 BF E8 57 J....... >> ~...u..W >> [0490] A9 EF B3 34 60 01 EF 7B 2C BC E4 8D A7 DD 06 05 ...4`..{ >> ,....... >> [04A0] A8 4B A6 B8 F4 C6 5B B2 AF 4D 3A BB 35 74 18 91 .K....[. >> .M:.5t.. >> [04B0] 54 A2 38 95 F1 8F CD 13 A1 F6 7B 4C 4D A5 04 73 T.8..... >> ..{LM..s >> [04C0] 12 DE DC A5 C9 9E B2 73 53 F2 A9 94 A7 4B 65 52 .......s >> S....KeR >> [04D0] 15 C6 84 70 4A 5B 3E 17 3A 96 AF D1 00 00 01 00 ...pJ[>. >> :....... >> 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 >> smb_signing_md5: sequence number 16 >> smb_signing_sign_pdu: sent SMB signature of >> [0000] 22 D2 88 02 E7 0E C2 30 "......0 >> smb_signing_md5: sequence number 17 >> smb_signing_check_pdu: seq 17: got good SMB signature of >> [0000] C7 4B 3C 94 92 8D 79 5F .K<...y_ >> rpc reply data: >> [0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ >> ........ >> [0010] 00 00 00 00 35 00 00 C0 ....5... >> [Wed Mar 18 11:18:04.781985 2015] [:error] [pid 3831] ipa: INFO: >> [jsonserver_session] admin at SOLARIS.COM: trust_add(u'infra.com', >> trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', >> all=False, raw=False, version=u'2.113'): RemoteRetrieveError >> > > -- >> 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 >> > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Wed Mar 18 09:24:29 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 12:24:29 +0300 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: References: <20150318091500.GZ3878@redhat.com> Message-ID: this is the result from AD C:\Users\Administrator>nslookup Default Server: localhost Address: 127.0.0.1 > set type=srv > _ldap._tcp.infra.com Server: localhost Address: 127.0.0.1 _ldap._tcp.infra.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = kwtipaad001.infra.com kwtipaad001.infra.com internet address = 172.16.107.250 > _ldap._tcp.solaris.com Server: localhost Address: 127.0.0.1 Non-authoritative answer: _ldap._tcp.solaris.com SRV service location: priority = 0 weight = 100 port = 389 svr hostname = kwtpocpbis02.solaris.com kwtpocpbis02.solaris.com internet address = 172.16.107.135 On Wed, Mar 18, 2015 at 12:21 PM, Ben .T.George wrote: > HI > > thanks for the reply > > i have created PTR record for IPA server under reverse lookup zone > manually and ipa server resolving from AD > > how can i solve trhis issue.? > > > > On Wed, Mar 18, 2015 at 12:15 PM, Alexander Bokovoy > wrote: > >> On Wed, 18 Mar 2015, Ben .T.George wrote: >> >>> Hi >>> >>> i am getting "ipa: ERROR: CIFS server communication error: code >>> "-1073741771"," >>> >>> while doing >>> >>> [root at kwtpocpbis02 ~]# ipa trust-add --type=ad infra.com --admin >>> Administrator --password >>> Active Directory domain administrator's password: >>> ipa: ERROR: CIFS server communication error: code "-1073741771", >>> message "NT_STATUS_OBJECT_NAME_COLLISION" (both may be >>> "None") >>> >>> i am using centos 7 and IPA 4.1.2 >>> >> NT_STATUS_OBJECT_NAME_COLLISION means AD thinks you have hosts in AD >> that belong to the solaris.com domain which 'trust-ad' operation claims >> to belong to IPA realm. AD denies operating the trust in this case. >> >> >> >>> IPA Server >>> >>> [root at kwtpocpbis02 ~]# host kwtpocpbis02.solaris.com >>> kwtpocpbis02.solaris.com has address 172.16.107.135 >>> [root at kwtpocpbis02 ~]# host 172.16.107.135 >>> 135.107.16.172.in-addr.arpa domain name pointer kwtpocpbis02.solaris.com >>> . >>> >>> >>> AD >>> >>> [root at kwtpocpbis02 ~]# host 172.16.107.250 >>> 250.107.16.172.in-addr.arpa domain name pointer kwtipaad001.infra.com. >>> [root at kwtpocpbis02 ~]# host kwtipaad001.infra.com >>> kwtipaad001.infra.com has address 172.16.107.250 >>> >>> debugging is enabled and this is i am getting on error_log >>> >>> INFO: Current debug levels: >>> all: 11 >>> tdb: 11 >>> printdrivers: 11 >>> lanman: 11 >>> smb: 11 >>> rpc_parse: 11 >>> rpc_srv: 11 >>> rpc_cli: 11 >>> passdb: 11 >>> sam: 11 >>> auth: 11 >>> winbind: 11 >>> vfs: 11 >>> idmap: 11 >>> quota: 11 >>> acls: 11 >>> locking: 11 >>> msdfs: 11 >>> dmapi: 11 >>> registry: 11 >>> scavenger: 11 >>> dns: 11 >>> ldb: 11 >>> pm_process() returned Yes >>> GENSEC backend 'gssapi_spnego' registered >>> GENSEC backend 'gssapi_krb5' registered >>> GENSEC backend 'gssapi_krb5_sasl' registered >>> GENSEC backend 'sasl-DIGEST-MD5' registered >>> GENSEC backend 'schannel' registered >>> GENSEC backend 'spnego' registered >>> GENSEC backend 'ntlmssp' registered >>> Using binding ncacn_np:kwtpocpbis02.solaris.com[,] >>> Mapped to DCERPC endpoint \pipe\lsarpc >>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>> netmask=255.255.255.0 >>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>> netmask=255.255.255.0 >>> Socket options: >>> SO_KEEPALIVE = 0 >>> SO_REUSEADDR = 0 >>> SO_BROADCAST = 0 >>> TCP_NODELAY = 1 >>> TCP_KEEPCNT = 9 >>> TCP_KEEPIDLE = 7200 >>> TCP_KEEPINTVL = 75 >>> IPTOS_LOWDELAY = 0 >>> IPTOS_THROUGHPUT = 0 >>> SO_REUSEPORT = 0 >>> SO_SNDBUF = 663430 >>> SO_RCVBUF = 261942 >>> SO_SNDLOWAT = 1 >>> SO_RCVLOWAT = 1 >>> SO_SNDTIMEO = 0 >>> SO_RCVTIMEO = 0 >>> TCP_QUICKACK = 1 >>> TCP_DEFER_ACCEPT = 0 >>> Starting GENSEC mechanism spnego >>> Starting GENSEC submechanism gssapi_krb5 >>> Ticket in credentials cache for admin at SOLARIS.COM will expire in 81540 >>> secs >>> gensec_gssapi: NO credentials were delegated >>> GSSAPI Connection will be cryptographically sealed >>> 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 >>> 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 ........ >>> 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 >>> rpc reply data: >>> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >>> .....U.4 >>> [0010] 2E 0F 00 00 00 00 00 00 ........ >>> rpc request data: >>> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >>> .....U.4 >>> [0010] 2E 0F 00 00 0C 00 ...... >>> 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 >>> rpc reply data: >>> [0000] 00 00 02 00 0C 00 00 00 0E 00 10 00 04 00 02 00 ........ >>> ........ >>> [0010] 16 00 18 00 08 00 02 00 16 00 18 00 0C 00 02 00 ........ >>> ........ >>> [0020] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... >>> .0l..... >>> [0030] 10 00 02 00 08 00 00 00 00 00 00 00 07 00 00 00 ........ >>> ........ >>> [0040] 53 00 4F 00 4C 00 41 00 52 00 49 00 53 00 00 00 S.O.L.A. >>> R.I.S... >>> [0050] 0C 00 00 00 00 00 00 00 0B 00 00 00 73 00 6F 00 ........ >>> ....s.o. >>> [0060] 6C 00 61 00 72 00 69 00 73 00 2E 00 63 00 6F 00 l.a.r.i. >>> s...c.o. >>> [0070] 6D 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 m....... >>> ........ >>> [0080] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. >>> r.i.s... >>> [0090] 63 00 6F 00 6D 00 00 00 04 00 00 00 01 04 00 00 c.o.m... >>> ........ >>> [00A0] 00 00 00 05 15 00 00 00 5F 89 A9 B4 86 30 6C 9D ........ >>> _....0l. >>> [00B0] B4 09 10 02 00 00 00 00 ........ >>> rpc request data: >>> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >>> .....U.4 >>> [0010] 2E 0F 00 00 06 00 ...... >>> 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 >>> 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: 11 >>> tdb: 11 >>> printdrivers: 11 >>> lanman: 11 >>> smb: 11 >>> rpc_parse: 11 >>> rpc_srv: 11 >>> rpc_cli: 11 >>> passdb: 11 >>> sam: 11 >>> auth: 11 >>> winbind: 11 >>> vfs: 11 >>> idmap: 11 >>> quota: 11 >>> acls: 11 >>> locking: 11 >>> msdfs: 11 >>> dmapi: 11 >>> registry: 11 >>> scavenger: 11 >>> dns: 11 >>> ldb: 11 >>> pm_process() returned Yes >>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>> netmask=255.255.255.0 >>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>> netmask=255.255.255.0 >>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>> netmask=255.255.255.0 >>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>> netmask=255.255.255.0 >>> finddcs: searching for a DC by DNS domain infra.com >>> finddcs: looking for SRV records for _ldap._tcp.infra.com >>> ads_dns_lookup_srv: 1 records returned in the answer section. >>> ads_dns_parse_rr_srv: Parsed kwtipaad001.infra.com [0, 100, 389] >>> Addrs = 172.16.107.250 at 389/kwtipaad001 >>> finddcs: DNS SRV response 0 at '172.16.107.250' >>> finddcs: performing CLDAP query on 172.16.107.250 >>> &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX >>> command : LOGON_SAM_LOGON_RESPONSE_EX (23) >>> sbz : 0x0000 (0) >>> server_type : 0x000033fd (13309) >>> 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 >>> 1: 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 : 2b3fba2e-3635-4e27-90d3-be555b96aea1 >>> forest : 'infra.com' >>> dns_domain : 'infra.com' >>> pdc_dns_name : 'kwtipaad001.infra.com' >>> domain_name : 'INFRA' >>> pdc_name : 'KWTIPAAD001' >>> 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 172.16.107.250 with server_type=0x000033fd >>> 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: 11 >>> tdb: 11 >>> printdrivers: 11 >>> lanman: 11 >>> smb: 11 >>> rpc_parse: 11 >>> rpc_srv: 11 >>> rpc_cli: 11 >>> passdb: 11 >>> sam: 11 >>> auth: 11 >>> winbind: 11 >>> vfs: 11 >>> idmap: 11 >>> quota: 11 >>> acls: 11 >>> locking: 11 >>> msdfs: 11 >>> dmapi: 11 >>> registry: 11 >>> scavenger: 11 >>> dns: 11 >>> ldb: 11 >>> pm_process() returned Yes >>> Using binding ncacn_np:kwtipaad001.infra.com[,] >>> Mapped to DCERPC endpoint \pipe\lsarpc >>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>> netmask=255.255.255.0 >>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>> netmask=255.255.255.0 >>> Socket options: >>> SO_KEEPALIVE = 0 >>> SO_REUSEADDR = 0 >>> SO_BROADCAST = 0 >>> TCP_NODELAY = 1 >>> TCP_KEEPCNT = 9 >>> TCP_KEEPIDLE = 7200 >>> TCP_KEEPINTVL = 75 >>> IPTOS_LOWDELAY = 0 >>> IPTOS_THROUGHPUT = 0 >>> SO_REUSEPORT = 0 >>> SO_SNDBUF = 23080 >>> SO_RCVBUF = 87380 >>> SO_SNDLOWAT = 1 >>> SO_RCVLOWAT = 1 >>> SO_SNDTIMEO = 0 >>> SO_RCVTIMEO = 0 >>> TCP_QUICKACK = 1 >>> TCP_DEFER_ACCEPT = 0 >>> Starting GENSEC mechanism spnego >>> Starting GENSEC submechanism 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 : 0x0007 (7) >>> DomainNameMaxLen : 0x0007 (7) >>> DomainName : * >>> DomainName : 'SOLARIS' >>> WorkstationLen : 0x0007 (7) >>> WorkstationMaxLen : 0x0007 (7) >>> Workstation : * >>> Workstation : 'SOLARIS' >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] 42 53 52 53 50 59 4C 20 BSRSPYL >>> 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 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] 42 53 52 53 50 59 4C 20 BSRSPYL >>> smb_signing_activate: user_session_key >>> [0000] 23 27 C0 93 E7 C8 7F B9 47 A9 FD 91 F7 73 10 6E #'...... >>> G....s.n >>> smb_signing_activate: NULL response_data >>> smb_signing_md5: sequence number 1 >>> smb_signing_check_pdu: seq 1: got good SMB signature of >>> [0000] 71 D6 FE AD D8 76 9E B9 q....v.. >>> smb_signing_md5: sequence number 2 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] 07 24 9E 31 C2 C8 37 9D .$.1..7. >>> smb_signing_md5: sequence number 3 >>> smb_signing_check_pdu: seq 3: got good SMB signature of >>> [0000] 7E F4 97 77 31 32 74 F7 ~..w12t. >>> smb_signing_md5: sequence number 4 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] 26 96 4E B8 AF B2 5C EB &.N...\. >>> smb_signing_md5: sequence number 5 >>> smb_signing_check_pdu: seq 5: got good SMB signature of >>> [0000] 77 EE BD 92 63 7A F7 86 w...cz.. >>> 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 >>> smb_signing_md5: sequence number 6 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] F2 49 18 60 8B 96 22 FB .I.`..". >>> smb_signing_md5: sequence number 7 >>> smb_signing_check_pdu: seq 7: got good SMB signature of >>> [0000] 74 CA 84 E8 F0 2B 5F 93 t....+_. >>> 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 ........ >>> 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 >>> smb_signing_md5: sequence number 8 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] AC 94 11 10 43 F9 1B A8 ....C... >>> smb_signing_md5: sequence number 9 >>> smb_signing_check_pdu: seq 9: got good SMB signature of >>> [0000] CD B6 5D F7 6A 95 70 B9 ..].j.p. >>> rpc reply data: >>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>> &..M..f. >>> [0010] B3 FE D1 C1 00 00 00 00 ........ >>> rpc request data: >>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>> &..M..f. >>> [0010] B3 FE D1 C1 0C 00 ...... >>> 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 >>> smb_signing_md5: sequence number 10 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] 32 2D 66 66 C2 FD C7 AF 2-ff.... >>> smb_signing_md5: sequence number 11 >>> smb_signing_check_pdu: seq 11: got good SMB signature of >>> [0000] DD 3C 1D 35 CD 94 09 88 .<.5.... >>> rpc reply data: >>> [0000] 00 00 02 00 0C 00 00 00 0A 00 0C 00 04 00 02 00 ........ >>> ........ >>> [0010] 12 00 14 00 08 00 02 00 12 00 14 00 0C 00 02 00 ........ >>> ........ >>> [0020] 2E BA 3F 2B 35 36 27 4E 90 D3 BE 55 5B 96 AE A1 ..?+56'N >>> ...U[... >>> [0030] 10 00 02 00 06 00 00 00 00 00 00 00 05 00 00 00 ........ >>> ........ >>> [0040] 49 00 4E 00 46 00 52 00 41 00 00 00 0A 00 00 00 I.N.F.R. >>> A....... >>> [0050] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ >>> i.n.f.r. >>> [0060] 61 00 2E 00 63 00 6F 00 6D 00 00 00 0A 00 00 00 a...c.o. >>> m....... >>> [0070] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ >>> i.n.f.r. >>> [0080] 61 00 2E 00 63 00 6F 00 6D 00 00 00 04 00 00 00 a...c.o. >>> m....... >>> [0090] 01 04 00 00 00 00 00 05 15 00 00 00 05 CF 66 0B ........ >>> ......f. >>> [00A0] 52 91 25 EF 02 4B 1B D6 00 00 00 00 R.%..K.. .... >>> rpc request data: >>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>> &..M..f. >>> [0010] B3 FE D1 C1 06 00 ...... >>> 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 >>> smb_signing_md5: sequence number 12 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] 62 FA 51 B6 49 8C 2D 73 b.Q.I.-s >>> smb_signing_md5: sequence number 13 >>> smb_signing_check_pdu: seq 13: got good SMB signature of >>> [0000] 4A E8 4A EB 69 A4 EC 5D J.J.i..] >>> rpc reply data: >>> [0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ >>> ........ >>> rpc request data: >>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>> &..M..f. >>> [0010] B3 FE D1 C1 16 00 16 00 00 00 02 00 0B 00 00 00 ........ >>> ........ >>> [0020] 00 00 00 00 0B 00 00 00 73 00 6F 00 6C 00 61 00 ........ >>> s.o.l.a. >>> [0030] 72 00 69 00 73 00 2E 00 63 00 6F 00 6D 00 08 00 r.i.s... >>> c.o.m... >>> 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 >>> smb_signing_md5: sequence number 14 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] 85 6D ED 23 EB 6A 9B 42 .m.#.j.B >>> smb_signing_md5: sequence number 15 >>> smb_signing_check_pdu: seq 15: got good SMB signature of >>> [0000] E3 52 D1 8E FB BD DE 9C .R...... >>> rpc reply data: >>> [0000] 00 00 00 00 34 00 00 C0 ....4... >>> rpc request data: >>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>> &..M..f. >>> [0010] B3 FE D1 C1 16 00 18 00 00 00 02 00 0E 00 10 00 ........ >>> ........ >>> [0020] 04 00 02 00 08 00 02 00 03 00 00 00 02 00 00 00 ........ >>> ........ >>> [0030] 00 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 ........ >>> ........ >>> [0040] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. >>> r.i.s... >>> [0050] 63 00 6F 00 6D 00 00 00 08 00 00 00 00 00 00 00 c.o.m... >>> ........ >>> [0060] 07 00 00 00 53 00 4F 00 4C 00 41 00 52 00 49 00 ....S.O. >>> L.A.R.I. >>> [0070] 53 00 00 00 04 00 00 00 01 04 00 00 00 00 00 05 S....... >>> ........ >>> [0080] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... >>> .0l..... >>> [0090] 40 04 00 00 0C 00 02 00 40 04 00 00 F3 EB B4 CA @....... >>> @....... >>> [00A0] 99 BB 60 76 9A 51 FD BE 16 00 59 56 14 B8 A4 AF ..`v.Q.. >>> ..YV.... >>> [00B0] 00 4F 6E C5 95 EE 75 2E BA EF 21 CF 26 B1 9E C5 .On...u. >>> ..!.&... >>> [00C0] 29 54 05 06 1F EB BF 90 4A F1 88 37 D3 AE B9 FB )T...... >>> J..7.... >>> [00D0] A0 A4 B7 C5 2A B2 38 60 3D 59 B1 14 19 5D 30 64 ....*.8` >>> =Y...]0d >>> [00E0] F2 82 6D DC 03 CC 19 CC D5 D1 ED A7 63 40 F0 72 ..m..... >>> ....c at .r >>> [00F0] E5 80 B2 FB 3E 06 95 45 76 19 0A C8 5A 83 5B 00 ....>..E >>> v...Z.[. >>> [0100] C7 39 27 83 43 88 98 0F 2B C5 75 D8 4C 3B 61 18 .9'.C... >>> +.u.L;a. >>> [0110] CF F6 1F BB 31 A9 CD FF 57 F5 EF 0B 81 B9 5F 7E ....1... >>> W....._~ >>> [0120] 1B 3E 00 11 92 CB 92 8C 29 D5 90 31 B7 39 B1 31 .>...... >>> )..1.9.1 >>> [0130] 7C C3 0C C8 E5 D0 51 AA 20 D2 A2 39 C1 52 ED 91 |.....Q. >>> ..9.R.. >>> [0140] 70 27 2F 7C EB 05 8F 91 AA EB 26 13 07 2C FA 62 p'/|.... >>> ..&..,.b >>> [0150] C3 CB 79 DD B5 DA EC 3E 78 9A D8 A1 AE 64 3C 7F ..y....> >>> x....d<. >>> [0160] BB CE 06 48 9A 56 6E 22 FC 6D 78 59 63 2F B8 51 ...H.Vn" >>> .mxYc/.Q >>> [0170] D6 81 91 1D 54 94 2D C7 69 75 B3 E4 F1 77 93 EF ....T.-. >>> iu...w.. >>> [0180] BB 3E 0E 80 D7 D4 DD A0 DA 3C 10 51 64 5A AA A7 .>...... >>> .<.QdZ.. >>> [0190] CB AE CE DA BF F8 03 10 5C DB 64 9F 32 94 D4 F2 ........ >>> \.d.2... >>> [01A0] 67 1F D4 E7 4E 4F A3 DA A3 1A 24 FC 47 C9 73 FD g...NO.. >>> ..$.G.s. >>> [01B0] AB 70 CB 34 BE 3B FF 12 A9 A3 DA 31 72 41 07 C0 .p.4.;.. >>> ...1rA.. >>> [01C0] 27 4A FF ED F8 C7 39 FD B6 87 2E 01 F9 0E 27 9F 'J....9. >>> ......'. >>> [01D0] 22 12 6B B3 A8 27 CB 86 A1 9D 8F D0 7A 70 97 66 ".k..'.. >>> ....zp.f >>> [01E0] D4 AD 10 FF BF 88 3A 14 A4 D6 74 E4 17 79 E2 79 ......:. >>> ..t..y.y >>> [01F0] A7 41 0D 2D A6 09 C5 DF 9F 85 C4 C8 E8 28 10 23 .A.-.... >>> .....(.# >>> [0200] B2 87 1C 8F 82 3E EC F6 BB 51 49 CD EF CF D3 95 .....>.. >>> .QI..... >>> [0210] 76 E5 A1 7B 6D 42 81 04 81 8D C0 9C 82 13 14 A1 v..{mB.. >>> ........ >>> [0220] 1C 8B B1 ED 94 D7 41 EF 43 04 49 A5 35 17 17 51 ......A. >>> C.I.5..Q >>> [0230] C1 D0 27 13 93 6F CF 15 15 E6 C3 32 4D 85 9D E7 ..'..o.. >>> ...2M... >>> [0240] FF E7 36 D9 3F CE 35 A2 DC 2D AB 06 1E 84 2B 6E ..6.?.5. >>> .-....+n >>> [0250] 3C D9 BF 3E 01 9E 6B 8B 5D 8D F3 98 F0 AA 1B 62 <..>..k. >>> ]......b >>> [0260] C4 BD D9 CB F6 F8 77 60 09 3C F1 C7 9B FA BB 6C ......w` >>> .<.....l >>> [0270] CF A8 6E 7C 6B 4B 20 D3 FB 1A 83 16 CC E1 2C 8D ..n|kK . >>> ......,. >>> [0280] 1F C0 6C 8F 93 69 7F 24 2C B4 76 9E D4 5E 2D 60 ..l..i.$ >>> ,.v..^-` >>> [0290] 38 3D 72 D6 07 E0 38 81 52 F1 71 06 23 07 68 18 8=r...8. >>> R.q.#.h. >>> [02A0] 67 7B D5 56 6B 19 E8 EF 7C 45 BB B3 7C A1 45 71 g{.Vk... >>> |E..|.Eq >>> [02B0] 1C 2B 27 8D 2D B0 7D 6C 0B 1E 4A 0F EC 39 C0 80 .+'.-.}l >>> ..J..9.. >>> [02C0] D5 3F A6 A9 01 96 BE 95 D9 8F 79 3C 9B E2 B5 77 .?...... >>> ..y<...w >>> [02D0] 68 BA 2B B3 F4 53 70 71 3C 78 FC 12 D5 09 3B 4F h.+..Spq >>> >> [02E0] 54 56 A3 73 63 E7 3A AE 29 F4 64 59 2E 74 BE B9 TV.sc.:. >>> ).dY.t.. >>> [02F0] 36 57 80 7B C8 5D 7A F1 92 B9 B9 98 33 62 2C 02 6W.{.]z. >>> ....3b,. >>> [0300] 2E 57 41 01 19 67 51 5D 57 FF FF 78 43 B2 27 00 .WA..gQ] >>> W..xC.'. >>> [0310] 49 E7 94 17 BC 69 AD 56 7D 51 65 F0 59 DB 41 15 I....i.V >>> }Qe.Y.A. >>> [0320] 94 8C 69 BE 1E 1D 35 1E 2F 60 EF B4 5C 43 A0 F5 ..i...5. >>> /`..\C.. >>> [0330] D3 6F 7E A1 42 2D 75 56 37 78 54 F4 9D AA A1 BB .o~.B-uV >>> 7xT..... >>> [0340] 31 7F DB AF 4A 7D EA 03 B2 64 06 84 F1 69 93 6F 1...J}.. >>> .d...i.o >>> [0350] D1 26 D6 3C CB E0 6F 8C 72 38 00 65 12 5D 3F 5E .&.<..o. >>> r8.e.]?^ >>> [0360] 8A 9B 36 AB FB 53 85 19 59 2B D7 9E 4B 9C DE 4E ..6..S.. >>> Y+..K..N >>> [0370] 6E 9B CA F1 8E CC 25 B5 7D 79 86 F3 0F 2B 9A D3 n.....%. >>> }y...+.. >>> [0380] 5F 47 6C DC AD 2F 6A 87 04 D1 C3 90 96 13 A0 4D _Gl../j. >>> .......M >>> [0390] 6A CC 05 74 0C E1 57 26 96 EC 72 53 93 BC 99 FA j..t..W& >>> ..rS.... >>> [03A0] 4C E9 17 2F 40 A8 B8 0A 77 D1 A5 D6 08 0B A1 69 L../@... >>> w......i >>> [03B0] 1D D9 3A EE BA A3 20 56 3F B0 48 9A AF EC CE 22 ..:... V >>> ?.H...." >>> [03C0] 03 B4 CC CF BC A7 38 CB CC 99 A8 CB C7 BE 54 6F ......8. >>> ......To >>> [03D0] 7B C8 DB 38 52 D5 F4 DB F1 E2 45 7B D1 56 C7 73 {..8R... >>> ..E{.V.s >>> [03E0] 91 08 64 7A 79 A9 49 3F 7F F4 41 1B 72 CB F0 E0 ..dzy.I? >>> ..A.r... >>> [03F0] B7 C1 69 50 4C 85 94 6B 75 AA CB BA A5 58 CA 9A ..iPL..k >>> u....X.. >>> [0400] 84 96 52 AA E2 F0 94 95 65 0A 03 06 C9 A5 A4 3F ..R..... >>> e......? >>> [0410] 78 46 4D 39 4B 64 88 4B A9 CA BB 2F 7C 65 B4 6E xFM9Kd.K >>> .../|e.n >>> [0420] D0 3D C7 19 29 50 A6 3D D3 A7 19 7C 9C 7C 82 06 .=..)P.= >>> ...|.|.. >>> [0430] 2B 3B E3 50 B9 CF 5F 31 03 31 AC 3D CF 57 45 32 +;.P.._1 >>> .1.=.WE2 >>> [0440] 32 F4 9C 9C 88 EE 93 63 F0 21 41 3A CA BA 22 95 2......c >>> .!A:..". >>> [0450] 38 DB 0F 10 3A AF C5 74 C7 07 85 B2 07 22 53 8F 8...:..t >>> ....."S. >>> [0460] 31 74 71 5A E5 92 5B 4E DE F0 DB 38 D9 A0 20 E2 1tqZ..[N >>> ...8.. . >>> [0470] 39 F7 79 BB B6 92 D0 D5 19 DB 14 EF F6 DD 6A 2C 9.y..... >>> ......j, >>> [0480] 4A 11 1E F2 DD 89 13 98 7E 19 FC CD 75 BF E8 57 J....... >>> ~...u..W >>> [0490] A9 EF B3 34 60 01 EF 7B 2C BC E4 8D A7 DD 06 05 ...4`..{ >>> ,....... >>> [04A0] A8 4B A6 B8 F4 C6 5B B2 AF 4D 3A BB 35 74 18 91 .K....[. >>> .M:.5t.. >>> [04B0] 54 A2 38 95 F1 8F CD 13 A1 F6 7B 4C 4D A5 04 73 T.8..... >>> ..{LM..s >>> [04C0] 12 DE DC A5 C9 9E B2 73 53 F2 A9 94 A7 4B 65 52 .......s >>> S....KeR >>> [04D0] 15 C6 84 70 4A 5B 3E 17 3A 96 AF D1 00 00 01 00 ...pJ[>. >>> :....... >>> 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 >>> smb_signing_md5: sequence number 16 >>> smb_signing_sign_pdu: sent SMB signature of >>> [0000] 22 D2 88 02 E7 0E C2 30 "......0 >>> smb_signing_md5: sequence number 17 >>> smb_signing_check_pdu: seq 17: got good SMB signature of >>> [0000] C7 4B 3C 94 92 8D 79 5F .K<...y_ >>> rpc reply data: >>> [0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ >>> ........ >>> [0010] 00 00 00 00 35 00 00 C0 ....5... >>> [Wed Mar 18 11:18:04.781985 2015] [:error] [pid 3831] ipa: INFO: >>> [jsonserver_session] admin at SOLARIS.COM: trust_add(u'infra.com', >>> trust_type=u'ad', realm_admin=u'Administrator', realm_passwd=u'********', >>> all=False, raw=False, version=u'2.113'): RemoteRetrieveError >>> >> >> -- >>> 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 >>> >> >> >> -- >> / Alexander Bokovoy >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Wed Mar 18 09:35:35 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 12:35:35 +0300 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: References: <20150318091500.GZ3878@redhat.com> Message-ID: HI i saw this ticket and' 13 months old https://fedorahosted.org/freeipa/ticket/4202 is this fixed? i think the mentioned patch is for 3.3 Regards, Ben On Wed, Mar 18, 2015 at 12:24 PM, Ben .T.George wrote: > this is the result from AD > > C:\Users\Administrator>nslookup > Default Server: localhost > Address: 127.0.0.1 > > > set type=srv > > _ldap._tcp.infra.com > Server: localhost > Address: 127.0.0.1 > > _ldap._tcp.infra.com SRV service location: > priority = 0 > weight = 100 > port = 389 > svr hostname = kwtipaad001.infra.com > kwtipaad001.infra.com internet address = 172.16.107.250 > > _ldap._tcp.solaris.com > Server: localhost > Address: 127.0.0.1 > > Non-authoritative answer: > _ldap._tcp.solaris.com SRV service location: > priority = 0 > weight = 100 > port = 389 > svr hostname = kwtpocpbis02.solaris.com > > kwtpocpbis02.solaris.com internet address = 172.16.107.135 > > On Wed, Mar 18, 2015 at 12:21 PM, Ben .T.George > wrote: > >> HI >> >> thanks for the reply >> >> i have created PTR record for IPA server under reverse lookup zone >> manually and ipa server resolving from AD >> >> how can i solve trhis issue.? >> >> >> >> On Wed, Mar 18, 2015 at 12:15 PM, Alexander Bokovoy >> wrote: >> >>> On Wed, 18 Mar 2015, Ben .T.George wrote: >>> >>>> Hi >>>> >>>> i am getting "ipa: ERROR: CIFS server communication error: code >>>> "-1073741771"," >>>> >>>> while doing >>>> >>>> [root at kwtpocpbis02 ~]# ipa trust-add --type=ad infra.com --admin >>>> Administrator --password >>>> Active Directory domain administrator's password: >>>> ipa: ERROR: CIFS server communication error: code "-1073741771", >>>> message "NT_STATUS_OBJECT_NAME_COLLISION" (both may be >>>> "None") >>>> >>>> i am using centos 7 and IPA 4.1.2 >>>> >>> NT_STATUS_OBJECT_NAME_COLLISION means AD thinks you have hosts in AD >>> that belong to the solaris.com domain which 'trust-ad' operation claims >>> to belong to IPA realm. AD denies operating the trust in this case. >>> >>> >>> >>>> IPA Server >>>> >>>> [root at kwtpocpbis02 ~]# host kwtpocpbis02.solaris.com >>>> kwtpocpbis02.solaris.com has address 172.16.107.135 >>>> [root at kwtpocpbis02 ~]# host 172.16.107.135 >>>> 135.107.16.172.in-addr.arpa domain name pointer >>>> kwtpocpbis02.solaris.com. >>>> >>>> >>>> AD >>>> >>>> [root at kwtpocpbis02 ~]# host 172.16.107.250 >>>> 250.107.16.172.in-addr.arpa domain name pointer kwtipaad001.infra.com. >>>> [root at kwtpocpbis02 ~]# host kwtipaad001.infra.com >>>> kwtipaad001.infra.com has address 172.16.107.250 >>>> >>>> debugging is enabled and this is i am getting on error_log >>>> >>>> INFO: Current debug levels: >>>> all: 11 >>>> tdb: 11 >>>> printdrivers: 11 >>>> lanman: 11 >>>> smb: 11 >>>> rpc_parse: 11 >>>> rpc_srv: 11 >>>> rpc_cli: 11 >>>> passdb: 11 >>>> sam: 11 >>>> auth: 11 >>>> winbind: 11 >>>> vfs: 11 >>>> idmap: 11 >>>> quota: 11 >>>> acls: 11 >>>> locking: 11 >>>> msdfs: 11 >>>> dmapi: 11 >>>> registry: 11 >>>> scavenger: 11 >>>> dns: 11 >>>> ldb: 11 >>>> pm_process() returned Yes >>>> GENSEC backend 'gssapi_spnego' registered >>>> GENSEC backend 'gssapi_krb5' registered >>>> GENSEC backend 'gssapi_krb5_sasl' registered >>>> GENSEC backend 'sasl-DIGEST-MD5' registered >>>> GENSEC backend 'schannel' registered >>>> GENSEC backend 'spnego' registered >>>> GENSEC backend 'ntlmssp' registered >>>> Using binding ncacn_np:kwtpocpbis02.solaris.com[,] >>>> Mapped to DCERPC endpoint \pipe\lsarpc >>>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>>> netmask=255.255.255.0 >>>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>>> netmask=255.255.255.0 >>>> Socket options: >>>> SO_KEEPALIVE = 0 >>>> SO_REUSEADDR = 0 >>>> SO_BROADCAST = 0 >>>> TCP_NODELAY = 1 >>>> TCP_KEEPCNT = 9 >>>> TCP_KEEPIDLE = 7200 >>>> TCP_KEEPINTVL = 75 >>>> IPTOS_LOWDELAY = 0 >>>> IPTOS_THROUGHPUT = 0 >>>> SO_REUSEPORT = 0 >>>> SO_SNDBUF = 663430 >>>> SO_RCVBUF = 261942 >>>> SO_SNDLOWAT = 1 >>>> SO_RCVLOWAT = 1 >>>> SO_SNDTIMEO = 0 >>>> SO_RCVTIMEO = 0 >>>> TCP_QUICKACK = 1 >>>> TCP_DEFER_ACCEPT = 0 >>>> Starting GENSEC mechanism spnego >>>> Starting GENSEC submechanism gssapi_krb5 >>>> Ticket in credentials cache for admin at SOLARIS.COM will expire in 81540 >>>> secs >>>> gensec_gssapi: NO credentials were delegated >>>> GSSAPI Connection will be cryptographically sealed >>>> 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 >>>> 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 ........ >>>> 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 >>>> rpc reply data: >>>> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >>>> .....U.4 >>>> [0010] 2E 0F 00 00 00 00 00 00 ........ >>>> rpc request data: >>>> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >>>> .....U.4 >>>> [0010] 2E 0F 00 00 0C 00 ...... >>>> 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 >>>> rpc reply data: >>>> [0000] 00 00 02 00 0C 00 00 00 0E 00 10 00 04 00 02 00 ........ >>>> ........ >>>> [0010] 16 00 18 00 08 00 02 00 16 00 18 00 0C 00 02 00 ........ >>>> ........ >>>> [0020] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... >>>> .0l..... >>>> [0030] 10 00 02 00 08 00 00 00 00 00 00 00 07 00 00 00 ........ >>>> ........ >>>> [0040] 53 00 4F 00 4C 00 41 00 52 00 49 00 53 00 00 00 S.O.L.A. >>>> R.I.S... >>>> [0050] 0C 00 00 00 00 00 00 00 0B 00 00 00 73 00 6F 00 ........ >>>> ....s.o. >>>> [0060] 6C 00 61 00 72 00 69 00 73 00 2E 00 63 00 6F 00 l.a.r.i. >>>> s...c.o. >>>> [0070] 6D 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 m....... >>>> ........ >>>> [0080] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. >>>> r.i.s... >>>> [0090] 63 00 6F 00 6D 00 00 00 04 00 00 00 01 04 00 00 c.o.m... >>>> ........ >>>> [00A0] 00 00 00 05 15 00 00 00 5F 89 A9 B4 86 30 6C 9D ........ >>>> _....0l. >>>> [00B0] B4 09 10 02 00 00 00 00 ........ >>>> rpc request data: >>>> [0000] 00 00 00 00 0D 00 00 00 00 00 00 00 09 55 BC 34 ........ >>>> .....U.4 >>>> [0010] 2E 0F 00 00 06 00 ...... >>>> 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 >>>> 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: 11 >>>> tdb: 11 >>>> printdrivers: 11 >>>> lanman: 11 >>>> smb: 11 >>>> rpc_parse: 11 >>>> rpc_srv: 11 >>>> rpc_cli: 11 >>>> passdb: 11 >>>> sam: 11 >>>> auth: 11 >>>> winbind: 11 >>>> vfs: 11 >>>> idmap: 11 >>>> quota: 11 >>>> acls: 11 >>>> locking: 11 >>>> msdfs: 11 >>>> dmapi: 11 >>>> registry: 11 >>>> scavenger: 11 >>>> dns: 11 >>>> ldb: 11 >>>> pm_process() returned Yes >>>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>>> netmask=255.255.255.0 >>>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>>> netmask=255.255.255.0 >>>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>>> netmask=255.255.255.0 >>>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>>> netmask=255.255.255.0 >>>> finddcs: searching for a DC by DNS domain infra.com >>>> finddcs: looking for SRV records for _ldap._tcp.infra.com >>>> ads_dns_lookup_srv: 1 records returned in the answer section. >>>> ads_dns_parse_rr_srv: Parsed kwtipaad001.infra.com [0, 100, 389] >>>> Addrs = 172.16.107.250 at 389/kwtipaad001 >>>> finddcs: DNS SRV response 0 at '172.16.107.250' >>>> finddcs: performing CLDAP query on 172.16.107.250 >>>> &response->data.nt5_ex: struct NETLOGON_SAM_LOGON_RESPONSE_EX >>>> command : LOGON_SAM_LOGON_RESPONSE_EX (23) >>>> sbz : 0x0000 (0) >>>> server_type : 0x000033fd (13309) >>>> 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 >>>> 1: 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 : 2b3fba2e-3635-4e27-90d3-be555b96aea1 >>>> forest : 'infra.com' >>>> dns_domain : 'infra.com' >>>> pdc_dns_name : 'kwtipaad001.infra.com' >>>> domain_name : 'INFRA' >>>> pdc_name : 'KWTIPAAD001' >>>> 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 172.16.107.250 with server_type=0x000033fd >>>> 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: 11 >>>> tdb: 11 >>>> printdrivers: 11 >>>> lanman: 11 >>>> smb: 11 >>>> rpc_parse: 11 >>>> rpc_srv: 11 >>>> rpc_cli: 11 >>>> passdb: 11 >>>> sam: 11 >>>> auth: 11 >>>> winbind: 11 >>>> vfs: 11 >>>> idmap: 11 >>>> quota: 11 >>>> acls: 11 >>>> locking: 11 >>>> msdfs: 11 >>>> dmapi: 11 >>>> registry: 11 >>>> scavenger: 11 >>>> dns: 11 >>>> ldb: 11 >>>> pm_process() returned Yes >>>> Using binding ncacn_np:kwtipaad001.infra.com[,] >>>> Mapped to DCERPC endpoint \pipe\lsarpc >>>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>>> netmask=255.255.255.0 >>>> added interface eno16777728 ip=172.16.107.135 bcast=172.16.107.255 >>>> netmask=255.255.255.0 >>>> Socket options: >>>> SO_KEEPALIVE = 0 >>>> SO_REUSEADDR = 0 >>>> SO_BROADCAST = 0 >>>> TCP_NODELAY = 1 >>>> TCP_KEEPCNT = 9 >>>> TCP_KEEPIDLE = 7200 >>>> TCP_KEEPINTVL = 75 >>>> IPTOS_LOWDELAY = 0 >>>> IPTOS_THROUGHPUT = 0 >>>> SO_REUSEPORT = 0 >>>> SO_SNDBUF = 23080 >>>> SO_RCVBUF = 87380 >>>> SO_SNDLOWAT = 1 >>>> SO_RCVLOWAT = 1 >>>> SO_SNDTIMEO = 0 >>>> SO_RCVTIMEO = 0 >>>> TCP_QUICKACK = 1 >>>> TCP_DEFER_ACCEPT = 0 >>>> Starting GENSEC mechanism spnego >>>> Starting GENSEC submechanism 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 : 0x0007 (7) >>>> DomainNameMaxLen : 0x0007 (7) >>>> DomainName : * >>>> DomainName : 'SOLARIS' >>>> WorkstationLen : 0x0007 (7) >>>> WorkstationMaxLen : 0x0007 (7) >>>> Workstation : * >>>> Workstation : 'SOLARIS' >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] 42 53 52 53 50 59 4C 20 BSRSPYL >>>> 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 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] 42 53 52 53 50 59 4C 20 BSRSPYL >>>> smb_signing_activate: user_session_key >>>> [0000] 23 27 C0 93 E7 C8 7F B9 47 A9 FD 91 F7 73 10 6E #'...... >>>> G....s.n >>>> smb_signing_activate: NULL response_data >>>> smb_signing_md5: sequence number 1 >>>> smb_signing_check_pdu: seq 1: got good SMB signature of >>>> [0000] 71 D6 FE AD D8 76 9E B9 q....v.. >>>> smb_signing_md5: sequence number 2 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] 07 24 9E 31 C2 C8 37 9D .$.1..7. >>>> smb_signing_md5: sequence number 3 >>>> smb_signing_check_pdu: seq 3: got good SMB signature of >>>> [0000] 7E F4 97 77 31 32 74 F7 ~..w12t. >>>> smb_signing_md5: sequence number 4 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] 26 96 4E B8 AF B2 5C EB &.N...\. >>>> smb_signing_md5: sequence number 5 >>>> smb_signing_check_pdu: seq 5: got good SMB signature of >>>> [0000] 77 EE BD 92 63 7A F7 86 w...cz.. >>>> 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 >>>> smb_signing_md5: sequence number 6 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] F2 49 18 60 8B 96 22 FB .I.`..". >>>> smb_signing_md5: sequence number 7 >>>> smb_signing_check_pdu: seq 7: got good SMB signature of >>>> [0000] 74 CA 84 E8 F0 2B 5F 93 t....+_. >>>> 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 ........ >>>> 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 >>>> smb_signing_md5: sequence number 8 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] AC 94 11 10 43 F9 1B A8 ....C... >>>> smb_signing_md5: sequence number 9 >>>> smb_signing_check_pdu: seq 9: got good SMB signature of >>>> [0000] CD B6 5D F7 6A 95 70 B9 ..].j.p. >>>> rpc reply data: >>>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>>> &..M..f. >>>> [0010] B3 FE D1 C1 00 00 00 00 ........ >>>> rpc request data: >>>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>>> &..M..f. >>>> [0010] B3 FE D1 C1 0C 00 ...... >>>> 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 >>>> smb_signing_md5: sequence number 10 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] 32 2D 66 66 C2 FD C7 AF 2-ff.... >>>> smb_signing_md5: sequence number 11 >>>> smb_signing_check_pdu: seq 11: got good SMB signature of >>>> [0000] DD 3C 1D 35 CD 94 09 88 .<.5.... >>>> rpc reply data: >>>> [0000] 00 00 02 00 0C 00 00 00 0A 00 0C 00 04 00 02 00 ........ >>>> ........ >>>> [0010] 12 00 14 00 08 00 02 00 12 00 14 00 0C 00 02 00 ........ >>>> ........ >>>> [0020] 2E BA 3F 2B 35 36 27 4E 90 D3 BE 55 5B 96 AE A1 ..?+56'N >>>> ...U[... >>>> [0030] 10 00 02 00 06 00 00 00 00 00 00 00 05 00 00 00 ........ >>>> ........ >>>> [0040] 49 00 4E 00 46 00 52 00 41 00 00 00 0A 00 00 00 I.N.F.R. >>>> A....... >>>> [0050] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ >>>> i.n.f.r. >>>> [0060] 61 00 2E 00 63 00 6F 00 6D 00 00 00 0A 00 00 00 a...c.o. >>>> m....... >>>> [0070] 00 00 00 00 09 00 00 00 69 00 6E 00 66 00 72 00 ........ >>>> i.n.f.r. >>>> [0080] 61 00 2E 00 63 00 6F 00 6D 00 00 00 04 00 00 00 a...c.o. >>>> m....... >>>> [0090] 01 04 00 00 00 00 00 05 15 00 00 00 05 CF 66 0B ........ >>>> ......f. >>>> [00A0] 52 91 25 EF 02 4B 1B D6 00 00 00 00 R.%..K.. .... >>>> rpc request data: >>>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>>> &..M..f. >>>> [0010] B3 FE D1 C1 06 00 ...... >>>> 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 >>>> smb_signing_md5: sequence number 12 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] 62 FA 51 B6 49 8C 2D 73 b.Q.I.-s >>>> smb_signing_md5: sequence number 13 >>>> smb_signing_check_pdu: seq 13: got good SMB signature of >>>> [0000] 4A E8 4A EB 69 A4 EC 5D J.J.i..] >>>> rpc reply data: >>>> [0000] 00 00 02 00 06 00 00 00 03 00 00 00 00 00 00 00 ........ >>>> ........ >>>> rpc request data: >>>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>>> &..M..f. >>>> [0010] B3 FE D1 C1 16 00 16 00 00 00 02 00 0B 00 00 00 ........ >>>> ........ >>>> [0020] 00 00 00 00 0B 00 00 00 73 00 6F 00 6C 00 61 00 ........ >>>> s.o.l.a. >>>> [0030] 72 00 69 00 73 00 2E 00 63 00 6F 00 6D 00 08 00 r.i.s... >>>> c.o.m... >>>> 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 >>>> smb_signing_md5: sequence number 14 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] 85 6D ED 23 EB 6A 9B 42 .m.#.j.B >>>> smb_signing_md5: sequence number 15 >>>> smb_signing_check_pdu: seq 15: got good SMB signature of >>>> [0000] E3 52 D1 8E FB BD DE 9C .R...... >>>> rpc reply data: >>>> [0000] 00 00 00 00 34 00 00 C0 ....4... >>>> rpc request data: >>>> [0000] 00 00 00 00 91 2A 29 B8 26 DE 0E 4D 87 08 66 C3 .....*). >>>> &..M..f. >>>> [0010] B3 FE D1 C1 16 00 18 00 00 00 02 00 0E 00 10 00 ........ >>>> ........ >>>> [0020] 04 00 02 00 08 00 02 00 03 00 00 00 02 00 00 00 ........ >>>> ........ >>>> [0030] 00 00 00 00 0C 00 00 00 00 00 00 00 0B 00 00 00 ........ >>>> ........ >>>> [0040] 73 00 6F 00 6C 00 61 00 72 00 69 00 73 00 2E 00 s.o.l.a. >>>> r.i.s... >>>> [0050] 63 00 6F 00 6D 00 00 00 08 00 00 00 00 00 00 00 c.o.m... >>>> ........ >>>> [0060] 07 00 00 00 53 00 4F 00 4C 00 41 00 52 00 49 00 ....S.O. >>>> L.A.R.I. >>>> [0070] 53 00 00 00 04 00 00 00 01 04 00 00 00 00 00 05 S....... >>>> ........ >>>> [0080] 15 00 00 00 5F 89 A9 B4 86 30 6C 9D B4 09 10 02 ...._... >>>> .0l..... >>>> [0090] 40 04 00 00 0C 00 02 00 40 04 00 00 F3 EB B4 CA @....... >>>> @....... >>>> [00A0] 99 BB 60 76 9A 51 FD BE 16 00 59 56 14 B8 A4 AF ..`v.Q.. >>>> ..YV.... >>>> [00B0] 00 4F 6E C5 95 EE 75 2E BA EF 21 CF 26 B1 9E C5 .On...u. >>>> ..!.&... >>>> [00C0] 29 54 05 06 1F EB BF 90 4A F1 88 37 D3 AE B9 FB )T...... >>>> J..7.... >>>> [00D0] A0 A4 B7 C5 2A B2 38 60 3D 59 B1 14 19 5D 30 64 ....*.8` >>>> =Y...]0d >>>> [00E0] F2 82 6D DC 03 CC 19 CC D5 D1 ED A7 63 40 F0 72 ..m..... >>>> ....c at .r >>>> [00F0] E5 80 B2 FB 3E 06 95 45 76 19 0A C8 5A 83 5B 00 ....>..E >>>> v...Z.[. >>>> [0100] C7 39 27 83 43 88 98 0F 2B C5 75 D8 4C 3B 61 18 .9'.C... >>>> +.u.L;a. >>>> [0110] CF F6 1F BB 31 A9 CD FF 57 F5 EF 0B 81 B9 5F 7E ....1... >>>> W....._~ >>>> [0120] 1B 3E 00 11 92 CB 92 8C 29 D5 90 31 B7 39 B1 31 .>...... >>>> )..1.9.1 >>>> [0130] 7C C3 0C C8 E5 D0 51 AA 20 D2 A2 39 C1 52 ED 91 |.....Q. >>>> ..9.R.. >>>> [0140] 70 27 2F 7C EB 05 8F 91 AA EB 26 13 07 2C FA 62 p'/|.... >>>> ..&..,.b >>>> [0150] C3 CB 79 DD B5 DA EC 3E 78 9A D8 A1 AE 64 3C 7F ..y....> >>>> x....d<. >>>> [0160] BB CE 06 48 9A 56 6E 22 FC 6D 78 59 63 2F B8 51 ...H.Vn" >>>> .mxYc/.Q >>>> [0170] D6 81 91 1D 54 94 2D C7 69 75 B3 E4 F1 77 93 EF ....T.-. >>>> iu...w.. >>>> [0180] BB 3E 0E 80 D7 D4 DD A0 DA 3C 10 51 64 5A AA A7 .>...... >>>> .<.QdZ.. >>>> [0190] CB AE CE DA BF F8 03 10 5C DB 64 9F 32 94 D4 F2 ........ >>>> \.d.2... >>>> [01A0] 67 1F D4 E7 4E 4F A3 DA A3 1A 24 FC 47 C9 73 FD g...NO.. >>>> ..$.G.s. >>>> [01B0] AB 70 CB 34 BE 3B FF 12 A9 A3 DA 31 72 41 07 C0 .p.4.;.. >>>> ...1rA.. >>>> [01C0] 27 4A FF ED F8 C7 39 FD B6 87 2E 01 F9 0E 27 9F 'J....9. >>>> ......'. >>>> [01D0] 22 12 6B B3 A8 27 CB 86 A1 9D 8F D0 7A 70 97 66 ".k..'.. >>>> ....zp.f >>>> [01E0] D4 AD 10 FF BF 88 3A 14 A4 D6 74 E4 17 79 E2 79 ......:. >>>> ..t..y.y >>>> [01F0] A7 41 0D 2D A6 09 C5 DF 9F 85 C4 C8 E8 28 10 23 .A.-.... >>>> .....(.# >>>> [0200] B2 87 1C 8F 82 3E EC F6 BB 51 49 CD EF CF D3 95 .....>.. >>>> .QI..... >>>> [0210] 76 E5 A1 7B 6D 42 81 04 81 8D C0 9C 82 13 14 A1 v..{mB.. >>>> ........ >>>> [0220] 1C 8B B1 ED 94 D7 41 EF 43 04 49 A5 35 17 17 51 ......A. >>>> C.I.5..Q >>>> [0230] C1 D0 27 13 93 6F CF 15 15 E6 C3 32 4D 85 9D E7 ..'..o.. >>>> ...2M... >>>> [0240] FF E7 36 D9 3F CE 35 A2 DC 2D AB 06 1E 84 2B 6E ..6.?.5. >>>> .-....+n >>>> [0250] 3C D9 BF 3E 01 9E 6B 8B 5D 8D F3 98 F0 AA 1B 62 <..>..k. >>>> ]......b >>>> [0260] C4 BD D9 CB F6 F8 77 60 09 3C F1 C7 9B FA BB 6C ......w` >>>> .<.....l >>>> [0270] CF A8 6E 7C 6B 4B 20 D3 FB 1A 83 16 CC E1 2C 8D ..n|kK . >>>> ......,. >>>> [0280] 1F C0 6C 8F 93 69 7F 24 2C B4 76 9E D4 5E 2D 60 ..l..i.$ >>>> ,.v..^-` >>>> [0290] 38 3D 72 D6 07 E0 38 81 52 F1 71 06 23 07 68 18 8=r...8. >>>> R.q.#.h. >>>> [02A0] 67 7B D5 56 6B 19 E8 EF 7C 45 BB B3 7C A1 45 71 g{.Vk... >>>> |E..|.Eq >>>> [02B0] 1C 2B 27 8D 2D B0 7D 6C 0B 1E 4A 0F EC 39 C0 80 .+'.-.}l >>>> ..J..9.. >>>> [02C0] D5 3F A6 A9 01 96 BE 95 D9 8F 79 3C 9B E2 B5 77 .?...... >>>> ..y<...w >>>> [02D0] 68 BA 2B B3 F4 53 70 71 3C 78 FC 12 D5 09 3B 4F h.+..Spq >>>> >>> [02E0] 54 56 A3 73 63 E7 3A AE 29 F4 64 59 2E 74 BE B9 TV.sc.:. >>>> ).dY.t.. >>>> [02F0] 36 57 80 7B C8 5D 7A F1 92 B9 B9 98 33 62 2C 02 6W.{.]z. >>>> ....3b,. >>>> [0300] 2E 57 41 01 19 67 51 5D 57 FF FF 78 43 B2 27 00 .WA..gQ] >>>> W..xC.'. >>>> [0310] 49 E7 94 17 BC 69 AD 56 7D 51 65 F0 59 DB 41 15 I....i.V >>>> }Qe.Y.A. >>>> [0320] 94 8C 69 BE 1E 1D 35 1E 2F 60 EF B4 5C 43 A0 F5 ..i...5. >>>> /`..\C.. >>>> [0330] D3 6F 7E A1 42 2D 75 56 37 78 54 F4 9D AA A1 BB .o~.B-uV >>>> 7xT..... >>>> [0340] 31 7F DB AF 4A 7D EA 03 B2 64 06 84 F1 69 93 6F 1...J}.. >>>> .d...i.o >>>> [0350] D1 26 D6 3C CB E0 6F 8C 72 38 00 65 12 5D 3F 5E .&.<..o. >>>> r8.e.]?^ >>>> [0360] 8A 9B 36 AB FB 53 85 19 59 2B D7 9E 4B 9C DE 4E ..6..S.. >>>> Y+..K..N >>>> [0370] 6E 9B CA F1 8E CC 25 B5 7D 79 86 F3 0F 2B 9A D3 n.....%. >>>> }y...+.. >>>> [0380] 5F 47 6C DC AD 2F 6A 87 04 D1 C3 90 96 13 A0 4D _Gl../j. >>>> .......M >>>> [0390] 6A CC 05 74 0C E1 57 26 96 EC 72 53 93 BC 99 FA j..t..W& >>>> ..rS.... >>>> [03A0] 4C E9 17 2F 40 A8 B8 0A 77 D1 A5 D6 08 0B A1 69 L../@... >>>> w......i >>>> [03B0] 1D D9 3A EE BA A3 20 56 3F B0 48 9A AF EC CE 22 ..:... V >>>> ?.H...." >>>> [03C0] 03 B4 CC CF BC A7 38 CB CC 99 A8 CB C7 BE 54 6F ......8. >>>> ......To >>>> [03D0] 7B C8 DB 38 52 D5 F4 DB F1 E2 45 7B D1 56 C7 73 {..8R... >>>> ..E{.V.s >>>> [03E0] 91 08 64 7A 79 A9 49 3F 7F F4 41 1B 72 CB F0 E0 ..dzy.I? >>>> ..A.r... >>>> [03F0] B7 C1 69 50 4C 85 94 6B 75 AA CB BA A5 58 CA 9A ..iPL..k >>>> u....X.. >>>> [0400] 84 96 52 AA E2 F0 94 95 65 0A 03 06 C9 A5 A4 3F ..R..... >>>> e......? >>>> [0410] 78 46 4D 39 4B 64 88 4B A9 CA BB 2F 7C 65 B4 6E xFM9Kd.K >>>> .../|e.n >>>> [0420] D0 3D C7 19 29 50 A6 3D D3 A7 19 7C 9C 7C 82 06 .=..)P.= >>>> ...|.|.. >>>> [0430] 2B 3B E3 50 B9 CF 5F 31 03 31 AC 3D CF 57 45 32 +;.P.._1 >>>> .1.=.WE2 >>>> [0440] 32 F4 9C 9C 88 EE 93 63 F0 21 41 3A CA BA 22 95 2......c >>>> .!A:..". >>>> [0450] 38 DB 0F 10 3A AF C5 74 C7 07 85 B2 07 22 53 8F 8...:..t >>>> ....."S. >>>> [0460] 31 74 71 5A E5 92 5B 4E DE F0 DB 38 D9 A0 20 E2 1tqZ..[N >>>> ...8.. . >>>> [0470] 39 F7 79 BB B6 92 D0 D5 19 DB 14 EF F6 DD 6A 2C 9.y..... >>>> ......j, >>>> [0480] 4A 11 1E F2 DD 89 13 98 7E 19 FC CD 75 BF E8 57 J....... >>>> ~...u..W >>>> [0490] A9 EF B3 34 60 01 EF 7B 2C BC E4 8D A7 DD 06 05 ...4`..{ >>>> ,....... >>>> [04A0] A8 4B A6 B8 F4 C6 5B B2 AF 4D 3A BB 35 74 18 91 .K....[. >>>> .M:.5t.. >>>> [04B0] 54 A2 38 95 F1 8F CD 13 A1 F6 7B 4C 4D A5 04 73 T.8..... >>>> ..{LM..s >>>> [04C0] 12 DE DC A5 C9 9E B2 73 53 F2 A9 94 A7 4B 65 52 .......s >>>> S....KeR >>>> [04D0] 15 C6 84 70 4A 5B 3E 17 3A 96 AF D1 00 00 01 00 ...pJ[>. >>>> :....... >>>> 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 >>>> smb_signing_md5: sequence number 16 >>>> smb_signing_sign_pdu: sent SMB signature of >>>> [0000] 22 D2 88 02 E7 0E C2 30 "......0 >>>> smb_signing_md5: sequence number 17 >>>> smb_signing_check_pdu: seq 17: got good SMB signature of >>>> [0000] C7 4B 3C 94 92 8D 79 5F .K<...y_ >>>> rpc reply data: >>>> [0000] 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ >>>> ........ >>>> [0010] 00 00 00 00 35 00 00 C0 ....5... >>>> [Wed Mar 18 11:18:04.781985 2015] [:error] [pid 3831] ipa: INFO: >>>> [jsonserver_session] admin at SOLARIS.COM: trust_add(u'infra.com', >>>> trust_type=u'ad', realm_admin=u'Administrator', >>>> realm_passwd=u'********', >>>> all=False, raw=False, version=u'2.113'): RemoteRetrieveError >>>> >>> >>> -- >>>> 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 >>>> >>> >>> >>> -- >>> / Alexander Bokovoy >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 18 09:45:28 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 11:45:28 +0200 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: References: <20150318091500.GZ3878@redhat.com> Message-ID: <20150318094528.GA3878@redhat.com> On Wed, 18 Mar 2015, Ben .T.George wrote: >HI > >i saw this ticket and' 13 months old > >https://fedorahosted.org/freeipa/ticket/4202 > >is this fixed? i think the mentioned patch is for 3.3 This is fixed. Do you have any host in .solaris.com that is joined your AD in infra.com? -- / Alexander Bokovoy From bentech4you at gmail.com Wed Mar 18 09:47:11 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 12:47:11 +0300 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: <20150318094528.GA3878@redhat.com> References: <20150318091500.GZ3878@redhat.com> <20150318094528.GA3878@redhat.com> Message-ID: no, this is new host-name i am choosed. anyway how to check is there any existing solaris.com in AD, under DNS management, i cannot see anything Regards, Ben On Wed, Mar 18, 2015 at 12:45 PM, Alexander Bokovoy wrote: > On Wed, 18 Mar 2015, Ben .T.George wrote: > >> HI >> >> i saw this ticket and' 13 months old >> >> https://fedorahosted.org/freeipa/ticket/4202 >> >> is this fixed? i think the mentioned patch is for 3.3 >> > This is fixed. > > Do you have any host in .solaris.com that is joined your AD in > infra.com? > > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 18 09:59:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 11:59:43 +0200 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: References: <20150318091500.GZ3878@redhat.com> <20150318094528.GA3878@redhat.com> Message-ID: <20150318095942.GB3878@redhat.com> On Wed, 18 Mar 2015, Ben .T.George wrote: >no, > >this is new host-name i am choosed. > >anyway how to check is there any existing solaris.com in AD, under DNS >management, i cannot see anything You can search with ldapsearch, something like this, from IPA master: ldapsearch -D administrator at infra.com -W -b dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn -- / Alexander Bokovoy From bentech4you at gmail.com Wed Mar 18 10:33:00 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 13:33:00 +0300 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: <20150318095942.GB3878@redhat.com> References: <20150318091500.GZ3878@redhat.com> <20150318094528.GA3878@redhat.com> <20150318095942.GB3878@redhat.com> Message-ID: did that and the result is [root at kwtpocpbis02 ~]# ldapsearch -D administrator at infra.com -W -b dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn Enter LDAP Password: ldap_bind: No such object (32) You have new mail in /var/spool/mail/root On Wed, Mar 18, 2015 at 12:59 PM, Alexander Bokovoy wrote: > On Wed, 18 Mar 2015, Ben .T.George wrote: > >> no, >> >> this is new host-name i am choosed. >> >> anyway how to check is there any existing solaris.com in AD, under DNS >> management, i cannot see anything >> > You can search with ldapsearch, something like this, from IPA master: > > ldapsearch -D administrator at infra.com -W -b dc=infra,dc=com > '(serviceprincipalname=*solaris.com)' dn > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 18 10:38:00 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 12:38:00 +0200 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: References: <20150318091500.GZ3878@redhat.com> <20150318094528.GA3878@redhat.com> <20150318095942.GB3878@redhat.com> Message-ID: <20150318103800.GD3878@redhat.com> On Wed, 18 Mar 2015, Ben .T.George wrote: >did that and the result is > >[root at kwtpocpbis02 ~]# ldapsearch -D administrator at infra.com -W -b >dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn >Enter LDAP Password: >ldap_bind: No such object (32) >You have new mail in /var/spool/mail/root Ah, sorry, you need to add -h option to specify LDAP server host (your AD DC). > > >On Wed, Mar 18, 2015 at 12:59 PM, Alexander Bokovoy >wrote: > >> On Wed, 18 Mar 2015, Ben .T.George wrote: >> >>> no, >>> >>> this is new host-name i am choosed. >>> >>> anyway how to check is there any existing solaris.com in AD, under DNS >>> management, i cannot see anything >>> >> You can search with ldapsearch, something like this, from IPA master: >> >> ldapsearch -D administrator at infra.com -W -b dc=infra,dc=com >> '(serviceprincipalname=*solaris.com)' dn >> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From bentech4you at gmail.com Wed Mar 18 10:41:25 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Wed, 18 Mar 2015 13:41:25 +0300 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: <20150318103800.GD3878@redhat.com> References: <20150318091500.GZ3878@redhat.com> <20150318094528.GA3878@redhat.com> <20150318095942.GB3878@redhat.com> <20150318103800.GD3878@redhat.com> Message-ID: ok thanks now the output is something different [root at kwtpocpbis02 ~]# ldapsearch -h 172.16.107.250 -D administrator at infra.com -W -b dc=infra,dc=com '(serviceprincipalname=* solaris.com)' dn Enter LDAP Password: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (serviceprincipalname=*solaris.com) # requesting: dn # # search reference ref: ldap://ForestDnsZones.infra.com/DC=ForestDnsZones,DC=infra,DC=com # search reference ref: ldap://DomainDnsZones.infra.com/DC=DomainDnsZones,DC=infra,DC=com # search reference ref: ldap://infra.com/CN=Configuration,DC=infra,DC=com # search result search: 2 result: 0 Success # numResponses: 4 # numReferences: 3 You have new mail in /var/spool/mail/root but there is no solaris.com in this output On Wed, Mar 18, 2015 at 1:38 PM, Alexander Bokovoy wrote: > On Wed, 18 Mar 2015, Ben .T.George wrote: > >> did that and the result is >> >> [root at kwtpocpbis02 ~]# ldapsearch -D administrator at infra.com -W -b >> dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn >> Enter LDAP Password: >> ldap_bind: No such object (32) >> You have new mail in /var/spool/mail/root >> > Ah, sorry, you need to add -h option to specify LDAP server host (your > AD DC). > > > >> >> On Wed, Mar 18, 2015 at 12:59 PM, Alexander Bokovoy >> wrote: >> >> On Wed, 18 Mar 2015, Ben .T.George wrote: >>> >>> no, >>>> >>>> this is new host-name i am choosed. >>>> >>>> anyway how to check is there any existing solaris.com in AD, under DNS >>>> management, i cannot see anything >>>> >>>> You can search with ldapsearch, something like this, from IPA master: >>> >>> ldapsearch -D administrator at infra.com -W -b dc=infra,dc=com >>> '(serviceprincipalname=*solaris.com)' dn >>> >>> -- >>> / Alexander Bokovoy >>> >>> > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanju.a at tcs.com Wed Mar 18 10:45:28 2015 From: sanju.a at tcs.com (Sanju A) Date: Wed, 18 Mar 2015 16:15:28 +0530 Subject: [Freeipa-users] Failed to fall over to replica with master down Message-ID: Hi All, I have configured IPA and later configured master-master replication. But it failed to fall over to the replica when master down. Please help Here are the details. ipa.example.com - 192.168.1.51 ipa2.example.com - 192.168.1.61 Command using for joining machines : ipa-client-install --mkhomedir --domain=example.com --server=ipa.example.com --realm=EXAMPLE.COM --enable-dns-updates Regards Sanju Abraham Linux Admin =====-----=====-----===== 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: From abokovoy at redhat.com Wed Mar 18 10:48:05 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 12:48:05 +0200 Subject: [Freeipa-users] ipa: ERROR: CIFS server communication error: code "-1073741771", In-Reply-To: References: <20150318091500.GZ3878@redhat.com> <20150318094528.GA3878@redhat.com> <20150318095942.GB3878@redhat.com> <20150318103800.GD3878@redhat.com> Message-ID: <20150318104805.GE3878@redhat.com> On Wed, 18 Mar 2015, Ben .T.George wrote: >ok thanks now the output is something different > >[root at kwtpocpbis02 ~]# ldapsearch -h 172.16.107.250 -D >administrator at infra.com -W -b dc=infra,dc=com '(serviceprincipalname=* >solaris.com)' dn >Enter LDAP Password: ># extended LDIF ># ># LDAPv3 ># base with scope subtree ># filter: (serviceprincipalname=*solaris.com) ># requesting: dn ># > ># search reference >ref: ldap://ForestDnsZones.infra.com/DC=ForestDnsZones,DC=infra,DC=com > ># search reference >ref: ldap://DomainDnsZones.infra.com/DC=DomainDnsZones,DC=infra,DC=com > ># search reference >ref: ldap://infra.com/CN=Configuration,DC=infra,DC=com > ># search result >search: 2 >result: 0 Success > ># numResponses: 4 ># numReferences: 3 >You have new mail in /var/spool/mail/root > > >but there is no solaris.com in this output Ok. Send me privately error_log after 'ipa trust-add'. Don't forget to set 'log level = 100' in /usr/share/ipa/smb.conf.empty before doing that. > > > >On Wed, Mar 18, 2015 at 1:38 PM, Alexander Bokovoy >wrote: > >> On Wed, 18 Mar 2015, Ben .T.George wrote: >> >>> did that and the result is >>> >>> [root at kwtpocpbis02 ~]# ldapsearch -D administrator at infra.com -W -b >>> dc=infra,dc=com '(serviceprincipalname=*solaris.com)' dn >>> Enter LDAP Password: >>> ldap_bind: No such object (32) >>> You have new mail in /var/spool/mail/root >>> >> Ah, sorry, you need to add -h option to specify LDAP server host (your >> AD DC). >> >> >> >>> >>> On Wed, Mar 18, 2015 at 12:59 PM, Alexander Bokovoy >>> wrote: >>> >>> On Wed, 18 Mar 2015, Ben .T.George wrote: >>>> >>>> no, >>>>> >>>>> this is new host-name i am choosed. >>>>> >>>>> anyway how to check is there any existing solaris.com in AD, under DNS >>>>> management, i cannot see anything >>>>> >>>>> You can search with ldapsearch, something like this, from IPA master: >>>> >>>> ldapsearch -D administrator at infra.com -W -b dc=infra,dc=com >>>> '(serviceprincipalname=*solaris.com)' dn >>>> >>>> -- >>>> / Alexander Bokovoy >>>> >>>> >> -- >> / Alexander Bokovoy >> -- / Alexander Bokovoy From jhrozek at redhat.com Wed Mar 18 11:36:59 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 18 Mar 2015 12:36:59 +0100 Subject: [Freeipa-users] Failed to fall over to replica with master down In-Reply-To: References: Message-ID: <20150318113659.GN4854@hendrix.redhat.com> On Wed, Mar 18, 2015 at 04:15:28PM +0530, Sanju A wrote: > Hi All, > > I have configured IPA and later configured master-master replication. But > it failed to fall over to the replica when master down. Please help > Here are the details. What it "it" ? A client machine running on a client different than any of these two servers? > > ipa.example.com - 192.168.1.51 > ipa2.example.com - 192.168.1.61 > > Command using for joining machines : ipa-client-install --mkhomedir > --domain=example.com --server=ipa.example.com --realm=EXAMPLE.COM ~~~~~~~~~~~~~~~~~~~~~~~~ I suspect this would be the culprit. Please check sssd.conf on the clients, especially the ipa_server directive. It should either be empty or the first record should be "_srv_". From jhrozek at redhat.com Wed Mar 18 13:23:37 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Wed, 18 Mar 2015 14:23:37 +0100 Subject: [Freeipa-users] Failed to fall over to replica with master down In-Reply-To: References: <20150318113659.GN4854@hendrix.redhat.com> Message-ID: <20150318132337.GO4854@hendrix.redhat.com> On Wed, Mar 18, 2015 at 06:44:04PM +0530, Sanju A wrote: > Dear Jakub, > > > I have joined the client machine using the following command (including > the replica server details) and it is working. > > ipa-client-install --mkhomedir --domain=example.com > --server=ipa.example.com --server=ipa2.example.com --realm=EXAMPLE.COM > --enable-dns-updates > > The problem is that we have around 225 client machines and it is not easy > to rejoin the machines with the replica server details. Is there any way I > can include the replica details in client machines ? Please keep the replies on the list, other users might hit the same problems as you do. Please also attach sssd.conf from one of your client machines, or at least paste the ipa_server option. Thanks! From Joshua.Gould at osumc.edu Wed Mar 18 13:24:18 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Wed, 18 Mar 2015 09:24:18 -0400 Subject: [Freeipa-users] sssd options ignored? In-Reply-To: <20150318082816.GY3878@redhat.com> References: <20150318062603.GW3878@redhat.com> <20150318074130.GD4854@hendrix.redhat.com> <20150318075500.GE9952@p.redhat.com> <20150318082816.GY3878@redhat.com> Message-ID: On 3/18/15, 4:28 AM, "Alexander Bokovoy" wrote: >On Wed, 18 Mar 2015, Gould, Joshua wrote: >> >> >>I?ll be happy to remove the AD section from the sssd.conf file and test >>but I think there?s more going on. The AD section was generated from the >>IPA client install. I never manually added anything other than ?pac? to >>the services line under the [sssd] section and the two ldap_idmap_range >>options. >Show your /var/log/ipaclient-install.log. ipa-client-install has no >support to generate sections for AD at all. I think then it would have to be the ?ipa trust-add? command which generates those sections then? The command that I used was: # ipa trust-add --type=ad TEST.OSUWMC ?-admin=farus ?password --range-type=ipa-ad-trust Active Directory domain administrator's password: ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue The trust was created even with that error message and seems to work. From abokovoy at redhat.com Wed Mar 18 13:48:47 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 15:48:47 +0200 Subject: [Freeipa-users] sssd options ignored? In-Reply-To: References: <20150318062603.GW3878@redhat.com> <20150318074130.GD4854@hendrix.redhat.com> <20150318075500.GE9952@p.redhat.com> <20150318082816.GY3878@redhat.com> Message-ID: <20150318134847.GH3878@redhat.com> On Wed, 18 Mar 2015, Gould, Joshua wrote: >On 3/18/15, 4:28 AM, "Alexander Bokovoy" wrote: > >>On Wed, 18 Mar 2015, Gould, Joshua wrote: >>> >>> >>>I?ll be happy to remove the AD section from the sssd.conf file and test >>>but I think there?s more going on. The AD section was generated from the >>>IPA client install. I never manually added anything other than ?pac? to >>>the services line under the [sssd] section and the two ldap_idmap_range >>>options. >>Show your /var/log/ipaclient-install.log. ipa-client-install has no >>support to generate sections for AD at all. > >I think then it would have to be the ?ipa trust-add? command which >generates those sections then? The command that I used was: No, it is not. We don't have *any* code that could have generated that section in FreeIPA. ># ipa trust-add --type=ad TEST.OSUWMC ?-admin=farus ?password >--range-type=ipa-ad-trust >Active Directory domain administrator's password: >ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most >likely it is a DNS or firewall issue > > >The trust was created even with that error message and seems to work. Do you get something like $ kdestroy -A $ kinit admin $ kvno -S cifs $ klist -ef working? -- / Alexander Bokovoy From Joshua.Gould at osumc.edu Wed Mar 18 14:21:02 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Wed, 18 Mar 2015 10:21:02 -0400 Subject: [Freeipa-users] sssd options ignored? In-Reply-To: <20150318134847.GH3878@redhat.com> References: <20150318062603.GW3878@redhat.com> <20150318074130.GD4854@hendrix.redhat.com> <20150318075500.GE9952@p.redhat.com> <20150318082816.GY3878@redhat.com> <20150318134847.GH3878@redhat.com> Message-ID: On 3/18/15, 9:48 AM, "Alexander Bokovoy" wrote: >On Wed, 18 Mar 2015, Gould, Joshua wrote: >>On 3/18/15, 4:28 AM, "Alexander Bokovoy" wrote: >> >>>On Wed, 18 Mar 2015, Gould, Joshua wrote: >>>> >>>> >>>>I?ll be happy to remove the AD section from the sssd.conf file and test >>>>but I think there?s more going on. The AD section was generated from >>>>the >>>>IPA client install. I never manually added anything other than ?pac? to >>>>the services line under the [sssd] section and the two ldap_idmap_range >>>>options. >>>Show your /var/log/ipaclient-install.log. ipa-client-install has no >>>support to generate sections for AD at all. >> >>I think then it would have to be the ?ipa trust-add? command which >>generates those sections then? The command that I used was: >No, it is not. We don't have *any* code that could have generated that >section in FreeIPA. Since we?re still in the test phase, I can fairly easily set things up again. It will help me to improve my own documentation for how things are setup in test and how I can set things up in production. When I do that, I can look at the sssd.conf after each step and see where it gets modified and let you know. Like I said, I never created the domain section, but I did add the debugging statement, the range options and the option for pac. > >># ipa trust-add --type=ad TEST.OSUWMC ?-admin=farus ?password >>--range-type=ipa-ad-trust >>Active Directory domain administrator's password: >>ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most >>likely it is a DNS or firewall issue >> >> >>The trust was created even with that error message and seems to work. >Do you get something like > >$ kdestroy -A >$ kinit admin >$ kvno -S cifs >$ klist -ef > >working? All of those work even with the error when initially creating the trust. We basically treated the error as cosmetic since everything else seems to work. [goul09 at mid-ipa-vp01 ~]$ kdestroy kdestroy: No credentials cache found while destroying cache [goul09 at mid-ipa-vp01 ~]$ kinit admin Password for admin at UNIX.TEST.OSUWMC: [goul09 at mid-ipa-vp01 ~]$ kvno -S cifs svr-addc-vt01.test.osuwmc cifs/svr-addc-vt01.test.osuwmc at TEST.OSUWMC: kvno = 16 [goul09 at mid-ipa-vp01 ~]$ klist -ef Ticket cache: FILE:/tmp/krb5cc_998 Default principal: admin at UNIX.TEST.OSUWMC Valid starting Expires Service principal 03/18/2015 10:15:28 03/19/2015 10:15:25 krbtgt/UNIX.TEST.OSUWMC at UNIX.TEST.OSUWMC Flags: FIA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 03/18/2015 10:16:08 03/19/2015 10:15:25 krbtgt/TEST.OSUWMC at UNIX.TEST.OSUWMC Flags: FAT, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 03/18/2015 10:15:46 03/18/2015 20:15:46 cifs/svr-addc-vt01.test.osuwmc at TEST.OSUWMC Flags: FA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 [goul09 at mid-ipa-vp01 ~]$ From guertin at middlebury.edu Wed Mar 18 15:31:26 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Wed, 18 Mar 2015 15:31:26 +0000 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: <20150318062309.GV3878@redhat.com> References: <1426605513212.47081@middlebury.edu> <20150317154300.GQ3878@redhat.com> <3746481a704f4e68b6aea41daf62597f@greyhound.middlebury.edu> <20150318062309.GV3878@redhat.com> Message-ID: > Wait, why do you have middlebury.edu section here at all? If middlebury is > trusted by csns.middlebury.edu, you should not have a separate > [domain/middlebury.edu] section at all! That was in there because in my increasingly desperate attempts to get this working, I actually read the documentation, and Section 2.4 of the RHEL 7 Windows Integration Guide says to create a new domain section for the Active Directory domain. Not knowing any better, I played along. I have removed that section, and now things are broken again. However, the "Could not convert objectSID to a UNIX ID" problem is solved -- it's now breaking elsewhere, but I don't know where yet. I've set debug_level = 10 everywhere, and don't see anything but success messages in the logs, until the user is disconnected. I should probably start another thread for that. David Guertin From abokovoy at redhat.com Wed Mar 18 16:25:40 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 18:25:40 +0200 Subject: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX ID In-Reply-To: References: <1426605513212.47081@middlebury.edu> <20150317154300.GQ3878@redhat.com> <3746481a704f4e68b6aea41daf62597f@greyhound.middlebury.edu> <20150318062309.GV3878@redhat.com> Message-ID: <20150318162540.GJ3878@redhat.com> On Wed, 18 Mar 2015, Guertin, David S. wrote: >> Wait, why do you have middlebury.edu section here at all? If middlebury is >> trusted by csns.middlebury.edu, you should not have a separate >> [domain/middlebury.edu] section at all! > >That was in there because in my increasingly desperate attempts to get >this working, I actually read the documentation, and Section 2.4 of the >RHEL 7 Windows Integration Guide says to create a new domain section >for the Active Directory domain. Not knowing any better, I played >along. > >I have removed that section, and now things are broken again. However, >the "Could not convert objectSID to a UNIX ID" problem is solved -- >it's now breaking elsewhere, but I don't know where yet. I've set >debug_level = 10 everywhere, and don't see anything but success >messages in the logs, until the user is disconnected. I should probably >start another thread for that. Yes, separating the issues would be better because we have more and more people trying to follow threads in email archive in search of solutions to their problems. -- / Alexander Bokovoy From andrew.holway at gmail.com Wed Mar 18 16:40:19 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Wed, 18 Mar 2015 17:40:19 +0100 Subject: [Freeipa-users] SSSD in redundant configuration Message-ID: Hello, Im wondering how we should be handing SSSD for redundant configurations on our freeipa clients. We have three freeipa servers; how can we make SSSD check another freeipa in the event that one goes down? It appears we can do something like the following: ipa_hostname = test-freeipa-client-1.cloud.domain.de, test-freeipa-client-2.cloud.domain.de, test-freeipa-client-3.cloud.domain.de However I thought SRV records were meant to supply the magic here? Thanks, Andrew /etc/sssd/sssd.conf [domain/cloud.domain.de] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = cloud.domain.de id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = test-freeipa-client-2.cloud.domain.de chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, test-freeipa-2.cloud.domain.de ldap_tls_cacert = /etc/ipa/ca.crt # For the SUDO integration sudo_provider = ldap ldap_uri = ldap://test-freeipa-1.cloud.domain.de ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/test-freeipa-client-2.cloud.domain.de ldap_sasl_realm = CLOUD.DOMAIN.DE krb5_server = test-freeipa-2.cloud.domain.de [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = cloud.domain.de [nss] [pam] [sudo] [autofs] [ssh] [pac] -------------- next part -------------- An HTML attachment was scrubbed... URL: From kperrin at doctorondemand.com Wed Mar 18 16:50:51 2015 From: kperrin at doctorondemand.com (Kim Perrin) Date: Wed, 18 Mar 2015 09:50:51 -0700 Subject: [Freeipa-users] Unable to remove nsTombstone objects Message-ID: Hi all, yesterday I cleared up replication problems on my last standing IPA server. So I somewhat feel like I'm coming out of the tunnel. Today I want to turn up a replica again. However before doing so I'd like to clean out the last remnants of data about all previous replicas. I can't figure out the properly formatted ldif to use to remove the nsds50ruv and the nsruvReplicaLastModified records in these entries. Any guidance on the proper ldif to use would be much appreciated -- Here is are the tombstone entries - dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca objectClass: top objectClass: nsTombstone objectClass: extensibleobject nsds50ruv: {replicageneration} 5317a449000000600000 nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 600000 550878b9000000600000 nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 470000 531ce069000300470000 nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 4c0000 53f659500004004c0000 nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 510000 531bf265000100510000 nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 560000 531a3256000400560000 nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 5b0000 531949920000005b0000 nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 0610000 5317a48a000100610000 o: ipaca nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} 550878ab nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} 00000000 nsruvReplicaLastModified: {replica 97 ldap://util1prd.companyz.com:7389} 00000000 Using the following to clean these did NOT work - dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config changetype: add objectclass: top objectclass: extensibleObject replica-base-dn: dc=companyz,dc=com replica-id: 97 cn: clean 97 From rmeggins at redhat.com Wed Mar 18 16:52:29 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Mar 2015 10:52:29 -0600 Subject: [Freeipa-users] Unable to remove nsTombstone objects In-Reply-To: References: Message-ID: <5509AD4D.6040403@redhat.com> On 03/18/2015 10:50 AM, Kim Perrin wrote: > Hi all, > yesterday I cleared up replication problems on my last standing IPA > server. So I somewhat feel like I'm coming out of the tunnel. Today I > want to turn up a replica again. However before doing so I'd like to > clean out the last remnants of data about all previous replicas. > I can't figure out the properly formatted ldif to use to remove the > nsds50ruv and the nsruvReplicaLastModified records in these entries. > Any guidance on the proper ldif to use would be much appreciated -- > Here is are the tombstone entries - > > dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca > objectClass: top > objectClass: nsTombstone > objectClass: extensibleobject > nsds50ruv: {replicageneration} 5317a449000000600000 > nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 > 600000 550878b9000000600000 > nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 > 470000 531ce069000300470000 > nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 > 4c0000 53f659500004004c0000 > nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 > 510000 531bf265000100510000 > nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 > 560000 531a3256000400560000 > nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 > 5b0000 531949920000005b0000 > nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 > 0610000 5317a48a000100610000 > o: ipaca > nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} > 550878ab > nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} > 00000000 > nsruvReplicaLastModified: {replica 97 ldap://util1prd.companyz.com:7389} > 00000000 > > > > Using the following to clean these did NOT work - > > dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config > changetype: add > objectclass: top > objectclass: extensibleObject > replica-base-dn: dc=companyz,dc=com > replica-id: 97 > cn: clean 97 > Any errors in /var/log/dirsrv/slapd-DOMAIN/errors? From CWhite at skytouchtechnology.com Wed Mar 18 17:04:18 2015 From: CWhite at skytouchtechnology.com (Craig White) Date: Wed, 18 Mar 2015 17:04:18 +0000 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: References: Message-ID: From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Andrew Holway Sent: Wednesday, March 18, 2015 9:40 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] SSSD in redundant configuration Hello, Im wondering how we should be handing SSSD for redundant configurations on our freeipa clients. We have three freeipa servers; how can we make SSSD check another freeipa in the event that one goes down? It appears we can do something like the following: ipa_hostname = test-freeipa-client-1.cloud.domain.de, test-freeipa-client-2.cloud.domain.de, test-freeipa-client-3.cloud.domain.de However I thought SRV records were meant to supply the magic here? Thanks, Andrew /etc/sssd/sssd.conf [domain/cloud.domain.de] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = cloud.domain.de id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = test-freeipa-client-2.cloud.domain.de chpass_provider = ipa ipa_dyndns_update = True ipa_server = _srv_, test-freeipa-2.cloud.domain.de ldap_tls_cacert = /etc/ipa/ca.crt # For the SUDO integration sudo_provider = ldap ldap_uri = ldap://test-freeipa-1.cloud.domain.de ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/test-freeipa-client-2.cloud.domain.de ldap_sasl_realm = CLOUD.DOMAIN.DE krb5_server = test-freeipa-2.cloud.domain.de [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = cloud.domain.de [nss] [pam] [sudo] [autofs] [ssh] [pac] I think the magic you are looking for is in /etc/sssd/sssd.conf where you have? ipa_server = _srv_, test-freeipa-2.cloud.domain.de and all you need is? ipa_server = _srv_ for magic Craig -------------- next part -------------- An HTML attachment was scrubbed... URL: From kperrin at doctorondemand.com Wed Mar 18 17:07:19 2015 From: kperrin at doctorondemand.com (Kim Perrin) Date: Wed, 18 Mar 2015 10:07:19 -0700 Subject: [Freeipa-users] Unable to remove nsTombstone objects In-Reply-To: <5509AD4D.6040403@redhat.com> References: <5509AD4D.6040403@redhat.com> Message-ID: ah, good question. Relevant errors around trying to use the ldif I included to remove replica ID 97 -- [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to receive all the deleted replica updates... [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: Sending cleanAllRUV task to all the replicas... [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: Cleaning local ruv's... [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to be cleaned... [18/Mar/2015:04:01:52 +0000] NSMMReplicationPlugin - CleanAllRUV Task: Waiting for all the replicas to finish cleaning... [18/Mar/2015:04:01:52 +0000] NSMMReplicationPlugin - CleanAllRUV Task: Successfully cleaned rid(14). [18/Mar/2015:04:20:18 +0000] - WARNING: can't modify task entry 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) [18/Mar/2015:04:20:21 +0000] - WARNING: can't modify task entry 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) [18/Mar/2015:04:20:23 +0000] - WARNING: can't modify task entry 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) [18/Mar/2015:04:20:23 +0000] NSMMReplicationPlugin - CleanAllRUV Task: Replica id (97) is already being cleaned [18/Mar/2015:04:20:25 +0000] - WARNING: can't modify task entry 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) [18/Mar/2015:04:20:27 +0000] - WARNING: can't modify task entry 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) [18/Mar/2015:04:20:29 +0000] - WARNING: can't modify task entry 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) [18/Mar/2015:04:20:29 +0000] NSMMReplicationPlugin - CleanAllRUV Task: Task failed...(-1) [18/Mar/2015:04:20:31 +0000] - WARNING: can't modify task entry 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) [18/Mar/2015:04:20:31 +0000] - WARNING: can't find task entry 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config' [18/Mar/2015:04:24:46 +0000] ipa_range_check_pre_op - [file ipa_range_check.c, line 235]: Missing entry to modify. On Wed, Mar 18, 2015 at 9:52 AM, Rich Megginson wrote: > On 03/18/2015 10:50 AM, Kim Perrin wrote: >> >> Hi all, >> yesterday I cleared up replication problems on my last standing IPA >> server. So I somewhat feel like I'm coming out of the tunnel. Today I >> want to turn up a replica again. However before doing so I'd like to >> clean out the last remnants of data about all previous replicas. >> I can't figure out the properly formatted ldif to use to remove the >> nsds50ruv and the nsruvReplicaLastModified records in these entries. >> Any guidance on the proper ldif to use would be much appreciated -- >> Here is are the tombstone entries - >> >> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca >> objectClass: top >> objectClass: nsTombstone >> objectClass: extensibleobject >> nsds50ruv: {replicageneration} 5317a449000000600000 >> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 >> 600000 550878b9000000600000 >> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 >> 470000 531ce069000300470000 >> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 >> 4c0000 53f659500004004c0000 >> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 >> 510000 531bf265000100510000 >> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 >> 560000 531a3256000400560000 >> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 >> 5b0000 531949920000005b0000 >> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 >> 0610000 5317a48a000100610000 >> o: ipaca >> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} >> 550878ab >> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} >> 00000000 >> nsruvReplicaLastModified: {replica 97 ldap://util1prd.companyz.com:7389} >> 00000000 >> >> >> >> Using the following to clean these did NOT work - >> >> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config >> changetype: add >> objectclass: top >> objectclass: extensibleObject >> replica-base-dn: dc=companyz,dc=com >> replica-id: 97 >> cn: clean 97 >> > Any errors in /var/log/dirsrv/slapd-DOMAIN/errors? > > -- > 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 Wed Mar 18 17:11:44 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Mar 2015 13:11:44 -0400 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: References: Message-ID: <5509B1D0.1050602@redhat.com> Craig White wrote: > *From:*freeipa-users-bounces at redhat.com > [mailto:freeipa-users-bounces at redhat.com] *On Behalf Of *Andrew Holway > *Sent:* Wednesday, March 18, 2015 9:40 AM > *To:* freeipa-users at redhat.com > *Subject:* [Freeipa-users] SSSD in redundant configuration > > > > Hello, > > > > Im wondering how we should be handing SSSD for redundant configurations > on our freeipa clients. We have three freeipa servers; how can we make > SSSD check another freeipa in the event that one goes down? > > > > It appears we can do something like the following: > > > > ipa_hostname = test-freeipa-client-1.cloud.domain.de > , > test-freeipa-client-2.cloud.domain.de > , > test-freeipa-client-3.cloud.domain.de > > > > > However I thought SRV records were meant to supply the magic here? > > > > Thanks, > > > > Andrew > > > > > > /etc/sssd/sssd.conf > > [domain/cloud.domain.de ] > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = cloud.domain.de > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = test-freeipa-client-2.cloud.domain.de > > > chpass_provider = ipa > > ipa_dyndns_update = True > > ipa_server = _srv_, test-freeipa-2.cloud.domain.de > > > ldap_tls_cacert = /etc/ipa/ca.crt > > # For the SUDO integration > > sudo_provider = ldap > > ldap_uri = ldap://test-freeipa-1.cloud.domain.de > > > ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de > > ldap_sasl_mech = GSSAPI > > ldap_sasl_authid = host/test-freeipa-client-2.cloud.domain.de > > > ldap_sasl_realm = CLOUD.DOMAIN.DE > > krb5_server = test-freeipa-2.cloud.domain.de > > > [sssd] > > services = nss, pam, ssh, sudo > > config_file_version = 2 > > domains = cloud.domain.de > > [nss] > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > I think the magic you are looking for is in /etc/sssd/sssd.conf where > you have > > ipa_server = _srv_, test-freeipa-2.cloud.domain.de > > > and all you need is > > ipa_server = _srv_ _srv_ tells SSSD to check DNS for SRV records. The trailing server gives it a hardcoded fallback in case DNS fails for some reason. Their current configuration is correct. rob From rmeggins at redhat.com Wed Mar 18 18:21:46 2015 From: rmeggins at redhat.com (Rich Megginson) Date: Wed, 18 Mar 2015 12:21:46 -0600 Subject: [Freeipa-users] Unable to remove nsTombstone objects In-Reply-To: References: <5509AD4D.6040403@redhat.com> Message-ID: <5509C23A.70003@redhat.com> On 03/18/2015 11:07 AM, Kim Perrin wrote: > ah, good question. Relevant errors around trying to use the ldif I > included to remove replica ID 97 -- > > [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: > Waiting for all the replicas to receive all the deleted replica > updates... > [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: > Sending cleanAllRUV task to all the replicas... > [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: > Cleaning local ruv's... > [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: > Waiting for all the replicas to be cleaned... > [18/Mar/2015:04:01:52 +0000] NSMMReplicationPlugin - CleanAllRUV Task: > Waiting for all the replicas to finish cleaning... > [18/Mar/2015:04:01:52 +0000] NSMMReplicationPlugin - CleanAllRUV Task: > Successfully cleaned rid(14). > [18/Mar/2015:04:20:18 +0000] - WARNING: can't modify task entry > 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) > [18/Mar/2015:04:20:21 +0000] - WARNING: can't modify task entry > 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) > [18/Mar/2015:04:20:23 +0000] - WARNING: can't modify task entry > 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) > [18/Mar/2015:04:20:23 +0000] NSMMReplicationPlugin - CleanAllRUV Task: > Replica id (97) is already being cleaned > [18/Mar/2015:04:20:25 +0000] - WARNING: can't modify task entry > 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) > [18/Mar/2015:04:20:27 +0000] - WARNING: can't modify task entry > 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) > [18/Mar/2015:04:20:29 +0000] - WARNING: can't modify task entry > 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) > [18/Mar/2015:04:20:29 +0000] NSMMReplicationPlugin - CleanAllRUV Task: > Task failed...(-1) > [18/Mar/2015:04:20:31 +0000] - WARNING: can't modify task entry > 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) > [18/Mar/2015:04:20:31 +0000] - WARNING: can't find task entry > 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config' > [18/Mar/2015:04:24:46 +0000] ipa_range_check_pre_op - [file > ipa_range_check.c, line 235]: Missing entry to modify. Not sure what this means. Anyone? > > > > On Wed, Mar 18, 2015 at 9:52 AM, Rich Megginson wrote: >> On 03/18/2015 10:50 AM, Kim Perrin wrote: >>> Hi all, >>> yesterday I cleared up replication problems on my last standing IPA >>> server. So I somewhat feel like I'm coming out of the tunnel. Today I >>> want to turn up a replica again. However before doing so I'd like to >>> clean out the last remnants of data about all previous replicas. >>> I can't figure out the properly formatted ldif to use to remove the >>> nsds50ruv and the nsruvReplicaLastModified records in these entries. >>> Any guidance on the proper ldif to use would be much appreciated -- >>> Here is are the tombstone entries - >>> >>> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca >>> objectClass: top >>> objectClass: nsTombstone >>> objectClass: extensibleobject >>> nsds50ruv: {replicageneration} 5317a449000000600000 >>> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} 5317a455000000 >>> 600000 550878b9000000600000 >>> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} 531ce018000000 >>> 470000 531ce069000300470000 >>> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} 531cdde8000000 >>> 4c0000 53f659500004004c0000 >>> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} 531bf216000000 >>> 510000 531bf265000100510000 >>> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} 531a3222000000 >>> 560000 531a3256000400560000 >>> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} 5317f7cf000000 >>> 5b0000 531949920000005b0000 >>> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} 5317a45000000 >>> 0610000 5317a48a000100610000 >>> o: ipaca >>> nsruvReplicaLastModified: {replica 96 ldap://noc1-prd.companyz.com:7389} >>> 550878ab >>> nsruvReplicaLastModified: {replica 71 ldap://noc2-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 76 ldap://noc4-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 81 ldap://noc2-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 86 ldap://noc3-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 91 ldap://noc2-prd.companyz.com:7389} >>> 00000000 >>> nsruvReplicaLastModified: {replica 97 ldap://util1prd.companyz.com:7389} >>> 00000000 >>> >>> >>> >>> Using the following to clean these did NOT work - >>> >>> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config >>> changetype: add >>> objectclass: top >>> objectclass: extensibleObject >>> replica-base-dn: dc=companyz,dc=com >>> replica-id: 97 >>> cn: clean 97 >>> >> Any errors in /var/log/dirsrv/slapd-DOMAIN/errors? >> >> -- >> 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 guertin at middlebury.edu Wed Mar 18 18:28:28 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Wed, 18 Mar 2015 18:28:28 +0000 Subject: [Freeipa-users] AD users cannot log in: PAM permission denied Message-ID: <1426703309057.17846@middlebury.edu> I've almost got AD integration going, except for the minor detail that no one can log in. When an AD user tries to SSH in to the IPA server, /var/log/secure shows: ------------------------------------------ Mar 18 13:59:08 genet sshd[21335]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=tundra.middlebury.edu user=MIDD\guertin-s Mar 18 13:59:09 genet sshd[21335]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=tundra.middlebury.edu user=MIDD\guertin-s Mar 18 13:59:10 genet sshd[21335]: pam_sss(sshd:account): Access denied for user MIDD\guertin-s: 6 (Permission denied) Mar 18 13:59:10 genet sshd[21335]: Failed password for MIDD\\guertin-s from 140.233.6.66 port 59707 ssh2 Mar 18 13:59:10 genet sshd[21335]: fatal: Access denied for user MIDD\\\\guertin-s by PAM account configuration [preauth] ------------------------------------------ So pam_sss is responding with "permission denied". /etc/pam.d/password-auth contains: ------------------------------------------ #%PAM-1.0 # This file is auto-generated. # User changes will be destroyed the next time authconfig is run. auth required pam_env.so auth sufficient pam_unix.so nullok try_first_pass auth requisite pam_succeed_if.so uid >= 1000 quiet_success auth sufficient pam_sss.so use_first_pass auth required pam_deny.so account required pam_unix.so account sufficient pam_localuser.so account sufficient pam_succeed_if.so uid < 1000 quiet account [default=bad success=ok user_unknown=ignore] pam_sss.so account required pam_permit.so password requisite pam_pwquality.so try_first_pass local_users_only retry=3 authtok_type= password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok password sufficient pam_sss.so use_authtok password required pam_deny.so session optional pam_keyinit.so revoke session required pam_limits.so -session optional pam_systemd.so session optional pam_oddjob_mkhomedir.so umask=0077 session [success=1 default=ignore] pam_succeed_if.so service in crond quiet use_uid session required pam_unix.so session optional pam_sss.so ------------------------------------------ And with debug_level = 10, /var/log/sssd/sssd_pam.log shows: ------------------------------------------ (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'MIDD\guertin-s' matched expression for domain 'middlebury.edu', user is guertin-s (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: middlebury.edu (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): user: guertin-s (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: tundra.middlebury.edu (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 21335 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: MIDD\guertin-s (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/middlebury.edu/guertin-s] (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7fc92c76bed0:3:guertin-s at middlebury.edu] (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [middlebury.edu][3][1][name=guertin-s] (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7fc92e921240 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7fc92c76bed0:3:guertin-s at middlebury.edu] (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7fc92e921240 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7fc92e920450 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [guertin-s at middlebury.edu] (Wed Mar 18 13:59:08 2015) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7fc92e924ac0 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7fc92e924bf0 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7fc92e924ac0 "ltdb_callback" (Wed Mar 18 13:59:08 2015) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7fc92e924bf0 "ltdb_timeout" (Wed Mar 18 13:59:08 2015) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7fc92e924ac0 "ltdb_callback" (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [guertin-s at middlebury.edu] (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is guertin-s at middlebury.edu (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_initgr_cache_set] (0x2000): [guertin-s at middlebury.edu] added to PAM initgroup cache (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: middlebury.edu (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): user: guertin-s at middlebury.edu (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: tundra.middlebury.edu (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 21335 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: MIDD\guertin-s (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7fc92e928530 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Wed Mar 18 13:59:08 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7fc92c76bed0:3:guertin-s at middlebury.edu] (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7fc92e928530 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7fc92e920450 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][middlebury.edu] (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]. (Wed Mar 18 13:59:09 2015) [sssd[pam]] [ldb] (0x4000): start ldb transaction (nesting: 0) (Wed Mar 18 13:59:09 2015) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7fc92e9281b0 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7fc92e928270 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7fc92e9281b0 "ltdb_callback" (Wed Mar 18 13:59:09 2015) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7fc92e928270 "ltdb_timeout" (Wed Mar 18 13:59:09 2015) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7fc92e9281b0 "ltdb_callback" (Wed Mar 18 13:59:09 2015) [sssd[pam]] [ldb] (0x4000): commit ldb transaction (nesting: 0) (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [0]. (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 79 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fc92e931f40][19] (Wed Mar 18 13:59:09 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fc92e931f40][19] (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_cmd_acct_mgmt] (0x0100): entering pam_cmd_acct_mgmt (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sss_parse_name_for_domains] (0x0200): name 'MIDD\guertin-s' matched expression for domain 'middlebury.edu', user is guertin-s (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: middlebury.edu (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): user: guertin-s (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: tundra.middlebury.edu (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 21335 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: MIDD\guertin-s (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sss_ncache_check_str] (0x2000): Checking negative cache for [NCE/USER/middlebury.edu/guertin-s] (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7fc92c76bed0:3:guertin-s at middlebury.edu] (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sss_dp_get_account_msg] (0x0400): Creating request for [middlebury.edu][3][1][name=guertin-s] (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7fc92e929bc0 (Wed Mar 18 13:59:09 2015) [sssd[pam]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7fc92c76bed0:3:guertin-s at middlebury.edu] (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7fc92e929bc0 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7fc92e920450 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 0 errno: 0 error message: Success (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [guertin-s at middlebury.edu] (Wed Mar 18 13:59:10 2015) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x7fc92e9249e0 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x7fc92e924b10 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [ldb] (0x4000): Running timer event 0x7fc92e9249e0 "ltdb_callback" (Wed Mar 18 13:59:10 2015) [sssd[pam]] [ldb] (0x4000): Destroying timer event 0x7fc92e924b10 "ltdb_timeout" (Wed Mar 18 13:59:10 2015) [sssd[pam]] [ldb] (0x4000): Ending timer event 0x7fc92e9249e0 "ltdb_callback" (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_check_user_search] (0x0400): Returning info for user [guertin-s at middlebury.edu] (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pd_set_primary_name] (0x0400): User's primary name is guertin-s at middlebury.edu (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_initgr_cache_set] (0x2000): [guertin-s at middlebury.edu] added to PAM initgroup cache (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: middlebury.edu (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): user: guertin-s at middlebury.edu (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: tundra.middlebury.edu (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 21335 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_print_data] (0x0100): logon name: MIDD\guertin-s (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sbus_add_timeout] (0x2000): 0x7fc92e936050 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7fc92c76bed0:3:guertin-s at middlebury.edu] (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sbus_remove_timeout] (0x2000): 0x7fc92e936050 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sbus_dispatch] (0x4000): dbus conn: 0x7fc92e920450 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [sbus_dispatch] (0x4000): Dispatching. (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [6][middlebury.edu] (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply called with result [6]. (Wed Mar 18 13:59:10 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 31 (Wed Mar 18 13:59:10 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fc92e931f40][19] (Wed Mar 18 13:59:10 2015) [sssd[pam]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x7fc92e931f40][19] (Wed Mar 18 13:59:10 2015) [sssd[pam]] [client_recv] (0x0200): Client disconnected! (Wed Mar 18 13:59:10 2015) [sssd[pam]] [client_destructor] (0x2000): Terminated client [0x7fc92e931f40][19] ------------------------------------------ Everything looks normal here to me, until "[pam_dp_process_reply] (0x0100): received: [6]", after which the client disconnects. Can someone help with PAM configuration to get this to work? As described in the documentation, my ad_users group contains the group ad_users_external, which contains the AD group rhidm_users: # ipa group-show ad_users Group name: ad_users Description: AD users GID: 1447200005 Member groups: ad_users_external # ipa group-show ad_users_external Group name: ad_users_external Description: AD users external map Member of groups: ad_users External member: rhidm_users at middlebury.edu? David Guertin -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 18 18:56:43 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 18 Mar 2015 20:56:43 +0200 Subject: [Freeipa-users] AD users cannot log in: PAM permission denied In-Reply-To: <1426703309057.17846@middlebury.edu> References: <1426703309057.17846@middlebury.edu> Message-ID: <20150318185643.GL3878@redhat.com> On Wed, 18 Mar 2015, Guertin, David S. wrote: >I've almost got AD integration going, except for the minor detail that no one can log in. When an AD user tries to SSH in to the IPA server, /var/log/secure shows: > > >------------------------------------------ > >Mar 18 13:59:08 genet sshd[21335]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=tundra.middlebury.edu user=MIDD\guertin-s >Mar 18 13:59:09 genet sshd[21335]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=tundra.middlebury.edu user=MIDD\guertin-s >Mar 18 13:59:10 genet sshd[21335]: pam_sss(sshd:account): Access denied for user MIDD\guertin-s: 6 (Permission denied) >Mar 18 13:59:10 genet sshd[21335]: Failed password for MIDD\\guertin-s from 140.233.6.66 port 59707 ssh2 >Mar 18 13:59:10 genet sshd[21335]: fatal: Access denied for user MIDD\\\\guertin-s by PAM account configuration [preauth] > >------------------------------------------ > > >So pam_sss is responding with "permission denied". pam_sss verifies your right to access a service by seeing if there is an HBAC rule that allows it. HBAC rules are to allow what is denied by default. In standard FreeIPA setup we have 'allow_all' HBAC rule which roughly states "anyone can access any service on any host". Did you disable this rule? If yes, then you have to have an explicit rules allowing access to specific services. See examples in 'ipa trust' and 'ipa hbacrule'. Without arguments any topic level command in IPA CLI prints a help, there are examples of use of commands from those topics. To create HBAC rules for AD users you first need to create a grouping for them in IPA ('ipa trust' has explicit example how to do that) and then define an HBAC rule to allow that POSIX group to access sshd service. HBAC services are PAM service names (i.e. /etc/pam.d/). >Everything looks normal here to me, until "[pam_dp_process_reply] >(0x0100): received: [6]", after which the client disconnects. Can >someone help with PAM configuration to get this to work? > >As described in the documentation, my ad_users group contains the group >ad_users_external, which contains the AD group rhidm_users: > ># ipa group-show ad_users > Group name: ad_users > Description: AD users > GID: 1447200005 > Member groups: ad_users_external > ># ipa group-show ad_users_external > Group name: ad_users_external > Description: AD users external map > Member of groups: ad_users > External member: rhidm_users at middlebury.edu? Right, so you have ad_users group now and need to define an HBAC rule allowing it an access to sshd service. -- / Alexander Bokovoy From dpal at redhat.com Wed Mar 18 19:12:45 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 18 Mar 2015 15:12:45 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: References: Message-ID: <5509CE2D.8080108@redhat.com> On 03/17/2015 02:54 PM, Prasun Gera wrote: > Sorry, the message got sent accidentally earlier before I could > provide all the details. > > Version: 4.1.0 on RHEL 7.1 x86_64 > > Steps: > 1. ipa-server-install > 2. service sshd restart > 3. kinit admin <- This always works > 4. ssh admin at localhost <- This works for the first time, > fails second time onwards > ssh admin at host_addr from external system <- This also works > the first time, fails second time onwards > > 5. ipa-server-install --uninstall > 6. go to 1 > > The log messages in /var/log/messages point to > [sssd[krb5_child[21029]]]: Decrypt integrity check failed at the point > of the authentication failure > sssd's log's have a lot of "No matching domain found for user" messages. > /var/log/krb5kdc.log has a lot of error decoding FAST: client> for , Decrypt integrity check failed while > handling ap-request armor > > The only ERROR I can see in /var/log/ipaserver-uninstall.log is > pkidestroy : ERROR ....... subprocess.CalledProcessError: Command > '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', ......returned > non-zero exit status 6! > > > It appears that the uninstall process is leaving some residual > configuration behind which is conflicting with the subsequent > installation with the same domain name SSSD and certificate issues with re-install would be unrelated. Let us start over. Remove IPA, try it several times, it helps sometimes as it moves forward and cleans more on each attempt. Make sure there are no certs left and certmonger is not tracking anything. If you still experience issues with SSSD, add debug_level=10 to sssd configuration in the domain section, restart sssd and send the sanitized logs for the failed attempts. > > > Regards, > Prasun > > > > > > > > On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera > wrote: > > Hello, > I installed the ipa-server on an RHEL 7.1 system, uninstalled it > and reinstalled it with the same domain name as the first time. > This somehow creates problems with ssh authentication on the > server from external systems as well as from the server itself. > > Steps: > 1. ipa-server-install > 2. service sshd restart > 3. kinit admin > 4. ssh admin at localhost > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From guertin at middlebury.edu Wed Mar 18 19:13:38 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Wed, 18 Mar 2015 19:13:38 +0000 Subject: [Freeipa-users] AD users cannot log in: PAM permission denied In-Reply-To: <20150318185643.GL3878@redhat.com> References: <1426703309057.17846@middlebury.edu> <20150318185643.GL3878@redhat.com> Message-ID: <68270c66033f4047aa28e426c62f9a4c@greyhound.middlebury.edu> > In standard FreeIPA setup we have 'allow_all' HBAC rule which roughly > states "anyone can access any service on any host". Did you disable this > rule? > > If yes, then you have to have an explicit rules allowing access to specific > services. Thanks! Yes, that was it exactly. I did disable the "allow all" rule on installation, but hadn't set up a specific rule allowing the appropriate group SSH access. I've added the rule, and everything is working as it should now. I'm a very happy sysadmin at the moment. :-) David Guertin From prasun.gera at gmail.com Wed Mar 18 21:39:14 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 18 Mar 2015 17:39:14 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: <5509CE2D.8080108@redhat.com> References: <5509CE2D.8080108@redhat.com> Message-ID: How do I confirm that there are no certs left behind and that cert-monger isn't tracking them? I'm a bit new to all the components used by IPA. I do see that the /root/cacert.p12 file is never deleted. After an uninstall, I see this: getcert list Number of certificates and requests being tracked: 0. getcert status process 31282: arguments to dbus_message_new_method_call() were incorrect, assertion "path != NULL" failed in file dbus-message.c line 1262. This is normally a bug in some application using the D-Bus library. D-Bus not built with -rdynamic so unable to print a backtrace Aborted (core dumped) I ran a few more tests, and I have had partial success with some configurations. Here's what I found: 1) The install-uninstall-install sequence definitely seems to be broken (at least for my configuration), and should be reproducible fairly easily. I would like to reproduce this consistently in a docker image/vm, but docker is apparently not supported on satellite subscribed RHEL systems. The only variable in the system is dns(external) and the choice of ipa domain name. The ipa server setup was pretty stock with no integrated dns. I don't know if some ipa domain names are preferred over others, but I feel that it shouldn't affect the client on the server at least. 2) I had some success with reboots. i.e. After the last install, rebooting the computer solves the problem for some cases at least. I am not sure if it is a general solution. I think it's also related to the choice of the domain name. The reboot trick doesn't help if the ipa domain name is the one derived from hostname. It did work for a random domain name though. 3) I need to understand how important the IPA domain name is. Should the ipa domain name be related to the hostname of the server (as suggested by the script)? What happens if someone else has another ipa server with the same domain name on the network? Also, what happens if there is another NIS server with the same domain name on the network? And lastly, what if the ipa server is setup on an existing NIS server or an NIS client ? I have tried a lot of permutations, and I have a feeling that this problem is somehow tied to the name resolution, and domain names, with external dns servers possibly playing a part. I'll post the logs if I can't make progress. Regards, Prasun On Wed, Mar 18, 2015 at 3:12 PM, Dmitri Pal wrote: > On 03/17/2015 02:54 PM, Prasun Gera wrote: > > Sorry, the message got sent accidentally earlier before I could provide > all the details. > > Version: 4.1.0 on RHEL 7.1 x86_64 > > Steps: > 1. ipa-server-install > 2. service sshd restart > 3. kinit admin <- This always works > 4. ssh admin at localhost <- This works for the first time, > fails second time onwards > ssh admin at host_addr from external system <- This also works the > first time, fails second time onwards > > 5. ipa-server-install --uninstall > 6. go to 1 > > The log messages in /var/log/messages point to [sssd[krb5_child[21029]]]: > Decrypt integrity check failed at the point of the authentication failure > sssd's log's have a lot of "No matching domain found for user" messages. > /var/log/krb5kdc.log has a lot of error decoding FAST: > for , Decrypt integrity check failed while handling > ap-request armor > > The only ERROR I can see in /var/log/ipaserver-uninstall.log is > pkidestroy : ERROR ....... subprocess.CalledProcessError: Command > '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', ......returned > non-zero exit status 6! > > > It appears that the uninstall process is leaving some residual > configuration behind which is conflicting with the subsequent installation > with the same domain name > > > > SSSD and certificate issues with re-install would be unrelated. > > > Let us start over. Remove IPA, try it several times, it helps sometimes as > it moves forward and cleans more on each attempt. Make sure there are no > certs left and certmonger is not tracking anything. > If you still experience issues with SSSD, add debug_level=10 to sssd > configuration in the domain section, restart sssd and send the sanitized > logs for the failed attempts. > > > > > Regards, > Prasun > > > > > > > > On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera > wrote: > >> Hello, >> I installed the ipa-server on an RHEL 7.1 system, uninstalled it and >> reinstalled it with the same domain name as the first time. This somehow >> creates problems with ssh authentication on the server from external >> systems as well as from the server itself. >> >> Steps: >> 1. ipa-server-install >> 2. service sshd restart >> 3. kinit admin >> 4. ssh admin at localhost >> > > > > > > -- > 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 Wed Mar 18 21:55:52 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 18 Mar 2015 17:55:52 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: References: <5509CE2D.8080108@redhat.com> Message-ID: <5509F468.2040400@redhat.com> Prasun Gera wrote: > How do I confirm that there are no certs left behind and that > cert-monger isn't tracking them? I'm a bit new to all the components > used by IPA. I do see that the /root/cacert.p12 file is never deleted. Not clean but this shouldn't prevent re-install. > After an uninstall, I see this: > getcert list > Number of certificates and requests being tracked: 0. > > getcert status > process 31282: arguments to dbus_message_new_method_call() were > incorrect, assertion "path != NULL" failed in file dbus-message.c line 1262. > This is normally a bug in some application using the D-Bus library. > D-Bus not built with -rdynamic so unable to print a backtrace > Aborted (core dumped) Please open a bug against certmonger. > > > I ran a few more tests, and I have had partial success with some > configurations. Here's what I found: > > 1) The install-uninstall-install sequence definitely seems to be broken > (at least for my configuration), and should be reproducible fairly > easily. I would like to reproduce this consistently in a docker > image/vm, but docker is apparently not supported on satellite subscribed > RHEL systems. The only variable in the system is dns(external) and the > choice of ipa domain name. The ipa server setup was pretty stock with no > integrated dns. I don't know if some ipa domain names are preferred over > others, but I feel that it shouldn't affect the client on the server at > least. I think IPA in docker is still rather experimental. Are you re-installing within a docker image? > 2) I had some success with reboots. i.e. After the last install, > rebooting the computer solves the problem for some cases at least. I am > not sure if it is a general solution. I think it's also related to the > choice of the domain name. The reboot trick doesn't help if the ipa > domain name is the one derived from hostname. It did work for a random > domain name though. I don't know why the domain name would make a difference one way or another. > 3) I need to understand how important the IPA domain name is. Should the > ipa domain name be related to the hostname of the server (as suggested > by the script)? What happens if someone else has another ipa server with > the same domain name on the network? Also, what happens if there is > another NIS server with the same domain name on the network? And lastly, > what if the ipa server is setup on an existing NIS server or an NIS > client ? I have tried a lot of permutations, and I have a feeling that > this problem is somehow tied to the name resolution, and domain names, > with external dns servers possibly playing a part. IPA just needs valid DNS names. It doesn't matter where they come from or what they are. There can be a conflict with realm names if you want to rely on DNS discovery and there are conflicts (with AD for example). rob > > I'll post the logs if I can't make progress. > > Regards, > Prasun > > On Wed, Mar 18, 2015 at 3:12 PM, Dmitri Pal > wrote: > > On 03/17/2015 02:54 PM, Prasun Gera wrote: >> Sorry, the message got sent accidentally earlier before I could >> provide all the details. >> >> Version: 4.1.0 on RHEL 7.1 x86_64 >> >> Steps: >> 1. ipa-server-install >> 2. service sshd restart >> 3. kinit admin <- This always works >> 4. ssh admin at localhost <- This works for the first >> time, fails second time onwards >> ssh admin at host_addr from external system <- This also >> works the first time, fails second time onwards >> >> 5. ipa-server-install --uninstall >> 6. go to 1 >> >> The log messages in /var/log/messages point >> to [sssd[krb5_child[21029]]]: Decrypt integrity check failed at >> the point of the authentication failure >> sssd's log's have a lot of "No matching domain found for user" >> messages. >> /var/log/krb5kdc.log has a lot of error decoding FAST: > client> for , Decrypt integrity check failed while >> handling ap-request armor >> >> The only ERROR I can see in /var/log/ipaserver-uninstall.log is >> pkidestroy : ERROR ....... subprocess.CalledProcessError: >> Command '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', >> ......returned non-zero exit status 6! >> >> >> It appears that the uninstall process is leaving some residual >> configuration behind which is conflicting with the subsequent >> installation with the same domain name > > > SSSD and certificate issues with re-install would be unrelated. > > > Let us start over. Remove IPA, try it several times, it helps > sometimes as it moves forward and cleans more on each attempt. Make > sure there are no certs left and certmonger is not tracking anything. > If you still experience issues with SSSD, add debug_level=10 to sssd > configuration in the domain section, restart sssd and send the > sanitized logs for the failed attempts. > > >> >> >> Regards, >> Prasun >> >> >> >> >> >> >> >> On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera >> > wrote: >> >> Hello, >> I installed the ipa-server on an RHEL 7.1 system, uninstalled >> it and reinstalled it with the same domain name as the first >> time. This somehow creates problems with ssh authentication on >> the server from external systems as well as from the server >> itself. >> >> Steps: >> 1. ipa-server-install >> 2. service sshd restart >> 3. kinit admin >> 4. ssh admin at localhost >> >> >> >> > > > -- > 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 prasun.gera at gmail.com Wed Mar 18 22:35:35 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 18 Mar 2015 18:35:35 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: <5509F468.2040400@redhat.com> References: <5509CE2D.8080108@redhat.com> <5509F468.2040400@redhat.com> Message-ID: No I haven't been using docker images. I was merely suggesting it as a way of reproducing the failure consistently and passing it on. I have been running everything natively. Barring external factors such as DNS, which probably don't matter in this case, I think this should be reproducible on an up to date RHEL 7 system. From your comments, I guess the domain name is not that important; at least not on the server itself since the client on the server should have no trouble finding the server. The specific cases for which reboot works could be a red herring, and not related to the domain name at all. However, any success I've had so far has only been with reboots, the choice of domain name notwithstanding. Is there a checklist of files that need to be cleaned up after an uninstall? I can try doing a manual wipe if that helps. On Wed, Mar 18, 2015 at 5:55 PM, Rob Crittenden wrote: > Prasun Gera wrote: > > How do I confirm that there are no certs left behind and that > > cert-monger isn't tracking them? I'm a bit new to all the components > > used by IPA. I do see that the /root/cacert.p12 file is never deleted. > > Not clean but this shouldn't prevent re-install. > > > After an uninstall, I see this: > > getcert list > > Number of certificates and requests being tracked: 0. > > > > getcert status > > process 31282: arguments to dbus_message_new_method_call() were > > incorrect, assertion "path != NULL" failed in file dbus-message.c line > 1262. > > This is normally a bug in some application using the D-Bus library. > > D-Bus not built with -rdynamic so unable to print a backtrace > > Aborted (core dumped) > > Please open a bug against certmonger. > > > > > > > I ran a few more tests, and I have had partial success with some > > configurations. Here's what I found: > > > > 1) The install-uninstall-install sequence definitely seems to be broken > > (at least for my configuration), and should be reproducible fairly > > easily. I would like to reproduce this consistently in a docker > > image/vm, but docker is apparently not supported on satellite subscribed > > RHEL systems. The only variable in the system is dns(external) and the > > choice of ipa domain name. The ipa server setup was pretty stock with no > > integrated dns. I don't know if some ipa domain names are preferred over > > others, but I feel that it shouldn't affect the client on the server at > > least. > > I think IPA in docker is still rather experimental. Are you > re-installing within a docker image? > > > 2) I had some success with reboots. i.e. After the last install, > > rebooting the computer solves the problem for some cases at least. I am > > not sure if it is a general solution. I think it's also related to the > > choice of the domain name. The reboot trick doesn't help if the ipa > > domain name is the one derived from hostname. It did work for a random > > domain name though. > > I don't know why the domain name would make a difference one way or > another. > > > 3) I need to understand how important the IPA domain name is. Should the > > ipa domain name be related to the hostname of the server (as suggested > > by the script)? What happens if someone else has another ipa server with > > the same domain name on the network? Also, what happens if there is > > another NIS server with the same domain name on the network? And lastly, > > what if the ipa server is setup on an existing NIS server or an NIS > > client ? I have tried a lot of permutations, and I have a feeling that > > this problem is somehow tied to the name resolution, and domain names, > > with external dns servers possibly playing a part. > > IPA just needs valid DNS names. It doesn't matter where they come from > or what they are. > > There can be a conflict with realm names if you want to rely on DNS > discovery and there are conflicts (with AD for example). > > rob > > > > > I'll post the logs if I can't make progress. > > > > Regards, > > Prasun > > > > On Wed, Mar 18, 2015 at 3:12 PM, Dmitri Pal > > wrote: > > > > On 03/17/2015 02:54 PM, Prasun Gera wrote: > >> Sorry, the message got sent accidentally earlier before I could > >> provide all the details. > >> > >> Version: 4.1.0 on RHEL 7.1 x86_64 > >> > >> Steps: > >> 1. ipa-server-install > >> 2. service sshd restart > >> 3. kinit admin <- This always works > >> 4. ssh admin at localhost <- This works for the first > >> time, fails second time onwards > >> ssh admin at host_addr from external system <- This also > >> works the first time, fails second time onwards > >> > >> 5. ipa-server-install --uninstall > >> 6. go to 1 > >> > >> The log messages in /var/log/messages point > >> to [sssd[krb5_child[21029]]]: Decrypt integrity check failed at > >> the point of the authentication failure > >> sssd's log's have a lot of "No matching domain found for user" > >> messages. > >> /var/log/krb5kdc.log has a lot of error decoding FAST: >> client> for , Decrypt integrity check failed while > >> handling ap-request armor > >> > >> The only ERROR I can see in /var/log/ipaserver-uninstall.log is > >> pkidestroy : ERROR ....... subprocess.CalledProcessError: > >> Command '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', > >> ......returned non-zero exit status 6! > >> > >> > >> It appears that the uninstall process is leaving some residual > >> configuration behind which is conflicting with the subsequent > >> installation with the same domain name > > > > > > SSSD and certificate issues with re-install would be unrelated. > > > > > > Let us start over. Remove IPA, try it several times, it helps > > sometimes as it moves forward and cleans more on each attempt. Make > > sure there are no certs left and certmonger is not tracking anything. > > If you still experience issues with SSSD, add debug_level=10 to sssd > > configuration in the domain section, restart sssd and send the > > sanitized logs for the failed attempts. > > > > > >> > >> > >> Regards, > >> Prasun > >> > >> > >> > >> > >> > >> > >> > >> On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera > >> > wrote: > >> > >> Hello, > >> I installed the ipa-server on an RHEL 7.1 system, uninstalled > >> it and reinstalled it with the same domain name as the first > >> time. This somehow creates problems with ssh authentication on > >> the server from external systems as well as from the server > >> itself. > >> > >> Steps: > >> 1. ipa-server-install > >> 2. service sshd restart > >> 3. kinit admin > >> 4. ssh admin at localhost > >> > >> > >> > >> > > > > > > -- > > 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 prasun.gera at gmail.com Thu Mar 19 01:50:33 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Wed, 18 Mar 2015 21:50:33 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: References: <5509CE2D.8080108@redhat.com> <5509F468.2040400@redhat.com> Message-ID: I think I have figured it out. The contents of /var/lib/sss/db are not cleared on uninstall. Stopping sssd, clearing that directory and restarting sssd solves the problem. Is there a reason why this is not cleared on uninstall? On Wed, Mar 18, 2015 at 6:35 PM, Prasun Gera wrote: > No I haven't been using docker images. I was merely suggesting it as a way > of reproducing the failure consistently and passing it on. I have been > running everything natively. Barring external factors such as DNS, which > probably don't matter in this case, I think this should be reproducible on > an up to date RHEL 7 system. From your comments, I guess the domain name is > not that important; at least not on the server itself since the client on > the server should have no trouble finding the server. The specific cases > for which reboot works could be a red herring, and not related to the > domain name at all. However, any success I've had so far has only been with > reboots, the choice of domain name notwithstanding. Is there a checklist of > files that need to be cleaned up after an uninstall? I can try doing a > manual wipe if that helps. > > On Wed, Mar 18, 2015 at 5:55 PM, Rob Crittenden > wrote: > >> Prasun Gera wrote: >> > How do I confirm that there are no certs left behind and that >> > cert-monger isn't tracking them? I'm a bit new to all the components >> > used by IPA. I do see that the /root/cacert.p12 file is never deleted. >> >> Not clean but this shouldn't prevent re-install. >> >> > After an uninstall, I see this: >> > getcert list >> > Number of certificates and requests being tracked: 0. >> > >> > getcert status >> > process 31282: arguments to dbus_message_new_method_call() were >> > incorrect, assertion "path != NULL" failed in file dbus-message.c line >> 1262. >> > This is normally a bug in some application using the D-Bus library. >> > D-Bus not built with -rdynamic so unable to print a backtrace >> > Aborted (core dumped) >> >> Please open a bug against certmonger. >> >> > >> > >> > I ran a few more tests, and I have had partial success with some >> > configurations. Here's what I found: >> > >> > 1) The install-uninstall-install sequence definitely seems to be broken >> > (at least for my configuration), and should be reproducible fairly >> > easily. I would like to reproduce this consistently in a docker >> > image/vm, but docker is apparently not supported on satellite subscribed >> > RHEL systems. The only variable in the system is dns(external) and the >> > choice of ipa domain name. The ipa server setup was pretty stock with no >> > integrated dns. I don't know if some ipa domain names are preferred over >> > others, but I feel that it shouldn't affect the client on the server at >> > least. >> >> I think IPA in docker is still rather experimental. Are you >> re-installing within a docker image? >> >> > 2) I had some success with reboots. i.e. After the last install, >> > rebooting the computer solves the problem for some cases at least. I am >> > not sure if it is a general solution. I think it's also related to the >> > choice of the domain name. The reboot trick doesn't help if the ipa >> > domain name is the one derived from hostname. It did work for a random >> > domain name though. >> >> I don't know why the domain name would make a difference one way or >> another. >> >> > 3) I need to understand how important the IPA domain name is. Should the >> > ipa domain name be related to the hostname of the server (as suggested >> > by the script)? What happens if someone else has another ipa server with >> > the same domain name on the network? Also, what happens if there is >> > another NIS server with the same domain name on the network? And lastly, >> > what if the ipa server is setup on an existing NIS server or an NIS >> > client ? I have tried a lot of permutations, and I have a feeling that >> > this problem is somehow tied to the name resolution, and domain names, >> > with external dns servers possibly playing a part. >> >> IPA just needs valid DNS names. It doesn't matter where they come from >> or what they are. >> >> There can be a conflict with realm names if you want to rely on DNS >> discovery and there are conflicts (with AD for example). >> >> rob >> >> > >> > I'll post the logs if I can't make progress. >> > >> > Regards, >> > Prasun >> > >> > On Wed, Mar 18, 2015 at 3:12 PM, Dmitri Pal > > > wrote: >> > >> > On 03/17/2015 02:54 PM, Prasun Gera wrote: >> >> Sorry, the message got sent accidentally earlier before I could >> >> provide all the details. >> >> >> >> Version: 4.1.0 on RHEL 7.1 x86_64 >> >> >> >> Steps: >> >> 1. ipa-server-install >> >> 2. service sshd restart >> >> 3. kinit admin <- This always works >> >> 4. ssh admin at localhost <- This works for the first >> >> time, fails second time onwards >> >> ssh admin at host_addr from external system <- This also >> >> works the first time, fails second time onwards >> >> >> >> 5. ipa-server-install --uninstall >> >> 6. go to 1 >> >> >> >> The log messages in /var/log/messages point >> >> to [sssd[krb5_child[21029]]]: Decrypt integrity check failed at >> >> the point of the authentication failure >> >> sssd's log's have a lot of "No matching domain found for user" >> >> messages. >> >> /var/log/krb5kdc.log has a lot of error decoding FAST: > >> client> for , Decrypt integrity check failed while >> >> handling ap-request armor >> >> >> >> The only ERROR I can see in /var/log/ipaserver-uninstall.log is >> >> pkidestroy : ERROR ....... subprocess.CalledProcessError: >> >> Command '['/usr/bin/sslget', '-n', 'subsystemCert cert-pki-ca', >> >> ......returned non-zero exit status 6! >> >> >> >> >> >> It appears that the uninstall process is leaving some residual >> >> configuration behind which is conflicting with the subsequent >> >> installation with the same domain name >> > >> > >> > SSSD and certificate issues with re-install would be unrelated. >> > >> > >> > Let us start over. Remove IPA, try it several times, it helps >> > sometimes as it moves forward and cleans more on each attempt. Make >> > sure there are no certs left and certmonger is not tracking >> anything. >> > If you still experience issues with SSSD, add debug_level=10 to sssd >> > configuration in the domain section, restart sssd and send the >> > sanitized logs for the failed attempts. >> > >> > >> >> >> >> >> >> Regards, >> >> Prasun >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Tue, Mar 17, 2015 at 2:41 PM, Prasun Gera >> >> > wrote: >> >> >> >> Hello, >> >> I installed the ipa-server on an RHEL 7.1 system, uninstalled >> >> it and reinstalled it with the same domain name as the first >> >> time. This somehow creates problems with ssh authentication on >> >> the server from external systems as well as from the server >> >> itself. >> >> >> >> Steps: >> >> 1. ipa-server-install >> >> 2. service sshd restart >> >> 3. kinit admin >> >> 4. ssh admin at localhost >> >> >> >> >> >> >> >> >> > >> > >> > -- >> > 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 andrew.holway at gmail.com Thu Mar 19 07:42:42 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 19 Mar 2015 08:42:42 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <5509B1D0.1050602@redhat.com> References: <5509B1D0.1050602@redhat.com> Message-ID: Cool stuff. Thanks. I had a look at our SRV records and found the following: _kerberos-master._tcp _kerberos-master._udp _kerberos._tcp _kerberos._udp _kpasswd._tcp _kpasswd._udp _ldap._tcp _ntp._udp No mention of and ipa srv records. Does sssd use _ldap._tcp? Thanks, Andrew On 18 March 2015 at 18:11, Rob Crittenden > wrote: > Craig White wrote: > > *From:*freeipa-users-bounces at redhat.com > > > [mailto:freeipa-users-bounces at redhat.com > ] *On > Behalf Of *Andrew Holway > > *Sent:* Wednesday, March 18, 2015 9:40 AM > > *To:* freeipa-users at redhat.com > > > *Subject:* [Freeipa-users] SSSD in redundant configuration > > > > > > > > Hello, > > > > > > > > Im wondering how we should be handing SSSD for redundant configurations > > on our freeipa clients. We have three freeipa servers; how can we make > > SSSD check another freeipa in the event that one goes down? > > > > > > > > It appears we can do something like the following: > > > > > > > > ipa_hostname = test-freeipa-client-1.cloud.domain.de > > , > > test-freeipa-client-2.cloud.domain.de > > , > > test-freeipa-client-3.cloud.domain.de > > > > > > > > > > However I thought SRV records were meant to supply the magic here? > > > > > > > > Thanks, > > > > > > > > Andrew > > > > > > > > > > > > /etc/sssd/sssd.conf > > > > [domain/cloud.domain.de ] > > > > cache_credentials = True > > > > krb5_store_password_if_offline = True > > > > ipa_domain = cloud.domain.de > > > > id_provider = ipa > > > > auth_provider = ipa > > > > access_provider = ipa > > > > ipa_hostname = test-freeipa-client-2.cloud.domain.de > > > > > > chpass_provider = ipa > > > > ipa_dyndns_update = True > > > > ipa_server = _srv_, test-freeipa-2.cloud.domain.de > > > > > > ldap_tls_cacert = /etc/ipa/ca.crt > > > > # For the SUDO integration > > > > sudo_provider = ldap > > > > ldap_uri = ldap://test-freeipa-1.cloud.domain.de > > > > > > ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de > > > > ldap_sasl_mech = GSSAPI > > > > ldap_sasl_authid = host/test-freeipa-client-2.cloud.domain.de > > > > > > ldap_sasl_realm = CLOUD.DOMAIN.DE > > > > krb5_server = test-freeipa-2.cloud.domain.de > > > > > > [sssd] > > > > services = nss, pam, ssh, sudo > > > > config_file_version = 2 > > > > domains = cloud.domain.de > > > > [nss] > > > > [pam] > > > > [sudo] > > > > [autofs] > > > > [ssh] > > > > [pac] > > > > I think the magic you are looking for is in /etc/sssd/sssd.conf where > > you have? > > > > ipa_server = _srv_, test-freeipa-2.cloud.domain.de > > > > > > and all you need is? > > > > ipa_server = _srv_ > > _srv_ tells SSSD to check DNS for SRV records. The trailing server gives > it a hardcoded fallback in case DNS fails for some reason. Their current > configuration is correct. > > rob > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tbordaz at redhat.com Thu Mar 19 09:06:58 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Thu, 19 Mar 2015 10:06:58 +0100 Subject: [Freeipa-users] Unable to remove nsTombstone objects In-Reply-To: <5509C23A.70003@redhat.com> References: <5509AD4D.6040403@redhat.com> <5509C23A.70003@redhat.com> Message-ID: <550A91B2.20204@redhat.com> On 03/18/2015 07:21 PM, Rich Megginson wrote: > On 03/18/2015 11:07 AM, Kim Perrin wrote: >> ah, good question. Relevant errors around trying to use the ldif I >> included to remove replica ID 97 -- >> >> [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: >> Waiting for all the replicas to receive all the deleted replica >> updates... >> [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: >> Sending cleanAllRUV task to all the replicas... >> [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: >> Cleaning local ruv's... >> [18/Mar/2015:04:01:51 +0000] NSMMReplicationPlugin - CleanAllRUV Task: >> Waiting for all the replicas to be cleaned... >> [18/Mar/2015:04:01:52 +0000] NSMMReplicationPlugin - CleanAllRUV Task: >> Waiting for all the replicas to finish cleaning... >> [18/Mar/2015:04:01:52 +0000] NSMMReplicationPlugin - CleanAllRUV Task: >> Successfully cleaned rid(14). >> [18/Mar/2015:04:20:18 +0000] - WARNING: can't modify task entry >> 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) >> [18/Mar/2015:04:20:21 +0000] - WARNING: can't modify task entry >> 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) >> [18/Mar/2015:04:20:23 +0000] - WARNING: can't modify task entry >> 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) >> [18/Mar/2015:04:20:23 +0000] NSMMReplicationPlugin - CleanAllRUV Task: >> Replica id (97) is already being cleaned >> [18/Mar/2015:04:20:25 +0000] - WARNING: can't modify task entry >> 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) >> [18/Mar/2015:04:20:27 +0000] - WARNING: can't modify task entry >> 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) >> [18/Mar/2015:04:20:29 +0000] - WARNING: can't modify task entry >> 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) >> [18/Mar/2015:04:20:29 +0000] NSMMReplicationPlugin - CleanAllRUV Task: >> Task failed...(-1) >> [18/Mar/2015:04:20:31 +0000] - WARNING: can't modify task entry >> 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config'; No such object (32) >> [18/Mar/2015:04:20:31 +0000] - WARNING: can't find task entry >> 'cn=clean 97,cn=cleanallruv,cn=tasks,cn=config' >> [18/Mar/2015:04:24:46 +0000] ipa_range_check_pre_op - [file >> ipa_range_check.c, line 235]: Missing entry to modify. > > Not sure what this means. Anyone? This is related to a direct MOD operation where the target entry is not found. This is logged by ipa-range-check but I am not sure if it reveal a real problem. Would you check that at the same time (2015:04:24:46) there is a MOD that returns err=32. The error reported by CleanAllRUV (Task failed) is strange, would you dump the RUV entry (nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca) to see if the clean up 97 occured ? thanks thierry > >> >> >> >> On Wed, Mar 18, 2015 at 9:52 AM, Rich Megginson >> wrote: >>> On 03/18/2015 10:50 AM, Kim Perrin wrote: >>>> Hi all, >>>> yesterday I cleared up replication problems on my last standing IPA >>>> server. So I somewhat feel like I'm coming out of the tunnel. Today I >>>> want to turn up a replica again. However before doing so I'd like to >>>> clean out the last remnants of data about all previous replicas. >>>> I can't figure out the properly formatted ldif to use to remove the >>>> nsds50ruv and the nsruvReplicaLastModified records in these entries. >>>> Any guidance on the proper ldif to use would be much appreciated -- >>>> Here is are the tombstone entries - >>>> >>>> dn: nsuniqueid=ffffffff-ffffffff-ffffffff-ffffffff,o=ipaca >>>> objectClass: top >>>> objectClass: nsTombstone >>>> objectClass: extensibleobject >>>> nsds50ruv: {replicageneration} 5317a449000000600000 >>>> nsds50ruv: {replica 96 ldap://noc1-prd.companyz.com:7389} >>>> 5317a455000000 >>>> 600000 550878b9000000600000 >>>> nsds50ruv: {replica 71 ldap://noc2-prd.companyz.com:7389} >>>> 531ce018000000 >>>> 470000 531ce069000300470000 >>>> nsds50ruv: {replica 76 ldap://noc4-prd.companyz.com:7389} >>>> 531cdde8000000 >>>> 4c0000 53f659500004004c0000 >>>> nsds50ruv: {replica 81 ldap://noc2-prd.companyz.com:7389} >>>> 531bf216000000 >>>> 510000 531bf265000100510000 >>>> nsds50ruv: {replica 86 ldap://noc3-prd.companyz.com:7389} >>>> 531a3222000000 >>>> 560000 531a3256000400560000 >>>> nsds50ruv: {replica 91 ldap://noc2-prd.companyz.com:7389} >>>> 5317f7cf000000 >>>> 5b0000 531949920000005b0000 >>>> nsds50ruv: {replica 97 ldap://util1-prd.companyz.com:7389} >>>> 5317a45000000 >>>> 0610000 5317a48a000100610000 >>>> o: ipaca >>>> nsruvReplicaLastModified: {replica 96 >>>> ldap://noc1-prd.companyz.com:7389} >>>> 550878ab >>>> nsruvReplicaLastModified: {replica 71 >>>> ldap://noc2-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 76 >>>> ldap://noc4-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 81 >>>> ldap://noc2-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 86 >>>> ldap://noc3-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 91 >>>> ldap://noc2-prd.companyz.com:7389} >>>> 00000000 >>>> nsruvReplicaLastModified: {replica 97 >>>> ldap://util1prd.companyz.com:7389} >>>> 00000000 >>>> >>>> >>>> >>>> Using the following to clean these did NOT work - >>>> >>>> dn: cn=clean 97,cn=cleanallruv,cn=tasks,cn=config >>>> changetype: add >>>> objectclass: top >>>> objectclass: extensibleObject >>>> replica-base-dn: dc=companyz,dc=com >>>> replica-id: 97 >>>> cn: clean 97 >>>> >>> Any errors in /var/log/dirsrv/slapd-DOMAIN/errors? >>> >>> -- >>> 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 g.fer.ordas at unicyber.co.uk Thu Mar 19 09:10:14 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Thu, 19 Mar 2015 09:10:14 +0000 Subject: [Freeipa-users] Fwd: Re: AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: <550737A2.10807@redhat.com> References: <55032968.5010500@redhat.com> <55032FE4.5030208@redhat.com> <55034397.4030008@unicyber.co.uk> <550345FF.9040407@redhat.com> <55035011.9080507@redhat.com> <98c0441da909fe42d1e266c3c46b3949@unicyber.co.uk> <3bccb84836c1afa05d3e78e01c30bbde@unicyber.co.uk> <550737A2.10807@redhat.com> Message-ID: <550A9276.7060409@unicyber.co.uk> Hi I have completed changed the scenario and I managed to install freeipa-server 4.1 (Somebody publish the right repo for Centos and it worked really well) --Let me double check a couple of things. You wrote you installed PassSync on Windows 2013 (which could be a typo?) We support Windows Server 2008 R2 and 2012 R2. We also confirmed it works on Windows Server 2003 R2. Yes, sorry, that was a typo. So, starting again from scratch, new machine, the whole installation process went well, not issues there but: * FreeIPA is supposed to generate a PassSync user by running ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also man ipa-replica-manage). I tried 5 times, the user was never created on the ipa server, I had to create it manually (I gave it admin permissions so it could create/delete/update users). Doing that, the password sync worked all right. We submit a password reset in AD and that propagated all right, tested and it worked fine. / * In one scenario I uninstalled freeipa (still kept the packages), installed again and something went wrong with the kerberos keys. After creating the AD --> LDAP certs and successfully syncing the passwords, I could read in the /var/log/messages a password decryption issue (kerberos related) everytime I tried to log as any user. I have tried uninstalling freeipa and also uninstalling removing the product completely and re-installing. it did not matter if I tried to rebuild the kerberos keys, the issue was always there, so I have to start afresh with a new box. So.. that has been all so far Thanks Gonzalo On 16/03/2015 20:05, Noriko Hosoi wrote: > Hello, Gonzalo, > > Any progress on your Password Synchronization? > > Let me double check a couple of things. You wrote you installed > PassSync on Windows 2013 (which could be a typo?) We support Windows > Server 2008 R2 and 2012 R2. We also confirmed it works on Windows > Server 2003 R2. > > On 03/13/2015 12:45 PM,g.fer.ordas at unicyber.co.uk wrote: > >> I got the Password Sync Tool installed in the Windows2013 box > You can find the doc on PassSync here. > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#windows-pass-sync > The doc is on PassSync 1.1.5, but 1.1.6 remains intact except the > default SSL version to connect to the 389 Directory Server (as we > discussed before). > > We had a dicussion regarding the PassSync user you had to create: > uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com > FreeIPA is supposed to generate a PassSync user by running > ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also > man ipa-replica-manage)./ > > there must some problem as FreeIPA > > creates own Passsync user in "cn=sysaccounts,cn=etc," also sets it's DN > > as passSyncManagersDNs in ipa_pwd_extop plugin to avoid it creating expired > > passwords. So there is no need to create > > "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" manually. > Please see the above doc regarding the user creation. > > * > The username of the system user which Active Directory uses to > connect to the IdM machine. This account is configured > automatically when sync is configured on the IdM server. The > default account is > |uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com|. > * > The password set in the |--passsync| option when the sync > agreement was created. > > I'm sending this response to freeipa-users to share the info and > request for more suggestions. > > Thanks, > --noriko > > On 03/13/2015 02:48 PM, g.fer.ordas at unicyber.co.uk wrote: >> I forgot to attach the search command now: >> # passsync, users, accounts, corp.company.com >> dn: uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com >> cn: passsync >> displayName: passsync >> krbLastFailedAuth: 20150313211546Z >> krbLoginFailedCount: 1 >> krbExtraData:: AALUUQNVcm9vdC9hZG1pbkBDT1JQLkhPT1RTVUlURU1FRElBLkNPTQA= >> memberOf: cn=ipausers,cn=groups,cn=accounts,dc=corp,dc=company,dc=com >> krbLastPwdChange: 20150313210836Z >> krbPasswordExpiration: 20150611210836Z >> mepManagedEntry: cn=passsync,cn=groups,cn=accounts,dc=corp,dc=company,d >> c=com >> objectClass: top >> objectClass: person >> objectClass: organizationalperson >> objectClass: inetorgperson >> objectClass: inetuser >> objectClass: posixaccount >> objectClass: krbprincipalaux >> objectClass: krbticketpolicyaux >> objectClass: ipaobject >> objectClass: ipasshuser >> objectClass: ipaSshGroupOfPubKeys >> objectClass: mepOriginEntry >> loginShell: /bin/bash >> gecos: pass sync >> sn: sync >> homeDirectory: /home/passsync >> uid: passsync >> mail: passsync at corp.company.com >> krbPrincipalName: passsync at CORP.company.COM >> givenName: pass >> initials: ps >> userPassword:: zxxxxxxxx= >> = >> ipaUniqueID: 1d76b14a-c9c5-11e4-93f4-12d2e19d1e3c >> uidNumber: 1481000829 >> gidNumber: 1481000829 >> krbPrincipalKey:: dfrerererer >> >> # search result >> search: 2 >> >> >> On 2015-03-13 21:39, g.fer.ordas at unicyber.co.uk wrote: >>> Hi >>> >>> I had to manually create the user!! For some reason I thought the sync >>> Agreement task was also creating that entry for the DS! >>> >>> So now I got: >>> >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=4 SRCH >>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>> scope=0 filter="(objectClass=*)" attrs="telephoneNumber uid title >>> loginShell uidNumber gidNumber sn homeDirectory mail ou givenName >>> nsAccountLock" >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=4 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=5 SRCH >>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>> scope=0 filter="(userPassword=*)" attrs="userPassword" >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=5 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=6 SRCH >>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>> scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey" >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=6 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=7 SRCH >>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>> scope=0 filter="(objectClass=*)" attrs="ipaSshPubKey" >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=7 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=8 UNBIND >>> [13/Mar/2015:14:27:30 -0700] conn=66 op=8 fd=103 closed - U1 >>> [13/Mar/2015:14:27:33 -0700] conn=48 op=20 RESULT err=0 tag=101 >>> nentries=828 etime=90 notes=U >>> [13/Mar/2015:14:27:33 -0700] conn=48 op=21 ABANDON targetop=NOTFOUND >>> msgid=16 >>> [13/Mar/2015:14:27:33 -0700] conn=48 op=22 SRCH >>> base="cn=users,cn=accounts,dc=corp,dc=company,dc=com" scope=0 >>> filter="(objectClass=*)" attrs="* aci" >>> [13/Mar/2015:14:27:33 -0700] conn=48 op=22 RESULT err=0 tag=101 >>> nentries=1 etime=0 >>> [13/Mar/2015:14:27:33 -0700] conn=48 op=23 ABANDON targetop=NOTFOUND >>> msgid=18 >>> [13/Mar/2015:14:27:42 -0700] conn=67 fd=103 slot=103 connection from >>> ::1 to ::1 >>> [13/Mar/2015:14:27:42 -0700] conn=67 op=0 BIND dn="cn=directory >>> manager" method=128 version=3 >>> [13/Mar/2015:14:27:42 -0700] conn=67 op=0 RESULT err=0 tag=97 >>> nentries=0 etime=0 dn="cn=directory manager" >>> [13/Mar/2015:14:27:42 -0700] conn=67 op=1 SRCH >>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>> scope=2 filter="(objectClass=*)" attrs=ALL >>> [13/Mar/2015:14:27:42 -0700] conn=67 op=1 RESULT err=0 tag=101 >>> nentries=1 etime=0 notes=U >>> [13/Mar/2015:14:27:42 -0700] conn=67 op=2 UNBIND >>> [13/Mar/2015:14:27:42 -0700] conn=67 op=2 fd=103 closed - U1 >>> >>> And target not found??? what else I might be missing ? >>> >>> Thanks! >>> >>> >>> On 2015-03-13 21:01, Noriko Hosoi wrote: >>>> On 03/13/2015 01:49 PM, g.fer.ordas at unicyber.co.uk wrote: >>>>> Hi >>>>> >>>>> Restarted... And I also have re-initiated the replica just in >>>>> case.... >>>>> >>>>> I can see the following: >>>>> --- >>>>> 3/Mar/2015:13:41:35 -0700] conn=34 op=329 RESULT err=0 tag=101 >>>>> nentries=1 etime=0 >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 fd=84 slot=84 SSL connection >>>>> from AD.SERVER to IPA.SERVER >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 SSL 128-bit AES >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 BIND >>>>> dn="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>> method=128 version=3 >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 RESULT err=32 tag=97 >>>>> nentries=0 etime=0 >>>> Error 32 is LDAP_NO_SUCH_OBJECT. >>>> Do you have a user >>>> "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" in your >>>> Directory Server? >>>> >>>> On the host/VM where your Direcotry Server is running, please run this >>>> command line search. Does it return the entry? >>>> ldapsearch -x -h localhost -p 389 -D 'cn=directory manager' -W -b >>>> "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=1 SRCH >>>>> base="cn=users,cn=accounts,dc=corp,dc=company,dc=com" scope=2 >>>>> filter="(ntUserDomainId=john.test)" attrs=ALL >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=1 RESULT err=0 tag=101 >>>>> nentries=1 etime=0 >>>>> [13/Mar/2015:13:41:36 -0700] conn=34 op=330 SRCH >>>>> base="cn=meTohqdc1.corp.company.com,cn=replica,cn=dc\3Dcorp\2Cdc\3Dcompany\2Cdc\3Dcom,cn=mapping >>>>> tree,cn=config" scope=0 filter="(objectClass=*)" >>>>> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >>>>> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >>>>> nsds5replicaLastInitEnd" >>>>> [13/Mar/2015:13:41:36 -0700] conn=34 op=330 RESULT err=0 tag=101 >>>>> nentries=1 etime=0 >>>>> [13/Mar/2015:13:41:36 -0700] conn=36 fd=101 slot=101 SSL >>>>> connection from AD.SERVER to IPA.SERVER >>>>> [13/Mar/2015:13:41:36 -0700] conn=36 SSL 128-bit AES >>>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=0 BIND >>>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>> method=128 version=3 >>>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=0 RESULT err=48 tag=97 >>>>> nentries=0 etime=0 >>>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=1 UNBIND >>>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=1 fd=101 closed - U1 >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=2 MOD >>>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=2 RESULT err=50 tag=103 >>>>> nentries=0 etime=0 >>>> Since the above bind failed, your PassSync has no right to update the >>>> password on the Directory Server and the modify attempt failed with >>>> LDAP_INSUFFICIENT_ACCESS. >>>> >>>> Thanks, >>>> --noriko >>>>> [13/Mar/2015:13:41:37 -0700] conn=35 op=3 UNBIND >>>>> [13/Mar/2015:13:41:37 -0700] conn=35 op=3 fd=84 closed - U1 >>>>> >>>>> -- >>>>> >>>>> Note there are 2 errors there: >>>>> dn="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>> method=128 version=3 >>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 RESULT err=32 tag=97 >>>>> nentries=0 etime=0 >>>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>> method=128 version=3 >>>>> >>>>> ipa user-show John.Test >>>>> >>>>> User login: john.test >>>>> >>>>> First name: John >>>>> >>>>> Last name: Test >>>>> >>>>> Home directory: /home/john.test >>>>> >>>>> Login shell: /bin/bash >>>>> >>>>> UID: 1481000790 >>>>> >>>>> GID: 1481000790 >>>>> >>>>> Account disabled: False >>>>> >>>>> Password: False >>>>> >>>>> Kerberos keys available: False >>>>> >>>>> >>>>> the password is still set as False >>>>> The PassSync Tool got defined as base search: >>>>> >>>>> cn=users,cn=accounts,dc=corp,dc=company,dc=com .. Which should be >>>>> all right >>>>> >>>>> Thanks for all your help! >>>>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 19 09:29:24 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 10:29:24 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: References: <5509B1D0.1050602@redhat.com> Message-ID: <20150319092924.GD3591@hendrix.arn.redhat.com> On Thu, Mar 19, 2015 at 08:42:42AM +0100, Andrew Holway wrote: > Cool stuff. Thanks. > > I had a look at our SRV records and found the following: > _kerberos-master._tcp > _kerberos-master._udp > _kerberos._tcp > _kerberos._udp > _kpasswd._tcp > _kpasswd._udp > _ldap._tcp > _ntp._udp > > No mention of and ipa srv records. Does sssd use _ldap._tcp? Yes, for the IPA back end it does. For the AD back end we use the special MS records for looking up sites or Global Catalog servers, but for IPA we stick to the standard services. From roberto.cornacchia at gmail.com Thu Mar 19 09:29:46 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Thu, 19 Mar 2015 10:29:46 +0100 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: <54F97E3A.6090803@redhat.com> References: <54F97E3A.6090803@redhat.com> Message-ID: On 6 March 2015 at 11:15, Martin Kosek wrote: > On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: > >> Hi there, >> >> I'm planning to deploy freeIPA on our lan. >> It's small-ish and completely based on FC21, so I expect everything to >> work >> like a charm. >> >> Except one detail. We have Synology NAS station, which uses DSM 5.0. >> The ideal plan is to use it as host for shared NFS home dirs once we >> switch our >> desktops to freeIPA. >> > > Great! > >> >> Hello, The first thing I'm struggling with is to find the correct approach about NFS home dirs. The ideal setting would be: - home dirs on the NAS - IPA manages automount maps - home dirs are created automatically at first login The documentation I could find on these topics includes only not-so-recent pages (anything I missed?): http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/ Now, I admit I don't have much experience with setting up NFS homes, with or without freeIPA, so trying to get this done correctly in the context of freeIPA and without clear howtos isn't very easy, but I'm willing to get my hands dirty. The first problem I struggle with is on the correct approach. >From the documentation above, I understand that there is a bit of a chicken-egg problem about the creation of home dirs. On the one hand, it would be optimal to have automount maps to load only single home dirs on demand, rather than the entire /home tree. On the other hand, if the /home tree is not available, then creating /home/user1 dir automatically isn't really possible. Just mounting the whole /home tree would make things easier, but I don't have a feeling of when it starts to become a performance issue (assuming recent hardware and up to date software). 10 users? 50? 100? 500? No idea. The realm I'm dealing with at the moment is in the range of 5-10 users and probably won't be larger than 50 in the next few years (and if it will, it means things are going well, so what the heck ;) Also true that, with such few users, I could just create the homedirs manually when needed (this is not an organisation where many users come and go) and just mount the individually. Any tips about this? Best, Roberto -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Thu Mar 19 10:30:56 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 19 Mar 2015 11:30:56 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9A6BF.5000306@redhat.com> <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> Message-ID: Isn't this documented well (yet) ? The RH docs are always very detailed about it, but I'm not sure here... I see solutions but not 100% from A to Z to make sure we do it the proper way. 2015-03-12 16:59 GMT+01:00 Matt . : > Not worried, I need to try. > > I think it's not an issue as we use persistance for the connection. We > only do some user adding/chaging stuff, nothing really fancy but it > needs to be decent. As persistence comes in I think we don't have to > worry about it, we discussed that here earlier as I remember. > > Or do I ? > > Something else; did you had a nice PTO ? > > 2015-03-12 15:54 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> Hi, >>> >>> Security wise I can understand that. >>> >>> Yes I have read about that... but that would let me use the >>> loadbalancer to connect ? I was not sure if the SAN would "connect" as >>> "other" host. >> >> Kerberos through a load balancer can be a problem. Is this what you're >> worried about? >> >> rob >> >>> >>> 2015-03-12 15:07 GMT+01:00 Rob Crittenden : >>>> Matt . wrote: >>>>> Hi Guys, >>>>> >>>>> Is Rob able to look at this ? I hope he has some sparetime as I'm >>>>> kinda stuck with this issue. >>>> >>>> Wildcard certs are not supported. >>>> >>>> You can request a SAN with certmonger using -D . That will work >>>> with IPA 4.x for sure, maybe 3.3.5. >>>> >>>> rob >>>> >>>>> >>>>> Thanks! >>>>> >>>>> >>>>> >>>>> 2015-03-08 12:30 GMT+01:00 Matt . : >>>>>> I'm reviewing some things. >>>>>> >>>>>> When I'm using a loadbalancer, which I prefer in this setup I need to >>>>>> have the same certificates on both servers. Maybe a wildcard for my >>>>>> domain could do instead of having only both fqdn's of the servers >>>>>> including the loadbalancer's fqdn. >>>>>> >>>>>> But the question remains, how? >>>>>> >>>>>> >>>>>> >>>>>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>>>>> Hi, >>>>>>> >>>>>>> I will balance with IP persistance so I think there won't be any >>>>>>> mixing as long as that "used" server is online. >>>>>>> >>>>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>>>>> >>>>>>>>> OK, understood. >>>>>>>>> >>>>>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>>>>> record and the first is not reacable, would it try to do it again or >>>>>>>>> will handle DNS this in front of it ? >>>>>>>>> >>>>>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>>>>> checked if the user was able to auth himself using his ldap >>>>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>>>>> to the IPA server. >>>>>>>>> >>>>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>>>>> from PHP for an example. Building in extra checks in front could be >>>>>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>>>>> better. >>>>>>>> >>>>>>>> >>>>>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>>>>> Rob. What is our failover logic for API? >>>>>>>> >>>>>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>>>>> whole conversation goes to the same server you should be fine. I do not >>>>>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>>>>> cert there then if you can enforce the use of the same server in this case. >>>>>>>> >>>>>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>>>>> >>>>>>>> Rob does that make sense for you? >>>>>>>> >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>>>>> >>>>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>>>>> SRV won't fit here sorry to say. >>>>>>>>>>> >>>>>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>>>>> believe ? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>>>>> it >>>>>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>>>>> you >>>>>>>>>> do not have any load balancers and this is the common case. You are >>>>>>>>>> trying >>>>>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>>>>> 100% there in step 6 >>>>>>>>>>> >>>>>>>>>>> Thanks again! >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Matthijs >>>>>>>>>>> >>>>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>>>>> >>>>>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>>>>> curl/json. >>>>>>>>>>>> >>>>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>>>>> It >>>>>>>>>>>> will >>>>>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>>>>> easiest >>>>>>>>>>>> way. >>>>>>>>>>>> >>>>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>>>>> >>>>>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>>>>> way >>>>>>>>>>>> is to >>>>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>>>>> works >>>>>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>>>>> and >>>>>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>>>>> >>>>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>>>>> >>>>>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>>>>> >>>>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>>>>> IPA >>>>>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>>>>> own >>>>>>>>>>>> keytab with different key. >>>>>>>>>>>> >>>>>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>>>>> possibility >>>>>>>>>>>> of >>>>>>>>>>>> sharing keytabs between IPA services. >>>>>>>>>>>> >>>>>>>>>>>>> Does this make it more clear ? >>>>>>>>>>>> >>>>>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>>>>> clients. >>>>>>>>>>>> >>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>> >>>>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>>>>> ipa >>>>>>>>>>>>>>> server ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Any other options ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>>>>> detail, please? >>>>>>>>>>>>>> >>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>>>>> possible to use >>>>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>>>>> to ipa >>>>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>>>>> classical load >>>>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>>>>> you to mess >>>>>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Petr Spacek @ Red Hat >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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. >>>>>>>> >>>>>>>> -- >>>>>>>> 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 kperrin at doctorondemand.com Thu Mar 19 05:10:36 2015 From: kperrin at doctorondemand.com (Kim Perrin) Date: Wed, 18 Mar 2015 22:10:36 -0700 Subject: [Freeipa-users] Replica install fails at client install Message-ID: This is about the 6th time of tried installing this replica. Each time I run the ipa-replica-manage del and ipa-csreplica-manage del command before trying. I also build new replica install files each time. Obviously I can't figure out what the problem is. I've tried a variety of things. I'm hoping someone in this community has been this before and solved the issue. At the end of the install I see the client install failure messages, though it appeared as though the server install went well. However it is clear it has not gone well because when I run 'service ipa status' I get this root at noc5-prd:/var/log# service ipa status Directory Service: RUNNING Unknown error when retrieving list of services from LDAP: {'info': 'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication method'} I've attached the ipareplica-install.log file. Here are some relevant entries from the end of the log - 2015-03-19T04:33:02Z DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain companyz.com --server noc5-prd.companyz.com --realm COMPANYZ.COM 2015-03-19T04:33:02Z DEBUG stdout= 2015-03-19T04:33:02Z DEBUG stderr=Hostname: noc5prd.companyz.com Realm: COMPANYZ.COM DNS Domain: companyz.com IPA Server: noc5-prd.companyz.com BaseDN: dc=companyz,dc=com New SSSD config will be created Configured sudoers in /etc/nsswitch.conf Configured /etc/sssd/sssd.conf trying https://noc5-prd.companyz.com/ipa/xml trying https://noc1-prd.companyz.com/ipa/xml Connection to https://noc1-prd.companyz.com/ipa/xml failed with [Errno -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in use. Cannot connect to the server due to generic error: cannot connect to Gettext('any of the configured servers', domain='ipa', localedir=None): https://noc5-prd.companyz.com/ipa/xml, https://noc1-prd.companyz.com/ipa/xml Installation failed. Rolling back changes. 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 nscd daemon is not installed, skip configuration nslcd daemon is not installed, skip configuration Client uninstall complete. 2015-03-19T04:33:02Z 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 536, in main raise RuntimeError("Failed to configure the client") 2015-03-19T04:33:02Z INFO The ipa-replica-install command failed, exception: RuntimeError: Failed to configure the client Anyone have any advice? -------------- next part -------------- A non-text attachment was scrubbed... Name: copyof_ipareplica-install.log.gz Type: application/x-gzip Size: 3995563 bytes Desc: not available URL: From giedrius.tuminauskas at alva-group.com Thu Mar 19 13:19:07 2015 From: giedrius.tuminauskas at alva-group.com (Giedrius Tuminauskas) Date: Thu, 19 Mar 2015 13:19:07 +0000 Subject: [Freeipa-users] Email address for directory admin Message-ID: Hi, I am curious, Is there a possibility to add email address for the "admin" user in the IPA web UI? In my current configuration "admin" user is a Linux system user and also used by IPA. I think there should be possibility to enter an email address for that user, but UI has no button/link (add) Is it expected behavior? Can you please suggest some tweaks, how to add it? Cheers Giedrius Tuminauskas -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Mar 19 13:36:54 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Mar 2015 09:36:54 -0400 Subject: [Freeipa-users] Email address for directory admin In-Reply-To: References: Message-ID: <550AD0F6.2020808@redhat.com> Giedrius Tuminauskas wrote: > Hi, > > I am curious, Is there a possibility to add email address for the > "admin" user in the IPA web UI? > In my current configuration "admin" user is a Linux system user and also > used by IPA. > I think there should be possibility to enter an email address for that > user, but UI has no button/link (add) > > Is it expected behavior? > Can you please suggest some tweaks, how to add it? Not easily from the UI but possible from the cli. The admin user lacks the inetOrgPerson objectclass which provides the mail attribute. I haven't given this a great deal of thought so can't guarantee that there won't be any subtle issues now or in the future, but given that this objectclass only has MAY attributes is should be ok. $ kinit admin $ ipa user-mod --email admin at example.com --addattr objectclass=inetorgperson admin rob From mkosek at redhat.com Thu Mar 19 13:41:14 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 19 Mar 2015 14:41:14 +0100 Subject: [Freeipa-users] Email address for directory admin In-Reply-To: <550AD0F6.2020808@redhat.com> References: <550AD0F6.2020808@redhat.com> Message-ID: <550AD1FA.1010509@redhat.com> On 03/19/2015 02:36 PM, Rob Crittenden wrote: > Giedrius Tuminauskas wrote: >> Hi, >> >> I am curious, Is there a possibility to add email address for the >> "admin" user in the IPA web UI? >> In my current configuration "admin" user is a Linux system user and also >> used by IPA. >> I think there should be possibility to enter an email address for that >> user, but UI has no button/link (add) >> >> Is it expected behavior? >> Can you please suggest some tweaks, how to add it? > > Not easily from the UI but possible from the cli. The admin user lacks > the inetOrgPerson objectclass which provides the mail attribute. > > I haven't given this a great deal of thought so can't guarantee that > there won't be any subtle issues now or in the future, but given that > this objectclass only has MAY attributes is should be ok. > > $ kinit admin > $ ipa user-mod --email admin at example.com --addattr > objectclass=inetorgperson admin > > rob Related closed tickets with reasoning why this is not done by default: https://fedorahosted.org/freeipa/ticket/4941 https://fedorahosted.org/freeipa/ticket/1162 Martin From nicolas.zin at savoirfairelinux.com Thu Mar 19 13:44:54 2015 From: nicolas.zin at savoirfairelinux.com (Nicolas Zin) Date: Thu, 19 Mar 2015 09:44:54 -0400 (EDT) Subject: [Freeipa-users] revocation of a ssl certificate In-Reply-To: <1983150872.896679.1426772318023.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <1848021824.897244.1426772694488.JavaMail.zimbra@savoirfairelinux.com> Hi, let say that I created a SSL certificate: ipa service-add HTTP/www.test.lan ipa service-add-host --hosts=ipa-server.test.lan HTTP/www.test.lan ipa-getcert request -r -f /etc/pki/tls/certs/www.test.lan.crt -k /etc/pki/tls/private/www.test.lan.key -N CN=www.test.lan -D www.test.lan -K HTTP/www.test.lan and I installed it. If the machine is compromised I would like to revoke it. What shall I do? I saw you can stop renewing it via ipa-getcert stop-tracking -i 20150319132153 and seems to be that I can revoke it via ipa cert-find ipa cert-revoke --revocation-reason=1 0xC is it sufficient? I didn't see the /var/lib/ipa/pki-ca/publish/MasterCRL.bin changed. I though I should find the revocated certificate inside this binary file? Also, how can I print the content of MasterCRL.bin in a "readable" output? Regards, Nicolas Zin PS: I have to confess that I don't master CRL and OCSP. From janellenicole80 at gmail.com Thu Mar 19 13:52:38 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 19 Mar 2015 06:52:38 -0700 Subject: [Freeipa-users] Replica install fails at client install In-Reply-To: References: Message-ID: <550AD4A6.7080009@gmail.com> On 3/18/15 10:10 PM, Kim Perrin wrote: > This is about the 6th time of tried installing this replica. Each time > I run the ipa-replica-manage del and ipa-csreplica-manage del command > before trying. I also build new replica install files each time. > Obviously I can't figure out what the problem is. I've tried a variety > of things. I'm hoping someone in this community has been this before > and solved the issue. > At the end of the install I see the client install failure messages, > though it appeared as though the server install went well. However it > is clear it has not gone well because when I run 'service ipa status' > I get this > > root at noc5-prd:/var/log# service ipa status > Directory Service: RUNNING > Unknown error when retrieving list of services from LDAP: {'info': > 'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication > method'} > > > I've attached the ipareplica-install.log file. Here are some relevant > entries from the end of the log - > > 2015-03-19T04:33:02Z DEBUG args=/usr/sbin/ipa-client-install > --on-master --unattended --domain companyz.com --server > noc5-prd.companyz.com --realm COMPANYZ.COM > 2015-03-19T04:33:02Z DEBUG stdout= > 2015-03-19T04:33:02Z DEBUG stderr=Hostname: noc5prd.companyz.com > Realm: COMPANYZ.COM > DNS Domain: companyz.com > IPA Server: noc5-prd.companyz.com > BaseDN: dc=companyz,dc=com > New SSSD config will be created > Configured sudoers in /etc/nsswitch.conf > Configured /etc/sssd/sssd.conf > trying https://noc5-prd.companyz.com/ipa/xml > trying https://noc1-prd.companyz.com/ipa/xml > Connection to https://noc1-prd.companyz.com/ipa/xml failed with [Errno > -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in > use. > Cannot connect to the server due to generic error: cannot connect to > Gettext('any of the configured servers', domain='ipa', > localedir=None): https://noc5-prd.companyz.com/ipa/xml, > https://noc1-prd.companyz.com/ipa/xml > Installation failed. Rolling back changes. > 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 > nscd daemon is not installed, skip configuration > nslcd daemon is not installed, skip configuration > Client uninstall complete. > 2015-03-19T04:33:02Z 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 536, in main > raise RuntimeError("Failed to configure the client") > 2015-03-19T04:33:02Z INFO The ipa-replica-install command failed, > exception: RuntimeError: Failed to configure the client > > Anyone have any advice? > > There are 2 possibilities here. One is you have the old python package scripts which have a bug in these files: /usr/lib/python2.7/site-packages/ipaplatform/fedora/services.py /usr/lib/python2.7/site-packages/ipaplatform/services.py They most likely have "fedora-domain" in them and it needs to be changed to "rhel-domain". The other option is to re-install the OS and freeipa environment, which gets you to clean packages. Deleting and re-installing all the python packages is painful at best. The other possibility is stale certs: certutil -d /etc/pki/nssdb -L You will probably see a stale cert. Remove it. certutil -d /etc/pki/nssdb -D -n "IPA CA" I have run into both of these issues about 1 million times so far. ~J -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Mar 19 14:04:22 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Mar 2015 10:04:22 -0400 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> Message-ID: <550AD766.5020504@redhat.com> Matt . wrote: > Isn't this documented well (yet) ? Is what documented yet? rob > > The RH docs are always very detailed about it, but I'm not sure > here... I see solutions but not 100% from A to Z to make sure we do it > the proper way. > > 2015-03-12 16:59 GMT+01:00 Matt . : >> Not worried, I need to try. >> >> I think it's not an issue as we use persistance for the connection. We >> only do some user adding/chaging stuff, nothing really fancy but it >> needs to be decent. As persistence comes in I think we don't have to >> worry about it, we discussed that here earlier as I remember. >> >> Or do I ? >> >> Something else; did you had a nice PTO ? >> >> 2015-03-12 15:54 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> Hi, >>>> >>>> Security wise I can understand that. >>>> >>>> Yes I have read about that... but that would let me use the >>>> loadbalancer to connect ? I was not sure if the SAN would "connect" as >>>> "other" host. >>> >>> Kerberos through a load balancer can be a problem. Is this what you're >>> worried about? >>> >>> rob >>> >>>> >>>> 2015-03-12 15:07 GMT+01:00 Rob Crittenden : >>>>> Matt . wrote: >>>>>> Hi Guys, >>>>>> >>>>>> Is Rob able to look at this ? I hope he has some sparetime as I'm >>>>>> kinda stuck with this issue. >>>>> >>>>> Wildcard certs are not supported. >>>>> >>>>> You can request a SAN with certmonger using -D . That will work >>>>> with IPA 4.x for sure, maybe 3.3.5. >>>>> >>>>> rob >>>>> >>>>>> >>>>>> Thanks! >>>>>> >>>>>> >>>>>> >>>>>> 2015-03-08 12:30 GMT+01:00 Matt . : >>>>>>> I'm reviewing some things. >>>>>>> >>>>>>> When I'm using a loadbalancer, which I prefer in this setup I need to >>>>>>> have the same certificates on both servers. Maybe a wildcard for my >>>>>>> domain could do instead of having only both fqdn's of the servers >>>>>>> including the loadbalancer's fqdn. >>>>>>> >>>>>>> But the question remains, how? >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>>>>>> Hi, >>>>>>>> >>>>>>>> I will balance with IP persistance so I think there won't be any >>>>>>>> mixing as long as that "used" server is online. >>>>>>>> >>>>>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>>>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>>>>>> >>>>>>>>>> OK, understood. >>>>>>>>>> >>>>>>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>>>>>> record and the first is not reacable, would it try to do it again or >>>>>>>>>> will handle DNS this in front of it ? >>>>>>>>>> >>>>>>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>>>>>> checked if the user was able to auth himself using his ldap >>>>>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>>>>>> to the IPA server. >>>>>>>>>> >>>>>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>>>>>> from PHP for an example. Building in extra checks in front could be >>>>>>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>>>>>> better. >>>>>>>>> >>>>>>>>> >>>>>>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>>>>>> Rob. What is our failover logic for API? >>>>>>>>> >>>>>>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>>>>>> whole conversation goes to the same server you should be fine. I do not >>>>>>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>>>>>> cert there then if you can enforce the use of the same server in this case. >>>>>>>>> >>>>>>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>>>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>>>>>> >>>>>>>>> Rob does that make sense for you? >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> Cheers, >>>>>>>>>> >>>>>>>>>> Matt >>>>>>>>>> >>>>>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>>>>>> >>>>>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>>>>>> SRV won't fit here sorry to say. >>>>>>>>>>>> >>>>>>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>>>>>> believe ? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>>>>>> it >>>>>>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>>>>>> you >>>>>>>>>>> do not have any load balancers and this is the common case. You are >>>>>>>>>>> trying >>>>>>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>>>>>> 100% there in step 6 >>>>>>>>>>>> >>>>>>>>>>>> Thanks again! >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> Matthijs >>>>>>>>>>>> >>>>>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>>>>>> >>>>>>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>>>>>> curl/json. >>>>>>>>>>>>> >>>>>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>>>>>> It >>>>>>>>>>>>> will >>>>>>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>>>>>> easiest >>>>>>>>>>>>> way. >>>>>>>>>>>>> >>>>>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>>>>>> >>>>>>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>>>>>> way >>>>>>>>>>>>> is to >>>>>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>>>>>> works >>>>>>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>>>>>> and >>>>>>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>>>>>> >>>>>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>>>>>> >>>>>>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>>>>>> IPA >>>>>>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>>>>>> own >>>>>>>>>>>>> keytab with different key. >>>>>>>>>>>>> >>>>>>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>>>>>> possibility >>>>>>>>>>>>> of >>>>>>>>>>>>> sharing keytabs between IPA services. >>>>>>>>>>>>> >>>>>>>>>>>>>> Does this make it more clear ? >>>>>>>>>>>>> >>>>>>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>>>>>> clients. >>>>>>>>>>>>> >>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>>>>>> ipa >>>>>>>>>>>>>>>> server ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Any other options ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>>>>>> detail, please? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>>>>>> possible to use >>>>>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>>>>>> to ipa >>>>>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>>>>>> classical load >>>>>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>>>>>> you to mess >>>>>>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> Petr Spacek @ Red Hat >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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. >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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 Thu Mar 19 14:11:15 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Mar 2015 10:11:15 -0400 Subject: [Freeipa-users] revocation of a ssl certificate In-Reply-To: <1848021824.897244.1426772694488.JavaMail.zimbra@savoirfairelinux.com> References: <1848021824.897244.1426772694488.JavaMail.zimbra@savoirfairelinux.com> Message-ID: <550AD903.3070304@redhat.com> Nicolas Zin wrote: > Hi, > > let say that I created a SSL certificate: > ipa service-add HTTP/www.test.lan > ipa service-add-host --hosts=ipa-server.test.lan HTTP/www.test.lan > ipa-getcert request -r -f /etc/pki/tls/certs/www.test.lan.crt -k /etc/pki/tls/private/www.test.lan.key -N CN=www.test.lan -D www.test.lan -K HTTP/www.test.lan > > and I installed it. > > If the machine is compromised I would like to revoke it. What shall I do? > > I saw you can stop renewing it via > ipa-getcert stop-tracking -i 20150319132153 That just stops tracking the certificate on the machine. It doesn't touch the certificate or key or whatever server is using it at all. In other words, you'd want to stop using this certificate as well. > and seems to be that I can revoke it via > > ipa cert-find > ipa cert-revoke --revocation-reason=1 0xC You shouldn't need the cert-find as you can get the serial number from the certificate on the server and revoke it directly. > is it sufficient? Only if revocation is actually verified by clients using either CRL or OCSP. > I didn't see the /var/lib/ipa/pki-ca/publish/MasterCRL.bin changed. I though I should find the revocated certificate inside this binary file? > Also, how can I print the content of MasterCRL.bin in a "readable" output? > The CRL is generated every 4 hours by default. # openssl crl -inform der -in /var/lib/ipa/pki-ca/publish/MasterCRL.bin -text rob From rcritten at redhat.com Thu Mar 19 14:26:07 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Mar 2015 10:26:07 -0400 Subject: [Freeipa-users] Replica install fails at client install In-Reply-To: <550AD4A6.7080009@gmail.com> References: <550AD4A6.7080009@gmail.com> Message-ID: <550ADC7F.1080601@redhat.com> Janelle wrote: > On 3/18/15 10:10 PM, Kim Perrin wrote: >> This is about the 6th time of tried installing this replica. Each time >> I run the ipa-replica-manage del and ipa-csreplica-manage del command >> before trying. I also build new replica install files each time. >> Obviously I can't figure out what the problem is. I've tried a variety >> of things. I'm hoping someone in this community has been this before >> and solved the issue. >> At the end of the install I see the client install failure messages, >> though it appeared as though the server install went well. However it >> is clear it has not gone well because when I run 'service ipa status' >> I get this >> >> root at noc5-prd:/var/log# service ipa status >> Directory Service: RUNNING >> Unknown error when retrieving list of services from LDAP: {'info': >> 'SASL(-4): no mechanism available: ', 'desc': 'Unknown authentication >> method'} >> >> >> I've attached the ipareplica-install.log file. Here are some relevant >> entries from the end of the log - >> >> 2015-03-19T04:33:02Z DEBUG args=/usr/sbin/ipa-client-install >> --on-master --unattended --domain companyz.com --server >> noc5-prd.companyz.com --realm COMPANYZ.COM >> 2015-03-19T04:33:02Z DEBUG stdout= >> 2015-03-19T04:33:02Z DEBUG stderr=Hostname: noc5prd.companyz.com >> Realm: COMPANYZ.COM >> DNS Domain: companyz.com >> IPA Server: noc5-prd.companyz.com >> BaseDN: dc=companyz,dc=com >> New SSSD config will be created >> Configured sudoers in /etc/nsswitch.conf >> Configured /etc/sssd/sssd.conf >> trying https://noc5-prd.companyz.com/ipa/xml >> trying https://noc1-prd.companyz.com/ipa/xml >> Connection to https://noc1-prd.companyz.com/ipa/xml failed with [Errno >> -8053] (SEC_ERROR_BUSY) NSS could not shutdown. Objects are still in >> use. >> Cannot connect to the server due to generic error: cannot connect to >> Gettext('any of the configured servers', domain='ipa', >> localedir=None): https://noc5-prd.companyz.com/ipa/xml, >> https://noc1-prd.companyz.com/ipa/xml >> Installation failed. Rolling back changes. >> 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 >> nscd daemon is not installed, skip configuration >> nslcd daemon is not installed, skip configuration >> Client uninstall complete. >> 2015-03-19T04:33:02Z 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 536, in main >> raise RuntimeError("Failed to configure the client") >> 2015-03-19T04:33:02Z INFO The ipa-replica-install command failed, >> exception: RuntimeError: Failed to configure the client >> >> Anyone have any advice? >> >> I think the issue is related to this: trying https://noc5-prd.companyz.com/ipa/xml trying https://noc1-prd.companyz.com/ipa/xml It would seem that the client NSS database isn't being properly shutdown between connection attempts. Is noc5 operational? If not then removing it from the SRV records would probably be the fastest way to work around this. What version of IPA is this? > There are 2 possibilities here. One is you have the old python package > scripts which have a bug in these files: > > /usr/lib/python2.7/site-packages/ipaplatform/fedora/services.py > /usr/lib/python2.7/site-packages/ipaplatform/services.py > > They most likely have "fedora-domain" in them and it needs to be changed > to "rhel-domain". The other option is to re-install the OS and freeipa > environment, which gets you to clean packages. Deleting and > re-installing all the python packages is painful at best. I think that was only a problem when trying to install 4.x in RHEL using the upstream COPR repositories. > > The other possibility is stale certs: > > certutil -d /etc/pki/nssdb -L > > You will probably see a stale cert. Remove it. > > certutil -d /etc/pki/nssdb -D -n "IPA CA" > > I have run into both of these issues about 1 million times so far. On a replica install it is always adding the same cert which shouldn't be a problem: # certutil -L -d /etc/pki/nssdb/ Certificate Nickname Trust Attributes SSL,S/MIME,JAR/XPI IPA CA CT,C,C # certutil -A -n 'IPA CA' -t CT,C,C -a -i /etc/ipa/ca.crt -d /etc/pki/nssdb/ # echo $? 0 rob From janellenicole80 at gmail.com Thu Mar 19 14:32:44 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 19 Mar 2015 07:32:44 -0700 Subject: [Freeipa-users] stupid question - 389-ds Message-ID: <550ADE0C.7060108@gmail.com> Hello again, Ok, probably a stupid question. If you increase cache sizes and tune 389-ds on the backend, do those changes replicate or do you need to make them across the other servers as well? For example: dn: cn=config,cn=ldbm database,cn=plugins,cn=config changetype: modify replace: nsslapd-dbcachesize nsslapd-dbcachesize: 2147483648 ~J From rcritten at redhat.com Thu Mar 19 14:38:32 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Mar 2015 10:38:32 -0400 Subject: [Freeipa-users] stupid question - 389-ds In-Reply-To: <550ADE0C.7060108@gmail.com> References: <550ADE0C.7060108@gmail.com> Message-ID: <550ADF68.8060704@redhat.com> Janelle wrote: > Hello again, > > Ok, probably a stupid question. If you increase cache sizes and tune > 389-ds on the backend, do those changes replicate or do you need to make > them across the other servers as well? > > For example: > > dn: cn=config,cn=ldbm database,cn=plugins,cn=config > changetype: modify > replace: nsslapd-dbcachesize > nsslapd-dbcachesize: 2147483648 Changes to cn=config do not replicate so you'd need to make the same change on other current masters (and future ones too). rob From andrew.holway at gmail.com Thu Mar 19 14:51:48 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 19 Mar 2015 15:51:48 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <20150319092924.GD3591@hendrix.arn.redhat.com> References: <5509B1D0.1050602@redhat.com> <20150319092924.GD3591@hendrix.arn.redhat.com> Message-ID: I am having problems with sudo and using _srv_ in the sssd config. This works: # For the SUDO integration sudo_provider = ldap ldap_uri = ldap://test-freeipa-1.cloud.domain.de ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=native-instruments,dc=de ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de ldap_sasl_realm = CLOUD.DOMAIN.DE krb5_server = test-freeipa-2.cloud.domain.de This does not work: # For the SUDO integration sudo_provider = ldap ldap_uri = _srv_ ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de ldap_sasl_mech = GSSAPI ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de ldap_sasl_realm = CLOUD.DOMAIN.DE krb5_server = _srv_ Thanks, Andrew On 19 March 2015 at 10:29, Jakub Hrozek wrote: > On Thu, Mar 19, 2015 at 08:42:42AM +0100, Andrew Holway wrote: > > Cool stuff. Thanks. > > > > I had a look at our SRV records and found the following: > > _kerberos-master._tcp > > _kerberos-master._udp > > _kerberos._tcp > > _kerberos._udp > > _kpasswd._tcp > > _kpasswd._udp > > _ldap._tcp > > _ntp._udp > > > > No mention of and ipa srv records. Does sssd use _ldap._tcp? > > Yes, for the IPA back end it does. > > For the AD back end we use the special MS records for looking up sites > or Global Catalog servers, but for IPA we stick to the standard > services. > > -- > 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 Joshua.Gould at osumc.edu Thu Mar 19 15:05:45 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Thu, 19 Mar 2015 11:05:45 -0400 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX Message-ID: I?m seeing ssh logins for AD users take MUCH longer when using SID mapping vs. POSIX attributes. Both myself and our AD admin would prefer to use SID mapping. It appears tied to the group lookup at login. There seem to be many posts about it, but I haven?t found anything to help much. sssd pegs the CPU for the 15 or so seconds the login takes. Ex w/ SID mapping AD trust: Mar 19 10:48:25 mid-ipa-vp01 sshd[16198]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.134.49.32 user=gould at test.osuwmc Mar 19 10:48:28 mid-ipa-vp01 sshd[16198]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.134.49.32 user=gould at test.osuwmc Mar 19 10:48:34 mid-ipa-vp01 sshd[16198]: Accepted password for goul09 at test.osuwmc from 10.134.49.32 port 56844 ssh2 Mar 19 10:48:38 mid-ipa-vp01 sshd[16198]: pam_unix(sshd:session): session opened for user goul09 at test.osuwmc by (uid=0) Ex w/ POSIX AD trust Mar 16 14:27:52 mid-ipa-vp01 sshd[13723]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.134.49.96 user=gould at test.osuwmc Mar 16 14:27:55 mid-ipa-vp01 sshd[13723]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.134.49.96 user=gould at test.osuwmc Mar 16 14:28:01 mid-ipa-vp01 sshd[13723]: Accepted password for gould at test.osuwmc from 10.134.49.96 port 61401 ssh2 Mar 16 14:28:05 mid-ipa-vp01 sshd[13723]: pam_unix(sshd:session): session opened for user goul09 at test.osuwmc by (uid=0) Exact same sssd.conf file for both configs. [domain/unix.test.osuwmc] debug_level = 9 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = unix.test.osuwmc id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = mid-ipa-vp01.unix.test.osuwmc chpass_provider = ipa ipa_server = mid-ipa-vp01.unix.test.osuwmc ipa_server_mode = True ldap_tls_cacert = /etc/ipa/ca.crt ldap_referrals = false #[domain/test.osuwmc] [sssd] services = nss, sudo, pam, ssh, pac config_file_version = 2 domains = unix.test.osuwmc [nss] homedir_substring = /home [pam] [sudo] [autofs] [ssh] [pac] [ifp] From jhrozek at redhat.com Thu Mar 19 15:23:48 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 16:23:48 +0100 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX In-Reply-To: References: Message-ID: <20150319152348.GL3591@hendrix.arn.redhat.com> On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote: > I?m seeing ssh logins for AD users take MUCH longer when using SID mapping > vs. POSIX attributes. Both myself and our AD admin would prefer to use SID > mapping. It appears tied to the group lookup at login. There seem to be > many posts about it, but I haven?t found anything to help much. sssd pegs > the CPU for the 15 or so seconds the login takes. You haven't said what OS or release are you running, but for 7.0 I have test packages with a proposed enhancement Sumit wrote: https://jhrozek.fedorapeople.org/sssd-test-builds/sssd-7.0-login-speedup/ Please include the versions of the problematic packages in the future requests for troubleshooting. From Joshua.Gould at osumc.edu Thu Mar 19 15:31:16 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Thu, 19 Mar 2015 11:31:16 -0400 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX In-Reply-To: <20150319152348.GL3591@hendrix.arn.redhat.com> References: <20150319152348.GL3591@hendrix.arn.redhat.com> Message-ID: RHEL 7.0 fully up to date. sssd-krb5-common-1.12.2-58.el7.x86_64 sssd-ipa-1.12.2-58.el7.x86_64 sssd-1.12.2-58.el7.x86_64 sssd-tools-1.12.2-58.el7.x86_64 sssd-common-1.12.2-58.el7.x86_64 sssd-ad-1.12.2-58.el7.x86_64 sssd-krb5-1.12.2-58.el7.x86_64 sssd-ldap-1.12.2-58.el7.x86_64 sssd-client-1.12.2-58.el7.x86_64 sssd-common-pac-1.12.2-58.el7.x86_64 sssd-proxy-1.12.2-58.el7.x86_64 On 3/19/15, 11:23 AM, "Jakub Hrozek" wrote: >On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote: >> I?m seeing ssh logins for AD users take MUCH longer when using SID >>mapping >> vs. POSIX attributes. Both myself and our AD admin would prefer to use >>SID >> mapping. It appears tied to the group lookup at login. There seem to be >> many posts about it, but I haven?t found anything to help much. sssd >>pegs >> the CPU for the 15 or so seconds the login takes. > >You haven't said what OS or release are you running, but for 7.0 I have >test packages with a proposed enhancement Sumit wrote: > >https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople. >org_sssd-2Dtest-2Dbuilds_sssd-2D7.0-2Dlogin-2Dspeedup_&d=AwIFAw&c=k9MF1d71 >ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv >JwojC24&m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gs&s=bYcFLFGsd6BT_1ozcn >1r1WaYFWJ4_5xT5ddR7d45Z08&e= > >Please include the versions of the problematic packages in the future >requests for troubleshooting. > >-- >Manage your subscription for the Freeipa-users mailing list: >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma >n_listinfo_freeipa-2Dusers&d=AwIFAw&c=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S >FEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24&m=YA1l-b8irE5VE9qVc1 >q4PY8RVJA2iLwWLK_U7aXS1gs&s=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2k&e= > >Go to >https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.org&d=AwIFAw&c >=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk >8zPbIs_SvJwojC24&m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gs&s=F_LQz74bb >hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznw&e= for more info on the project From jhrozek at redhat.com Thu Mar 19 15:37:34 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 16:37:34 +0100 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX In-Reply-To: References: <20150319152348.GL3591@hendrix.arn.redhat.com> Message-ID: <20150319153734.GN3591@hendrix.arn.redhat.com> On Thu, Mar 19, 2015 at 11:31:16AM -0400, Gould, Joshua wrote: > RHEL 7.0 fully up to date. Are you sure? Looks like 7.1 to me based on the NVRs. > > sssd-krb5-common-1.12.2-58.el7.x86_64 > sssd-ipa-1.12.2-58.el7.x86_64 > sssd-1.12.2-58.el7.x86_64 > sssd-tools-1.12.2-58.el7.x86_64 > sssd-common-1.12.2-58.el7.x86_64 > sssd-ad-1.12.2-58.el7.x86_64 > sssd-krb5-1.12.2-58.el7.x86_64 > sssd-ldap-1.12.2-58.el7.x86_64 > sssd-client-1.12.2-58.el7.x86_64 > sssd-common-pac-1.12.2-58.el7.x86_64 > sssd-proxy-1.12.2-58.el7.x86_64 > > > > On 3/19/15, 11:23 AM, "Jakub Hrozek" wrote: > > >On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote: > >> I?m seeing ssh logins for AD users take MUCH longer when using SID > >>mapping > >> vs. POSIX attributes. Both myself and our AD admin would prefer to use > >>SID > >> mapping. It appears tied to the group lookup at login. There seem to be > >> many posts about it, but I haven?t found anything to help much. sssd > >>pegs > >> the CPU for the 15 or so seconds the login takes. > > > >You haven't said what OS or release are you running, but for 7.0 I have > >test packages with a proposed enhancement Sumit wrote: > > > >https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople. > >org_sssd-2Dtest-2Dbuilds_sssd-2D7.0-2Dlogin-2Dspeedup_&d=AwIFAw&c=k9MF1d71 > >ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv > >JwojC24&m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gs&s=bYcFLFGsd6BT_1ozcn > >1r1WaYFWJ4_5xT5ddR7d45Z08&e= > > > >Please include the versions of the problematic packages in the future > >requests for troubleshooting. > > > >-- > >Manage your subscription for the Freeipa-users mailing list: > >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma > >n_listinfo_freeipa-2Dusers&d=AwIFAw&c=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S > >FEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24&m=YA1l-b8irE5VE9qVc1 > >q4PY8RVJA2iLwWLK_U7aXS1gs&s=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2k&e= > > > >Go to > >https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.org&d=AwIFAw&c > >=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk > >8zPbIs_SvJwojC24&m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gs&s=F_LQz74bb > >hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznw&e= for more info on the project > From bobby.prins at proxy.nl Thu Mar 19 15:46:44 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Thu, 19 Mar 2015 16:46:44 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> Message-ID: <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> Hi there, I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup (described here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust was created all seems to work well on the freeIPA server. I can also do a lookup of AD users and groups on an AIX test server. But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success [12299] 1426773524.361880: Produced preauth for next request: 2 [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 [12299] 1426773524.368482: Response was not from master KDC [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 [12299] 1426773524.384237: Response was not from master KDC [12299] 1426773524.384263: Processing preauth types: 19 [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" [12299] 1426773524.384275: Produced preauth for next request: (empty) [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB [12299] 1426773524.384333: FAST negotiation: unavailable [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v Any ideas? Thanks, Bobby From nalin at redhat.com Thu Mar 19 15:57:04 2015 From: nalin at redhat.com (Nalin Dahyabhai) Date: Thu, 19 Mar 2015 11:57:04 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: <5509F468.2040400@redhat.com> References: <5509CE2D.8080108@redhat.com> <5509F468.2040400@redhat.com> Message-ID: <20150319155704.GA1389@redhat.com> On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote: > > getcert status > > process 31282: arguments to dbus_message_new_method_call() were > > incorrect, assertion "path != NULL" failed in file dbus-message.c line 1262. > > This is normally a bug in some application using the D-Bus library. > > D-Bus not built with -rdynamic so unable to print a backtrace > > Aborted (core dumped) > > Please open a bug against certmonger. I'm pretty sure this one's already being tracked as #1148001. Cheers, Nalin From jhrozek at redhat.com Thu Mar 19 16:00:10 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 17:00:10 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> Message-ID: <20150319160010.GO3591@hendrix.arn.redhat.com> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: > Hi there, > > I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup (described here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust was created all seems to work well on the freeIPA server. I can also do a lookup of AD users and groups on an AIX test server. > > But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 > > If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': Can you test if kinit -C -E makes any difference? > [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 > [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 > [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success > [12299] 1426773524.361880: Produced preauth for next request: 2 > [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP > [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. > [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 > [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 > [12299] 1426773524.368482: Response was not from master KDC > [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP > [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP > [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) > [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. > [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 > [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 > [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 I see the KDCs were different, can you also test against the KDC that SSSD autodiscovered? > [12299] 1426773524.384237: Response was not from master KDC > [12299] 1426773524.384263: Processing preauth types: 19 > [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" > [12299] 1426773524.384275: Produced preauth for next request: (empty) > [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 > [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB > [12299] 1426773524.384333: FAST negotiation: unavailable > [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP > [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v > [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v > [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 > [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v > [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v > > Any ideas? > > Thanks, > > Bobby > > -- > 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 giedrius.tuminauskas at alva-group.com Thu Mar 19 16:16:29 2015 From: giedrius.tuminauskas at alva-group.com (Giedrius Tuminauskas) Date: Thu, 19 Mar 2015 16:16:29 +0000 Subject: [Freeipa-users] Email address for directory admin In-Reply-To: <550AD1FA.1010509@redhat.com> References: <550AD1FA.1010509@redhat.com> Message-ID: Thank you Rob, it worked like a charm. Giedrius? At Thursday, 19-03-2015 on 13:41 Martin Kosek wrote: On 03/19/2015 02:36 PM, Rob Crittenden wrote: > Giedrius Tuminauskas wrote: >> Hi, >> >> I am curious, Is there a possibility to add email address for the >> "admin" user in the IPA web UI? >> In my current configuration "admin" user is a Linux system user and also >> used by IPA. >> I think there should be possibility to enter an email address for that >> user, but UI has no button/link (add) >> >> Is it expected behavior? >> Can you please suggest some tweaks, how to add it? > > Not easily from the UI but possible from the cli. The admin user lacks > the inetOrgPerson objectclass which provides the mail attribute. > > I haven't given this a great deal of thought so can't guarantee that > there won't be any subtle issues now or in the future, but given that > this objectclass only has MAY attributes is should be ok. > > $ kinit admin > $ ipa user-mod --email admin at example.com --addattr > objectclass=inetorgperson admin > > rob Related closed tickets with reasoning why this is not done by default: https://fedorahosted.org/freeipa/ticket/4941 https://fedorahosted.org/freeipa/ticket/1162 Martin -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobby.prins at proxy.nl Thu Mar 19 16:20:41 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Thu, 19 Mar 2015 17:20:41 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150319160010.GO3591@hendrix.arn.redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> <20150319160010.GO3591@hendrix.arn.redhat.com> Message-ID: <1624017521.522660.1426782041761.JavaMail.zimbra@proxy.nl> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >> Hi there, >> >> I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup (described here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust was created all seems to work well on the freeIPA server. I can also do a lookup of AD users and groups on an AIX test server. >> >> But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 >> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': > >Can you test if kinit -C -E makes any difference? KRB5_TRACE=/dev/stderr kinit -C -E BPrins at EXAMPLE.CORP output: [12994] 1426781014.22372: Resolving unique ccache of type KEYRING [12994] 1426781014.22420: Getting initial credentials for BPrins\@EXAMPLE.CORP at UNIX.EXAMPLE.CORP [12994] 1426781014.24809: Sending request (182 bytes) to UNIX.EXAMPLE.CORP [12994] 1426781014.25036: Sending initial UDP request to dgram 192.168.140.133:88 [12994] 1426781014.26345: Received answer from dgram 192.168.140.133:88 [12994] 1426781014.26381: Response was from master KDC [12994] 1426781014.26402: Received error from KDC: -1765328378/Client not found in Kerberos database kinit: Client 'BPrins\@EXAMPLE.CORP at UNIX.EXAMPLE.CORP' not found in Kerberos database while getting initial credentials > >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >> [12299] 1426773524.361880: Produced preauth for next request: 2 >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >> [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 >> [12299] 1426773524.368482: Response was not from master KDC >> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP >> [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >> [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 > >I see the KDCs were different, can you also test against the KDC that >SSSD autodiscovered? Just tried it a couple of times again and against the same KDC kinit works, SSSD not. > >> [12299] 1426773524.384237: Response was not from master KDC >> [12299] 1426773524.384263: Processing preauth types: 19 >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >> [12299] 1426773524.384275: Produced preauth for next request: (empty) >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 >> [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB >> [12299] 1426773524.384333: FAST negotiation: unavailable >> [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v >> >> Any ideas? >> >> Thanks, >> >> Bobby >> >> -- >> 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 Joshua.Gould at osumc.edu Thu Mar 19 16:29:35 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Thu, 19 Mar 2015 12:29:35 -0400 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX In-Reply-To: <20150319153734.GN3591@hendrix.arn.redhat.com> References: <20150319153734.GN3591@hendrix.arn.redhat.com> Message-ID: <4B7E9FCA791B8B48B816E89C8C7C7EF40CC48F3D0E@EXMBOX-VP03.OSUMC.EDU> You are correct. 7.1. Sent with Good (www.good.com) -----Original Message----- From: Jakub Hrozek [jhrozek at redhat.com] Sent: Thursday, March 19, 2015 11:37 AM Eastern Standard Time To: Gould, Joshua Cc: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX On Thu, Mar 19, 2015 at 11:31:16AM -0400, Gould, Joshua wrote: > RHEL 7.0 fully up to date. Are you sure? Looks like 7.1 to me based on the NVRs. > > sssd-krb5-common-1.12.2-58.el7.x86_64 > sssd-ipa-1.12.2-58.el7.x86_64 > sssd-1.12.2-58.el7.x86_64 > sssd-tools-1.12.2-58.el7.x86_64 > sssd-common-1.12.2-58.el7.x86_64 > sssd-ad-1.12.2-58.el7.x86_64 > sssd-krb5-1.12.2-58.el7.x86_64 > sssd-ldap-1.12.2-58.el7.x86_64 > sssd-client-1.12.2-58.el7.x86_64 > sssd-common-pac-1.12.2-58.el7.x86_64 > sssd-proxy-1.12.2-58.el7.x86_64 > > > > On 3/19/15, 11:23 AM, "Jakub Hrozek" wrote: > > >On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote: > >> I?m seeing ssh logins for AD users take MUCH longer when using SID > >>mapping > >> vs. POSIX attributes. Both myself and our AD admin would prefer to use > >>SID > >> mapping. It appears tied to the group lookup at login. There seem to be > >> many posts about it, but I haven?t found anything to help much. sssd > >>pegs > >> the CPU for the 15 or so seconds the login takes. > > > >You haven't said what OS or release are you running, but for 7.0 I have > >test packages with a proposed enhancement Sumit wrote: > > > >https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople. > >org_sssd-2Dtest-2Dbuilds_sssd-2D7.0-2Dlogin-2Dspeedup_&d=AwIFAw&c=k9MF1d71 > >ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv > >JwojC24&m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gs&s=bYcFLFGsd6BT_1ozcn > >1r1WaYFWJ4_5xT5ddR7d45Z08&e= > > > >Please include the versions of the problematic packages in the future > >requests for troubleshooting. > > > >-- > >Manage your subscription for the Freeipa-users mailing list: > >https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma > >n_listinfo_freeipa-2Dusers&d=AwIFAw&c=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S > >FEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24&m=YA1l-b8irE5VE9qVc1 > >q4PY8RVJA2iLwWLK_U7aXS1gs&s=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2k&e= > > > >Go to > >https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.org&d=AwIFAw&c > >=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk > >8zPbIs_SvJwojC24&m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gs&s=F_LQz74bb > >hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznw&e= for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 19 16:33:09 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 17:33:09 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: References: <5509B1D0.1050602@redhat.com> <20150319092924.GD3591@hendrix.arn.redhat.com> Message-ID: <20150319163309.GQ3591@hendrix.arn.redhat.com> On Thu, Mar 19, 2015 at 03:51:48PM +0100, Andrew Holway wrote: > I am having problems with sudo and using _srv_ in the sssd config. > > This works: > > # For the SUDO integration > > sudo_provider = ldap > > ldap_uri = ldap://test-freeipa-1.cloud.domain.de > > ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=native-instruments,dc=de > > ldap_sasl_mech = GSSAPI > > ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de > > ldap_sasl_realm = CLOUD.DOMAIN.DE > > krb5_server = test-freeipa-2.cloud.domain.de > > > This does not work: > > # For the SUDO integration > > sudo_provider = ldap > > ldap_uri = _srv_ > > ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de > > ldap_sasl_mech = GSSAPI > > ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de > > ldap_sasl_realm = CLOUD.DOMAIN.DE > > krb5_server = _srv_ What is the client version? From andrew.holway at gmail.com Thu Mar 19 16:38:49 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 19 Mar 2015 17:38:49 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <20150319163309.GQ3591@hendrix.arn.redhat.com> References: <5509B1D0.1050602@redhat.com> <20150319092924.GD3591@hendrix.arn.redhat.com> <20150319163309.GQ3591@hendrix.arn.redhat.com> Message-ID: Hi Jakub, Name : ipa-client Arch : x86_64 Version : 3.3.3 Release : 28.0.1.el7.centos.3 On 19 March 2015 at 17:33, Jakub Hrozek wrote: > On Thu, Mar 19, 2015 at 03:51:48PM +0100, Andrew Holway wrote: > > I am having problems with sudo and using _srv_ in the sssd config. > > > > This works: > > > > # For the SUDO integration > > > > sudo_provider = ldap > > > > ldap_uri = ldap://test-freeipa-1.cloud.domain.de > > > > ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=native-instruments,dc=de > > > > ldap_sasl_mech = GSSAPI > > > > ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de > > > > ldap_sasl_realm = CLOUD.DOMAIN.DE > > > > krb5_server = test-freeipa-2.cloud.domain.de > > > > > > This does not work: > > > > # For the SUDO integration > > > > sudo_provider = ldap > > > > ldap_uri = _srv_ > > > > ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de > > > > ldap_sasl_mech = GSSAPI > > > > ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de > > > > ldap_sasl_realm = CLOUD.DOMAIN.DE > > > > krb5_server = _srv_ > > What is the client version? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 19 16:46:10 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 17:46:10 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: References: <5509B1D0.1050602@redhat.com> <20150319092924.GD3591@hendrix.arn.redhat.com> <20150319163309.GQ3591@hendrix.arn.redhat.com> Message-ID: <20150319164610.GS3591@hendrix.arn.redhat.com> On Thu, Mar 19, 2015 at 05:38:49PM +0100, Andrew Holway wrote: > Hi Jakub, > > Name : ipa-client > Arch : x86_64 > Version : 3.3.3 > Release : 28.0.1.el7.centos.3 I wasn't precise enough, I meant the sssd version, sorry. But given that you're on RHEL-7, I think you can switch to: sudo_provider=ipa and remove all the ldap_ config parameters as well as krb5_server. From sbose at redhat.com Thu Mar 19 17:11:19 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 19 Mar 2015 18:11:19 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> Message-ID: <20150319171119.GI27609@p.redhat.com> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: > Hi there, > > I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup (described here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust was created all seems to work well on the freeIPA server. I can also do a lookup of AD users and groups on an AIX test server. > > But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] > (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 > > If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': > [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 > [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 > [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success > [12299] 1426773524.361880: Produced preauth for next request: 2 > [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP > [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. > [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 > [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 > [12299] 1426773524.368482: Response was not from master KDC > [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP > [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP > [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) > [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. > [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 > [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 > [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 > [12299] 1426773524.384237: Response was not from master KDC > [12299] 1426773524.384263: Processing preauth types: 19 > [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" > [12299] 1426773524.384275: Produced preauth for next request: (empty) > [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 > [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB > [12299] 1426773524.384333: FAST negotiation: unavailable > [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP > [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v > [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v > [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 > [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v > [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v > > Any ideas? Can you log in to the IPA server as this user? If yes I would assume that the password gets garbled somewhere on the way from AIX through the IPA machinery to SSSD. Does the password contain some special characters which some LDAP processing calls might want the escape? bye, Sumit > > Thanks, > > Bobby > > -- > 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 yamakasi.014 at gmail.com Thu Mar 19 17:12:47 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 19 Mar 2015 18:12:47 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <550AD766.5020504@redhat.com> References: <54F9AA8F.6060404@redhat.com> <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> Message-ID: The right way to sequest a SAN, this seems to need some extra config file ? 2015-03-19 15:04 GMT+01:00 Rob Crittenden : > Matt . wrote: >> Isn't this documented well (yet) ? > > Is what documented yet? > > rob > >> >> The RH docs are always very detailed about it, but I'm not sure >> here... I see solutions but not 100% from A to Z to make sure we do it >> the proper way. >> >> 2015-03-12 16:59 GMT+01:00 Matt . : >>> Not worried, I need to try. >>> >>> I think it's not an issue as we use persistance for the connection. We >>> only do some user adding/chaging stuff, nothing really fancy but it >>> needs to be decent. As persistence comes in I think we don't have to >>> worry about it, we discussed that here earlier as I remember. >>> >>> Or do I ? >>> >>> Something else; did you had a nice PTO ? >>> >>> 2015-03-12 15:54 GMT+01:00 Rob Crittenden : >>>> Matt . wrote: >>>>> Hi, >>>>> >>>>> Security wise I can understand that. >>>>> >>>>> Yes I have read about that... but that would let me use the >>>>> loadbalancer to connect ? I was not sure if the SAN would "connect" as >>>>> "other" host. >>>> >>>> Kerberos through a load balancer can be a problem. Is this what you're >>>> worried about? >>>> >>>> rob >>>> >>>>> >>>>> 2015-03-12 15:07 GMT+01:00 Rob Crittenden : >>>>>> Matt . wrote: >>>>>>> Hi Guys, >>>>>>> >>>>>>> Is Rob able to look at this ? I hope he has some sparetime as I'm >>>>>>> kinda stuck with this issue. >>>>>> >>>>>> Wildcard certs are not supported. >>>>>> >>>>>> You can request a SAN with certmonger using -D . That will work >>>>>> with IPA 4.x for sure, maybe 3.3.5. >>>>>> >>>>>> rob >>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> >>>>>>> >>>>>>> >>>>>>> 2015-03-08 12:30 GMT+01:00 Matt . : >>>>>>>> I'm reviewing some things. >>>>>>>> >>>>>>>> When I'm using a loadbalancer, which I prefer in this setup I need to >>>>>>>> have the same certificates on both servers. Maybe a wildcard for my >>>>>>>> domain could do instead of having only both fqdn's of the servers >>>>>>>> including the loadbalancer's fqdn. >>>>>>>> >>>>>>>> But the question remains, how? >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I will balance with IP persistance so I think there won't be any >>>>>>>>> mixing as long as that "used" server is online. >>>>>>>>> >>>>>>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>>>>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>>>>>>> >>>>>>>>>>> OK, understood. >>>>>>>>>>> >>>>>>>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>>>>>>> record and the first is not reacable, would it try to do it again or >>>>>>>>>>> will handle DNS this in front of it ? >>>>>>>>>>> >>>>>>>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>>>>>>> checked if the user was able to auth himself using his ldap >>>>>>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>>>>>>> to the IPA server. >>>>>>>>>>> >>>>>>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>>>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>>>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>>>>>>> from PHP for an example. Building in extra checks in front could be >>>>>>>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>>>>>>> better. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>>>>>>> Rob. What is our failover logic for API? >>>>>>>>>> >>>>>>>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>>>>>>> whole conversation goes to the same server you should be fine. I do not >>>>>>>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>>>>>>> cert there then if you can enforce the use of the same server in this case. >>>>>>>>>> >>>>>>>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>>>>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>>>>>>> >>>>>>>>>> Rob does that make sense for you? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Thanks! >>>>>>>>>>> >>>>>>>>>>> Cheers, >>>>>>>>>>> >>>>>>>>>>> Matt >>>>>>>>>>> >>>>>>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>>>>>>> >>>>>>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>>>>>>> SRV won't fit here sorry to say. >>>>>>>>>>>>> >>>>>>>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>>>>>>> believe ? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>>>>>>> it >>>>>>>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>>>>>>> you >>>>>>>>>>>> do not have any load balancers and this is the common case. You are >>>>>>>>>>>> trying >>>>>>>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>>>>>>> 100% there in step 6 >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> Matthijs >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>>>>>>> curl/json. >>>>>>>>>>>>>> >>>>>>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>>>>>>> It >>>>>>>>>>>>>> will >>>>>>>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>>>>>>> easiest >>>>>>>>>>>>>> way. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>>>>>>> way >>>>>>>>>>>>>> is to >>>>>>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>>>>>>> works >>>>>>>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>>>>>>> and >>>>>>>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>>>>>>> >>>>>>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>>>>>>> IPA >>>>>>>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>>>>>>> own >>>>>>>>>>>>>> keytab with different key. >>>>>>>>>>>>>> >>>>>>>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>>>>>>> possibility >>>>>>>>>>>>>> of >>>>>>>>>>>>>> sharing keytabs between IPA services. >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Does this make it more clear ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>>>>>>> clients. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>>>>>>> ipa >>>>>>>>>>>>>>>>> server ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Any other options ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>>>>>>> detail, please? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>>>>>>> possible to use >>>>>>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>>>>>>> to ipa >>>>>>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>>>>>>> classical load >>>>>>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>>>>>>> you to mess >>>>>>>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Petr Spacek @ Red Hat >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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. >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> 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 Mar 19 18:36:10 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Mar 2015 14:36:10 -0400 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: References: <54F97E3A.6090803@redhat.com> Message-ID: <550B171A.6070600@redhat.com> On 03/19/2015 05:29 AM, Roberto Cornacchia wrote: > On 6 March 2015 at 11:15, Martin Kosek > wrote: > > On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: > > Hi there, > > I'm planning to deploy freeIPA on our lan. > It's small-ish and completely based on FC21, so I expect > everything to work > like a charm. > > Except one detail. We have Synology NAS station, which uses > DSM 5.0. > The ideal plan is to use it as host for shared NFS home dirs > once we switch our > desktops to freeIPA. > > > Great! > > > > Hello, > > The first thing I'm struggling with is to find the correct approach > about NFS home dirs. > The ideal setting would be: > - home dirs on the NAS > - IPA manages automount maps > - home dirs are created automatically at first login > > The documentation I could find on these topics includes only > not-so-recent pages (anything I missed?): > > http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories > http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/ > > Now, I admit I don't have much experience with setting up NFS homes, > with or without freeIPA, so trying to get this done correctly in the > context of freeIPA and without clear howtos isn't very easy, but I'm > willing to get my hands dirty. > > The first problem I struggle with is on the correct approach. > From the documentation above, I understand that there is a bit of a > chicken-egg problem about the creation of home dirs. > On the one hand, it would be optimal to have automount maps to load > only single home dirs on demand, rather than the entire /home tree. > On the other hand, if the /home tree is not available, then creating > /home/user1 dir automatically isn't really possible. > > Just mounting the whole /home tree would make things easier, but I > don't have a feeling of when it starts to become a performance issue > (assuming recent hardware and up to date software). 10 users? 50? 100? > 500? No idea. > The realm I'm dealing with at the moment is in the range of 5-10 users > and probably won't be larger than 50 in the next few years (and if it > will, it means things are going well, so what the heck ;) > Also true that, with such few users, I could just create the homedirs > manually when needed (this is not an organisation where many users > come and go) and just mount the individually. > Any tips about this? > > Best, Roberto > > > Some of these questions are really outside the scope of this list. You might consider asking them on the NFS list. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Mar 19 18:39:45 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Mar 2015 14:39:45 -0400 Subject: [Freeipa-users] Fwd: Re: AD --> FreeIPA Password Sync --- Peer reports incompatible or unsupported protocol In-Reply-To: <550A9276.7060409@unicyber.co.uk> References: <55032968.5010500@redhat.com> <55032FE4.5030208@redhat.com> <55034397.4030008@unicyber.co.uk> <550345FF.9040407@redhat.com> <55035011.9080507@redhat.com> <98c0441da909fe42d1e266c3c46b3949@unicyber.co.uk> <3bccb84836c1afa05d3e78e01c30bbde@unicyber.co.uk> <550737A2.10807@redhat.com> <550A9276.7060409@unicyber.co.uk> Message-ID: <550B17F1.4030405@redhat.com> On 03/19/2015 05:10 AM, Gonzalo Fernandez Ordas wrote: > Hi > > I have completed changed the scenario and I managed to install > freeipa-server 4.1 (Somebody publish the right repo for Centos and it > worked really well) > > --Let me double check a couple of things. You wrote you installed > PassSync on Windows 2013 (which could be a typo?) We support Windows > Server 2008 R2 and 2012 R2. We also confirmed it works on Windows > Server 2003 R2. > > Yes, sorry, that was a typo. > > So, starting again from scratch, new machine, the whole installation > process went well, not issues there but: > > * FreeIPA is supposed to generate a PassSync user by running > ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also > man ipa-replica-manage). > > I tried 5 times, the user was never created on the ipa server, I had > to create it manually (I gave it admin permissions so it could > create/delete/update users). > Doing that, the password sync worked all right. We submit a password > reset in AD and that propagated all right, tested and it worked fine. > / > * In one scenario I uninstalled freeipa (still kept the packages), > installed again and something went wrong with the kerberos keys. > After creating the AD --> LDAP certs and successfully syncing the > passwords, I could read in the /var/log/messages a password decryption > issue (kerberos related) everytime I tried to log as any user. > I have tried uninstalling freeipa and also uninstalling removing the > product completely and re-installing. it did not matter if I tried to > rebuild the kerberos keys, the issue was always there, so I have to > start afresh with a new box. > Something is really messed up with the system. Do you have some kind of backup and restore running in the background? It seems that for some reason a kerberos (probably master) key was rewritten in some way. > So.. that has been all so far > > Thanks > > Gonzalo > > > On 16/03/2015 20:05, Noriko Hosoi wrote: >> Hello, Gonzalo, >> >> Any progress on your Password Synchronization? >> >> Let me double check a couple of things. You wrote you installed >> PassSync on Windows 2013 (which could be a typo?) We support Windows >> Server 2008 R2 and 2012 R2. We also confirmed it works on Windows >> Server 2003 R2. >> > On 03/13/2015 12:45 PM,g.fer.ordas at unicyber.co.uk wrote: >> >> I got the Password Sync Tool installed in the Windows2013 box >> You can find the doc on PassSync here. >> https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Windows_Integration_Guide/pass-sync.html#windows-pass-sync >> The doc is on PassSync 1.1.5, but 1.1.6 remains intact except the >> default SSL version to connect to the 389 Directory Server (as we >> discussed before). >> >> We had a dicussion regarding the PassSync user you had to create: >> uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com >> FreeIPA is supposed to generate a PassSync user by running >> ipa-replica-manage *--winsync **--passsync*=/PASSSYNC_PWD. (See also >> man ipa-replica-manage)./ >> > there must some problem as FreeIPA >> > creates own Passsync user in "cn=sysaccounts,cn=etc," also sets it's DN >> > as passSyncManagersDNs in ipa_pwd_extop plugin to avoid it creating expired >> > passwords. So there is no need to create >> > "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" manually. >> Please see the above doc regarding the user creation. >> >> * >> The username of the system user which Active Directory uses to >> connect to the IdM machine. This account is configured >> automatically when sync is configured on the IdM server. The >> default account is >> |uid=passsync,cn=sysaccounts,cn=etc,dc=example,dc=com|. >> * >> The password set in the |--passsync| option when the sync >> agreement was created. >> >> I'm sending this response to freeipa-users to share the info and >> request for more suggestions. >> >> Thanks, >> --noriko >> >> On 03/13/2015 02:48 PM, g.fer.ordas at unicyber.co.uk wrote: >>> I forgot to attach the search command now: >>> # passsync, users, accounts, corp.company.com >>> dn: uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com >>> cn: passsync >>> displayName: passsync >>> krbLastFailedAuth: 20150313211546Z >>> krbLoginFailedCount: 1 >>> krbExtraData:: AALUUQNVcm9vdC9hZG1pbkBDT1JQLkhPT1RTVUlURU1FRElBLkNPTQA= >>> memberOf: cn=ipausers,cn=groups,cn=accounts,dc=corp,dc=company,dc=com >>> krbLastPwdChange: 20150313210836Z >>> krbPasswordExpiration: 20150611210836Z >>> mepManagedEntry: cn=passsync,cn=groups,cn=accounts,dc=corp,dc=company,d >>> c=com >>> objectClass: top >>> objectClass: person >>> objectClass: organizationalperson >>> objectClass: inetorgperson >>> objectClass: inetuser >>> objectClass: posixaccount >>> objectClass: krbprincipalaux >>> objectClass: krbticketpolicyaux >>> objectClass: ipaobject >>> objectClass: ipasshuser >>> objectClass: ipaSshGroupOfPubKeys >>> objectClass: mepOriginEntry >>> loginShell: /bin/bash >>> gecos: pass sync >>> sn: sync >>> homeDirectory: /home/passsync >>> uid: passsync >>> mail: passsync at corp.company.com >>> krbPrincipalName: passsync at CORP.company.COM >>> givenName: pass >>> initials: ps >>> userPassword:: zxxxxxxxx= >>> = >>> ipaUniqueID: 1d76b14a-c9c5-11e4-93f4-12d2e19d1e3c >>> uidNumber: 1481000829 >>> gidNumber: 1481000829 >>> krbPrincipalKey:: dfrerererer >>> >>> # search result >>> search: 2 >>> >>> >>> On 2015-03-13 21:39, g.fer.ordas at unicyber.co.uk wrote: >>>> Hi >>>> >>>> I had to manually create the user!! For some reason I thought the sync >>>> Agreement task was also creating that entry for the DS! >>>> >>>> So now I got: >>>> >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=4 SRCH >>>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> scope=0 filter="(objectClass=*)" attrs="telephoneNumber uid title >>>> loginShell uidNumber gidNumber sn homeDirectory mail ou givenName >>>> nsAccountLock" >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=4 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=5 SRCH >>>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> scope=0 filter="(userPassword=*)" attrs="userPassword" >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=5 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=6 SRCH >>>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> scope=0 filter="(krbPrincipalKey=*)" attrs="krbPrincipalKey" >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=6 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=7 SRCH >>>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> scope=0 filter="(objectClass=*)" attrs="ipaSshPubKey" >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=7 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=8 UNBIND >>>> [13/Mar/2015:14:27:30 -0700] conn=66 op=8 fd=103 closed - U1 >>>> [13/Mar/2015:14:27:33 -0700] conn=48 op=20 RESULT err=0 tag=101 >>>> nentries=828 etime=90 notes=U >>>> [13/Mar/2015:14:27:33 -0700] conn=48 op=21 ABANDON >>>> targetop=NOTFOUND msgid=16 >>>> [13/Mar/2015:14:27:33 -0700] conn=48 op=22 SRCH >>>> base="cn=users,cn=accounts,dc=corp,dc=company,dc=com" scope=0 >>>> filter="(objectClass=*)" attrs="* aci" >>>> [13/Mar/2015:14:27:33 -0700] conn=48 op=22 RESULT err=0 tag=101 >>>> nentries=1 etime=0 >>>> [13/Mar/2015:14:27:33 -0700] conn=48 op=23 ABANDON >>>> targetop=NOTFOUND msgid=18 >>>> [13/Mar/2015:14:27:42 -0700] conn=67 fd=103 slot=103 connection >>>> from ::1 to ::1 >>>> [13/Mar/2015:14:27:42 -0700] conn=67 op=0 BIND dn="cn=directory >>>> manager" method=128 version=3 >>>> [13/Mar/2015:14:27:42 -0700] conn=67 op=0 RESULT err=0 tag=97 >>>> nentries=0 etime=0 dn="cn=directory manager" >>>> [13/Mar/2015:14:27:42 -0700] conn=67 op=1 SRCH >>>> base="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>> scope=2 filter="(objectClass=*)" attrs=ALL >>>> [13/Mar/2015:14:27:42 -0700] conn=67 op=1 RESULT err=0 tag=101 >>>> nentries=1 etime=0 notes=U >>>> [13/Mar/2015:14:27:42 -0700] conn=67 op=2 UNBIND >>>> [13/Mar/2015:14:27:42 -0700] conn=67 op=2 fd=103 closed - U1 >>>> >>>> And target not found??? what else I might be missing ? >>>> >>>> Thanks! >>>> >>>> >>>> On 2015-03-13 21:01, Noriko Hosoi wrote: >>>>> On 03/13/2015 01:49 PM, g.fer.ordas at unicyber.co.uk wrote: >>>>>> Hi >>>>>> >>>>>> Restarted... And I also have re-initiated the replica just in >>>>>> case.... >>>>>> >>>>>> I can see the following: >>>>>> --- >>>>>> 3/Mar/2015:13:41:35 -0700] conn=34 op=329 RESULT err=0 tag=101 >>>>>> nentries=1 etime=0 >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 fd=84 slot=84 SSL connection >>>>>> from AD.SERVER to IPA.SERVER >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 SSL 128-bit AES >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 BIND >>>>>> dn="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>>> method=128 version=3 >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 RESULT err=32 tag=97 >>>>>> nentries=0 etime=0 >>>>> Error 32 is LDAP_NO_SUCH_OBJECT. >>>>> Do you have a user >>>>> "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" in your >>>>> Directory Server? >>>>> >>>>> On the host/VM where your Direcotry Server is running, please run >>>>> this >>>>> command line search. Does it return the entry? >>>>> ldapsearch -x -h localhost -p 389 -D 'cn=directory manager' -W -b >>>>> "uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=1 SRCH >>>>>> base="cn=users,cn=accounts,dc=corp,dc=company,dc=com" scope=2 >>>>>> filter="(ntUserDomainId=john.test)" attrs=ALL >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=1 RESULT err=0 tag=101 >>>>>> nentries=1 etime=0 >>>>>> [13/Mar/2015:13:41:36 -0700] conn=34 op=330 SRCH >>>>>> base="cn=meTohqdc1.corp.company.com,cn=replica,cn=dc\3Dcorp\2Cdc\3Dcompany\2Cdc\3Dcom,cn=mapping >>>>>> tree,cn=config" scope=0 filter="(objectClass=*)" >>>>>> attrs="nsds5replicaLastInitStart nsds5replicaUpdateInProgress >>>>>> nsds5replicaLastInitStatus cn nsds5BeginReplicaRefresh >>>>>> nsds5replicaLastInitEnd" >>>>>> [13/Mar/2015:13:41:36 -0700] conn=34 op=330 RESULT err=0 tag=101 >>>>>> nentries=1 etime=0 >>>>>> [13/Mar/2015:13:41:36 -0700] conn=36 fd=101 slot=101 SSL >>>>>> connection from AD.SERVER to IPA.SERVER >>>>>> [13/Mar/2015:13:41:36 -0700] conn=36 SSL 128-bit AES >>>>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=0 BIND >>>>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>>> method=128 version=3 >>>>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=0 RESULT err=48 tag=97 >>>>>> nentries=0 etime=0 >>>>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=1 UNBIND >>>>>> [13/Mar/2015:13:41:36 -0700] conn=36 op=1 fd=101 closed - U1 >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=2 MOD >>>>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=2 RESULT err=50 tag=103 >>>>>> nentries=0 etime=0 >>>>> Since the above bind failed, your PassSync has no right to update the >>>>> password on the Directory Server and the modify attempt failed with >>>>> LDAP_INSUFFICIENT_ACCESS. >>>>> >>>>> Thanks, >>>>> --noriko >>>>>> [13/Mar/2015:13:41:37 -0700] conn=35 op=3 UNBIND >>>>>> [13/Mar/2015:13:41:37 -0700] conn=35 op=3 fd=84 closed - U1 >>>>>> >>>>>> -- >>>>>> >>>>>> Note there are 2 errors there: >>>>>> dn="uid=passsync,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>>> method=128 version=3 >>>>>> [13/Mar/2015:13:41:36 -0700] conn=35 op=0 RESULT err=32 tag=97 >>>>>> nentries=0 etime=0 >>>>>> dn="uid=john.test,cn=users,cn=accounts,dc=corp,dc=company,dc=com" >>>>>> method=128 version=3 >>>>>> >>>>>> ipa user-show John.Test >>>>>> >>>>>> User login: john.test >>>>>> >>>>>> First name: John >>>>>> >>>>>> Last name: Test >>>>>> >>>>>> Home directory: /home/john.test >>>>>> >>>>>> Login shell: /bin/bash >>>>>> >>>>>> UID: 1481000790 >>>>>> >>>>>> GID: 1481000790 >>>>>> >>>>>> Account disabled: False >>>>>> >>>>>> Password: False >>>>>> >>>>>> Kerberos keys available: False >>>>>> >>>>>> >>>>>> the password is still set as False >>>>>> The PassSync Tool got defined as base search: >>>>>> >>>>>> cn=users,cn=accounts,dc=corp,dc=company,dc=com .. Which should be >>>>>> all right >>>>>> >>>>>> Thanks for all your help! >>>>>> >>> >> > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Thu Mar 19 18:46:51 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Thu, 19 Mar 2015 19:46:51 +0100 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: <550B171A.6070600@redhat.com> References: <54F97E3A.6090803@redhat.com> <550B171A.6070600@redhat.com> Message-ID: Hi Dmitri, I do realise my question is borderline and I accept that it is considered off-topic. I did post it here because I believe it's not *only* about NFS, but also about its interaction with freeIPA. The issue of NFS home and in particular about their creation is touched in all the links I posted (all about freeIPA) and never really answered. Best, Roberto On 19 March 2015 at 19:36, Dmitri Pal wrote: > On 03/19/2015 05:29 AM, Roberto Cornacchia wrote: > > On 6 March 2015 at 11:15, Martin Kosek wrote: > >> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: >> >>> Hi there, >>> >>> I'm planning to deploy freeIPA on our lan. >>> It's small-ish and completely based on FC21, so I expect everything to >>> work >>> like a charm. >>> >>> Except one detail. We have Synology NAS station, which uses DSM 5.0. >>> The ideal plan is to use it as host for shared NFS home dirs once we >>> switch our >>> desktops to freeIPA. >>> >> >> Great! >> >>> >>> > Hello, > > The first thing I'm struggling with is to find the correct approach > about NFS home dirs. > The ideal setting would be: > - home dirs on the NAS > - IPA manages automount maps > - home dirs are created automatically at first login > > The documentation I could find on these topics includes only > not-so-recent pages (anything I missed?): > > http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html > > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories > http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/ > > Now, I admit I don't have much experience with setting up NFS homes, > with or without freeIPA, so trying to get this done correctly in the > context of freeIPA and without clear howtos isn't very easy, but I'm > willing to get my hands dirty. > > The first problem I struggle with is on the correct approach. > From the documentation above, I understand that there is a bit of a > chicken-egg problem about the creation of home dirs. > On the one hand, it would be optimal to have automount maps to load only > single home dirs on demand, rather than the entire /home tree. > On the other hand, if the /home tree is not available, then creating > /home/user1 dir automatically isn't really possible. > > Just mounting the whole /home tree would make things easier, but I don't > have a feeling of when it starts to become a performance issue (assuming > recent hardware and up to date software). 10 users? 50? 100? 500? No idea. > The realm I'm dealing with at the moment is in the range of 5-10 users and > probably won't be larger than 50 in the next few years (and if it will, it > means things are going well, so what the heck ;) > Also true that, with such few users, I could just create the homedirs > manually when needed (this is not an organisation where many users come and > go) and just mount the individually. > Any tips about this? > > Best, Roberto > > > > > Some of these questions are really outside the scope of this list. > You might consider asking them on the NFS list. > > -- > 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 prasun.gera at gmail.com Thu Mar 19 19:09:01 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 19 Mar 2015 15:09:01 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: <20150319155704.GA1389@redhat.com> References: <5509CE2D.8080108@redhat.com> <5509F468.2040400@redhat.com> <20150319155704.GA1389@redhat.com> Message-ID: I thought a bit more about the issue of conflicts in /var/lib/sss/db, and I think it's a pretty significant problem, probably from a security standpoint too. The fact that it's trying to authenticate against something stale and incorrect would imply that it might erroneously authenticate against something it should not. Also, this problem would lock out all clients and be a nightmare to deal with if the master server needs to be replaced/migrated. On Thu, Mar 19, 2015 at 11:57 AM, Nalin Dahyabhai wrote: > On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote: > > > getcert status > > > process 31282: arguments to dbus_message_new_method_call() were > > > incorrect, assertion "path != NULL" failed in file dbus-message.c line > 1262. > > > This is normally a bug in some application using the D-Bus library. > > > D-Bus not built with -rdynamic so unable to print a backtrace > > > Aborted (core dumped) > > > > Please open a bug against certmonger. > > I'm pretty sure this one's already being tracked as #1148001. > > Cheers, > > Nalin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Mar 19 19:49:21 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Mar 2015 15:49:21 -0400 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: References: <54F97E3A.6090803@redhat.com> <550B171A.6070600@redhat.com> Message-ID: <550B2841.5000905@redhat.com> On 03/19/2015 02:46 PM, Roberto Cornacchia wrote: > Hi Dmitri, > > I do realise my question is borderline and I accept that it is > considered off-topic. > > I did post it here because I believe it's not *only* about NFS, but > also about its interaction with freeIPA. The issue of NFS home and in > particular about their creation is touched in all the links I posted > (all about freeIPA) and never really answered. > This is what documented and recommended: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs RHEL6 has a similar chapter in its doc set though books have changed significantly between 6 and 7. I do not see any chicken and egg problem there. The instructions show how to create home dirs on the first login. It mounts the volume and then creates dirs on it as users log in if they are not already there. It is unclear what problem you see with doing it the way it is recommended. > Best, > Roberto > > On 19 March 2015 at 19:36, Dmitri Pal > wrote: > > On 03/19/2015 05:29 AM, Roberto Cornacchia wrote: >> On 6 March 2015 at 11:15, Martin Kosek > > wrote: >> >> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: >> >> Hi there, >> >> I'm planning to deploy freeIPA on our lan. >> It's small-ish and completely based on FC21, so I expect >> everything to work >> like a charm. >> >> Except one detail. We have Synology NAS station, which >> uses DSM 5.0. >> The ideal plan is to use it as host for shared NFS home >> dirs once we switch our >> desktops to freeIPA. >> >> >> Great! >> >> >> >> Hello, >> >> The first thing I'm struggling with is to find the correct >> approach about NFS home dirs. >> The ideal setting would be: >> - home dirs on the NAS >> - IPA manages automount maps >> - home dirs are created automatically at first login >> >> The documentation I could find on these topics includes only >> not-so-recent pages (anything I missed?): >> >> http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories >> http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/ >> >> Now, I admit I don't have much experience with setting up NFS >> homes, with or without freeIPA, so trying to get this done >> correctly in the context of freeIPA and without clear howtos >> isn't very easy, but I'm willing to get my hands dirty. >> >> The first problem I struggle with is on the correct approach. >> From the documentation above, I understand that there is a bit of >> a chicken-egg problem about the creation of home dirs. >> On the one hand, it would be optimal to have automount maps to >> load only single home dirs on demand, rather than the entire >> /home tree. >> On the other hand, if the /home tree is not available, then >> creating /home/user1 dir automatically isn't really possible. >> >> Just mounting the whole /home tree would make things easier, but >> I don't have a feeling of when it starts to become a performance >> issue (assuming recent hardware and up to date software). 10 >> users? 50? 100? 500? No idea. >> The realm I'm dealing with at the moment is in the range of 5-10 >> users and probably won't be larger than 50 in the next few years >> (and if it will, it means things are going well, so what the heck ;) >> Also true that, with such few users, I could just create the >> homedirs manually when needed (this is not an organisation where >> many users come and go) and just mount the individually. >> Any tips about this? >> >> Best, Roberto >> >> >> > Some of these questions are really outside the scope of this list. > You might consider asking them on the NFS list. > > -- > 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 jhrozek at redhat.com Thu Mar 19 20:05:12 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 21:05:12 +0100 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX In-Reply-To: References: <20150319152348.GL3591@hendrix.arn.redhat.com> Message-ID: <8B69617A-9B4B-4FF6-A9B4-ACEFBE1E2A80@redhat.com> I'm running a bit out of time today, but I'll be doing some 7.1 builds tomorrow anyway, so I'll spin up the test package for you. > On 19 Mar 2015, at 16:31, Gould, Joshua wrote: > > RHEL 7.0 fully up to date. > > sssd-krb5-common-1.12.2-58.el7.x86_64 > sssd-ipa-1.12.2-58.el7.x86_64 > sssd-1.12.2-58.el7.x86_64 > sssd-tools-1.12.2-58.el7.x86_64 > sssd-common-1.12.2-58.el7.x86_64 > sssd-ad-1.12.2-58.el7.x86_64 > sssd-krb5-1.12.2-58.el7.x86_64 > sssd-ldap-1.12.2-58.el7.x86_64 > sssd-client-1.12.2-58.el7.x86_64 > sssd-common-pac-1.12.2-58.el7.x86_64 > sssd-proxy-1.12.2-58.el7.x86_64 > > > > On 3/19/15, 11:23 AM, "Jakub Hrozek" wrote: > >> On Thu, Mar 19, 2015 at 11:05:45AM -0400, Gould, Joshua wrote: >>> I?m seeing ssh logins for AD users take MUCH longer when using SID >>> mapping >>> vs. POSIX attributes. Both myself and our AD admin would prefer to use >>> SID >>> mapping. It appears tied to the group lookup at login. There seem to be >>> many posts about it, but I haven?t found anything to help much. sssd >>> pegs >>> the CPU for the 15 or so seconds the login takes. >> >> You haven't said what OS or release are you running, but for 7.0 I have >> test packages with a proposed enhancement Sumit wrote: >> >> https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople. >> org_sssd-2Dtest-2Dbuilds_sssd-2D7.0-2Dlogin-2Dspeedup_&d=AwIFAw&c=k9MF1d71 >> ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv >> JwojC24&m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gs&s=bYcFLFGsd6BT_1ozcn >> 1r1WaYFWJ4_5xT5ddR7d45Z08&e= >> >> Please include the versions of the problematic packages in the future >> requests for troubleshooting. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com_mailma >> n_listinfo_freeipa-2Dusers&d=AwIFAw&c=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S >> FEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24&m=YA1l-b8irE5VE9qVc1 >> q4PY8RVJA2iLwWLK_U7aXS1gs&s=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2k&e= >> >> Go to >> https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.org&d=AwIFAw&c >> =k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk >> 8zPbIs_SvJwojC24&m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gs&s=F_LQz74bb >> hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznw&e= for more info on the project > From roberto.cornacchia at gmail.com Thu Mar 19 20:18:57 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Thu, 19 Mar 2015 21:18:57 +0100 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: <550B2841.5000905@redhat.com> References: <54F97E3A.6090803@redhat.com> <550B171A.6070600@redhat.com> <550B2841.5000905@redhat.com> Message-ID: It's possible that I'm simply not getting the point, or that I don't understand the documentation correctly, but this is what I don't find clear: I had seen the instructions you pointed me at. These are not specifically about home directories. However, this section is: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs It first suggests that automatic creation of home directories over NFS shares is possible: just automount /home and then use pam_oddjob_mkhomedir or pam_mkhomedir to create homedirs at first login. But then it also suggests that mounting the whole /home tree could be an issue, and says: "*Use automount to mount only the user's home directory and only when the user logs in, rather than loading the entire /home tree."* That means that automatic homedir creation is out of the game, doesn't it? That's what I find confusing. What's the recommended way? On 19 March 2015 at 20:49, Dmitri Pal wrote: > On 03/19/2015 02:46 PM, Roberto Cornacchia wrote: > > Hi Dmitri, > > I do realise my question is borderline and I accept that it is > considered off-topic. > > I did post it here because I believe it's not *only* about NFS, but also > about its interaction with freeIPA. The issue of NFS home and in particular > about their creation is touched in all the links I posted (all about > freeIPA) and never really answered. > > > This is what documented and recommended: > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs > > RHEL6 has a similar chapter in its doc set though books have changed > significantly between 6 and 7. > > I do not see any chicken and egg problem there. > The instructions show how to create home dirs on the first login. > > It mounts the volume and then creates dirs on it as users log in if they > are not already there. > > It is unclear what problem you see with doing it the way it is recommended. > > > > Best, > Roberto > > On 19 March 2015 at 19:36, Dmitri Pal wrote: > >> On 03/19/2015 05:29 AM, Roberto Cornacchia wrote: >> >> On 6 March 2015 at 11:15, Martin Kosek wrote: >> >>> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: >>> >>>> Hi there, >>>> >>>> I'm planning to deploy freeIPA on our lan. >>>> It's small-ish and completely based on FC21, so I expect everything to >>>> work >>>> like a charm. >>>> >>>> Except one detail. We have Synology NAS station, which uses DSM 5.0. >>>> The ideal plan is to use it as host for shared NFS home dirs once we >>>> switch our >>>> desktops to freeIPA. >>>> >>> >>> Great! >>> >>>> >>>> >> Hello, >> >> The first thing I'm struggling with is to find the correct approach >> about NFS home dirs. >> The ideal setting would be: >> - home dirs on the NAS >> - IPA manages automount maps >> - home dirs are created automatically at first login >> >> The documentation I could find on these topics includes only >> not-so-recent pages (anything I missed?): >> >> http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >> >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html >> >> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories >> >> http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/ >> >> Now, I admit I don't have much experience with setting up NFS homes, >> with or without freeIPA, so trying to get this done correctly in the >> context of freeIPA and without clear howtos isn't very easy, but I'm >> willing to get my hands dirty. >> >> The first problem I struggle with is on the correct approach. >> From the documentation above, I understand that there is a bit of a >> chicken-egg problem about the creation of home dirs. >> On the one hand, it would be optimal to have automount maps to load only >> single home dirs on demand, rather than the entire /home tree. >> On the other hand, if the /home tree is not available, then creating >> /home/user1 dir automatically isn't really possible. >> >> Just mounting the whole /home tree would make things easier, but I >> don't have a feeling of when it starts to become a performance issue >> (assuming recent hardware and up to date software). 10 users? 50? 100? 500? >> No idea. >> The realm I'm dealing with at the moment is in the range of 5-10 users >> and probably won't be larger than 50 in the next few years (and if it will, >> it means things are going well, so what the heck ;) >> Also true that, with such few users, I could just create the homedirs >> manually when needed (this is not an organisation where many users come and >> go) and just mount the individually. >> Any tips about this? >> >> Best, Roberto >> >> >> >> >> Some of these questions are really outside the scope of this list. >> You might consider asking them on the NFS list. >> >> -- >> 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. > > > -- > 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 jhrozek at redhat.com Thu Mar 19 20:19:46 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 21:19:46 +0100 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: References: <5509CE2D.8080108@redhat.com> <5509F468.2040400@redhat.com> <20150319155704.GA1389@redhat.com> Message-ID: <8B409FD7-FB59-4B6B-91D7-E9053DABFA7D@redhat.com> > On 19 Mar 2015, at 20:09, Prasun Gera wrote: > > I thought a bit more about the issue of conflicts in /var/lib/sss/db, and I think it's a pretty significant problem, probably from a security standpoint too. The fact that it's trying to authenticate against something stale and incorrect would imply that it might erroneously authenticate against something it should not. Also, this problem would lock out all clients and be a nightmare to deal with if the master server needs to be replaced/migrated. > I'm sorry to come late into this thread, but from the subject it wasn't clear it's also about SSSD. Can you describe the problem better? How did you manage to create conflicts in sssd database? > On Thu, Mar 19, 2015 at 11:57 AM, Nalin Dahyabhai wrote: > On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote: > > > getcert status > > > process 31282: arguments to dbus_message_new_method_call() were > > > incorrect, assertion "path != NULL" failed in file dbus-message.c line 1262. > > > This is normally a bug in some application using the D-Bus library. > > > D-Bus not built with -rdynamic so unable to print a backtrace > > > Aborted (core dumped) > > > > Please open a bug against certmonger. > > I'm pretty sure this one's already being tracked as #1148001. > > Cheers, > > Nalin > > -- > 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 jhrozek at redhat.com Thu Mar 19 20:23:09 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 19 Mar 2015 21:23:09 +0100 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: References: <54F97E3A.6090803@redhat.com> <550B171A.6070600@redhat.com> <550B2841.5000905@redhat.com> Message-ID: <9290BB8D-824B-40CD-8D36-B3CA317696ED@redhat.com> > On 19 Mar 2015, at 21:18, Roberto Cornacchia wrote: > > It's possible that I'm simply not getting the point, or that I don't understand the documentation correctly, but this is what I don't find clear: > > I had seen the instructions you pointed me at. These are not specifically about home directories. > > However, this section is: https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs > > It first suggests that automatic creation of home directories over NFS shares is possible: just automount /home and then use pam_oddjob_mkhomedir or pam_mkhomedir to create homedirs at first login. > > But then it also suggests that mounting the whole /home tree could be an issue, and says: "Use automount to mount only the user's home directory and only when the user logs in, rather than loading the entire /home tree." > > That means that automatic homedir creation is out of the game, doesn't it? > > That's what I find confusing. What's the recommended way? > It really depends on your environment. For your size, it's perfectly fine to NFS mount the whole /home tree and be done with it. Don't optimize prematurely :-) > > > On 19 March 2015 at 20:49, Dmitri Pal wrote: > On 03/19/2015 02:46 PM, Roberto Cornacchia wrote: >> Hi Dmitri, >> >> I do realise my question is borderline and I accept that it is considered off-topic. >> >> I did post it here because I believe it's not *only* about NFS, but also about its interaction with freeIPA. The issue of NFS home and in particular about their creation is touched in all the links I posted (all about freeIPA) and never really answered. >> > > This is what documented and recommended: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs > > RHEL6 has a similar chapter in its doc set though books have changed significantly between 6 and 7. > > I do not see any chicken and egg problem there. > The instructions show how to create home dirs on the first login. > > It mounts the volume and then creates dirs on it as users log in if they are not already there. > > It is unclear what problem you see with doing it the way it is recommended. > > > >> Best, >> Roberto >> >> On 19 March 2015 at 19:36, Dmitri Pal wrote: >> On 03/19/2015 05:29 AM, Roberto Cornacchia wrote: >>> On 6 March 2015 at 11:15, Martin Kosek wrote: >>> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: >>> Hi there, >>> >>> I'm planning to deploy freeIPA on our lan. >>> It's small-ish and completely based on FC21, so I expect everything to work >>> like a charm. >>> >>> Except one detail. We have Synology NAS station, which uses DSM 5.0. >>> The ideal plan is to use it as host for shared NFS home dirs once we switch our >>> desktops to freeIPA. >>> >>> Great! >>> >>> >>> Hello, >>> >>> The first thing I'm struggling with is to find the correct approach about NFS home dirs. >>> The ideal setting would be: >>> - home dirs on the NAS >>> - IPA manages automount maps >>> - home dirs are created automatically at first login >>> >>> The documentation I could find on these topics includes only not-so-recent pages (anything I missed?): >>> >>> http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA >>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html >>> http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories >>> http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/ >>> >>> Now, I admit I don't have much experience with setting up NFS homes, with or without freeIPA, so trying to get this done correctly in the context of freeIPA and without clear howtos isn't very easy, but I'm willing to get my hands dirty. >>> >>> The first problem I struggle with is on the correct approach. >>> From the documentation above, I understand that there is a bit of a chicken-egg problem about the creation of home dirs. >>> On the one hand, it would be optimal to have automount maps to load only single home dirs on demand, rather than the entire /home tree. >>> On the other hand, if the /home tree is not available, then creating /home/user1 dir automatically isn't really possible. >>> >>> Just mounting the whole /home tree would make things easier, but I don't have a feeling of when it starts to become a performance issue (assuming recent hardware and up to date software). 10 users? 50? 100? 500? No idea. >>> The realm I'm dealing with at the moment is in the range of 5-10 users and probably won't be larger than 50 in the next few years (and if it will, it means things are going well, so what the heck ;) >>> Also true that, with such few users, I could just create the homedirs manually when needed (this is not an organisation where many users come and go) and just mount the individually. >>> Any tips about this? >>> >>> Best, Roberto >>> >>> >>> >>> >> Some of these questions are really outside the scope of this list. >> You might consider asking them on the NFS list. >> >> -- >> 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. > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From roberto.cornacchia at gmail.com Thu Mar 19 20:46:07 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Thu, 19 Mar 2015 21:46:07 +0100 Subject: [Freeipa-users] ipa-client-install failure Message-ID: Hi, This should really work like a charm, and I'm sure it is a stupid mistake of mine if it doesn't, but I really can't find out what goes wrong. Both IPA server and client are on FC21, very up to date. Server installation (standard, with dns) worked well. Required ports open in the firewall. Everything seems to work. I did try to use the IPA server as a DNS (with forwarders) and NTP server from non-ipa clients, no problem. I also tried to use it as LDAP server, from a non-fedora machine (a synology). It worked well and I could see users. When trying to enroll a client, the enrollment itself seems to succeed, but: - Unable to sync time with NTP server - Unable to update DNS - Unable to find users I include below the short installation log (I changed the real domain into hq.example.com), and in attachment, the full log with debug on. >From the debug log, about the DNS update failure, I can see this: ; Communication with 192.168.0.72#53 failed: operation canceled could not reach any name server I'm not sure what communication problem this could be, as the server (which is both the IPA and the DNS servers), clearly can be reached. Any idea where to look at? Thanks, Roberto [root at meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd --hostname=meson.hq.example.com Discovery was successful! Hostname: meson.hq.example.com Realm: HQ.EXAMPLE.COM DNS Domain: hq.example.com IPA Server: ipa.hq.example.com BaseDN: dc=hq,dc=example,dc=com Continue to configure the system with these values? [no]: yes Synchronizing time with KDC... *Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened.* User authorized to enroll computers: admin Password for admin at HQ.EXAMPLE.COM: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM Valid From: Mon Mar 16 18:44:35 2015 UTC Valid Until: Fri Mar 16 18:44:35 2035 UTC Enrolled in IPA realm HQ.EXAMPLE.COM 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 HQ.EXAMPLE.COM trying https://ipa.hq.example.com/ipa/json Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' Forwarding 'ca_is_enabled' to json server ' https://ipa.hq.example.com/ipa/json' Systemwide CA database updated. Added CA certificates to the default NSS database. Hostname (meson.hq.example.com) not found in DNS *Failed to update DNS records.* Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json' *Could not update DNS SSHFP records.* SSSD enabled Configured /etc/openldap/ldap.conf *Unable to find 'admin' user with 'getent passwd admin at hq.example.com '!* *Unable to reliably detect configuration. Check NSS setup manually.* NTP enabled Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Configuring hq.example.com as NIS domain. Client configuration complete. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: ipa-client-install_debug.log Type: text/x-log Size: 92883 bytes Desc: not available URL: From roberto.cornacchia at gmail.com Thu Mar 19 20:51:08 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Thu, 19 Mar 2015 21:51:08 +0100 Subject: [Freeipa-users] Synology DSM5 and freeIPA In-Reply-To: <9290BB8D-824B-40CD-8D36-B3CA317696ED@redhat.com> References: <54F97E3A.6090803@redhat.com> <550B171A.6070600@redhat.com> <550B2841.5000905@redhat.com> <9290BB8D-824B-40CD-8D36-B3CA317696ED@redhat.com> Message-ID: Thanks, Jakub. On 19 March 2015 at 21:23, Jakub Hrozek wrote: > > > On 19 Mar 2015, at 21:18, Roberto Cornacchia < > roberto.cornacchia at gmail.com> wrote: > > > > It's possible that I'm simply not getting the point, or that I don't > understand the documentation correctly, but this is what I don't find clear: > > > > I had seen the instructions you pointed me at. These are not > specifically about home directories. > > > > However, this section is: > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#homedir-reqs > > > > It first suggests that automatic creation of home directories over NFS > shares is possible: just automount /home and then use pam_oddjob_mkhomedir > or pam_mkhomedir to create homedirs at first login. > > > > But then it also suggests that mounting the whole /home tree could be an > issue, and says: "Use automount to mount only the user's home directory and > only when the user logs in, rather than loading the entire /home tree." > > > > That means that automatic homedir creation is out of the game, doesn't > it? > > > > That's what I find confusing. What's the recommended way? > > > > It really depends on your environment. For your size, it's perfectly fine > to NFS mount the whole /home tree and be done with it. Don't optimize > prematurely :-) > > > > > > > On 19 March 2015 at 20:49, Dmitri Pal wrote: > > On 03/19/2015 02:46 PM, Roberto Cornacchia wrote: > >> Hi Dmitri, > >> > >> I do realise my question is borderline and I accept that it is > considered off-topic. > >> > >> I did post it here because I believe it's not *only* about NFS, but > also about its interaction with freeIPA. The issue of NFS home and in > particular about their creation is touched in all the links I posted (all > about freeIPA) and never really answered. > >> > > > > This is what documented and recommended: > > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html-single/Linux_Domain_Identity_Authentication_and_Policy_Guide/index.html#kerb-nfs > > > > RHEL6 has a similar chapter in its doc set though books have changed > significantly between 6 and 7. > > > > I do not see any chicken and egg problem there. > > The instructions show how to create home dirs on the first login. > > > > It mounts the volume and then creates dirs on it as users log in if they > are not already there. > > > > It is unclear what problem you see with doing it the way it is > recommended. > > > > > > > >> Best, > >> Roberto > >> > >> On 19 March 2015 at 19:36, Dmitri Pal wrote: > >> On 03/19/2015 05:29 AM, Roberto Cornacchia wrote: > >>> On 6 March 2015 at 11:15, Martin Kosek wrote: > >>> On 03/06/2015 10:56 AM, Roberto Cornacchia wrote: > >>> Hi there, > >>> > >>> I'm planning to deploy freeIPA on our lan. > >>> It's small-ish and completely based on FC21, so I expect everything to > work > >>> like a charm. > >>> > >>> Except one detail. We have Synology NAS station, which uses DSM 5.0. > >>> The ideal plan is to use it as host for shared NFS home dirs once we > switch our > >>> desktops to freeIPA. > >>> > >>> Great! > >>> > >>> > >>> Hello, > >>> > >>> The first thing I'm struggling with is to find the correct approach > about NFS home dirs. > >>> The ideal setting would be: > >>> - home dirs on the NAS > >>> - IPA manages automount maps > >>> - home dirs are created automatically at first login > >>> > >>> The documentation I could find on these topics includes only > not-so-recent pages (anything I missed?): > >>> > >>> http://wiki.linux-nfs.org/wiki/index.php/NFS_and_FreeIPA > >>> > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/automount.html > >>> > http://docs.fedoraproject.org/en-US/Fedora/18/html/FreeIPA_Guide/users.html#home-directories > >>> > http://adam.younglogic.com/2011/06/automount-and-home-directory-creation/ > >>> > >>> Now, I admit I don't have much experience with setting up NFS homes, > with or without freeIPA, so trying to get this done correctly in the > context of freeIPA and without clear howtos isn't very easy, but I'm > willing to get my hands dirty. > >>> > >>> The first problem I struggle with is on the correct approach. > >>> From the documentation above, I understand that there is a bit of a > chicken-egg problem about the creation of home dirs. > >>> On the one hand, it would be optimal to have automount maps to load > only single home dirs on demand, rather than the entire /home tree. > >>> On the other hand, if the /home tree is not available, then creating > /home/user1 dir automatically isn't really possible. > >>> > >>> Just mounting the whole /home tree would make things easier, but I > don't have a feeling of when it starts to become a performance issue > (assuming recent hardware and up to date software). 10 users? 50? 100? 500? > No idea. > >>> The realm I'm dealing with at the moment is in the range of 5-10 users > and probably won't be larger than 50 in the next few years (and if it will, > it means things are going well, so what the heck ;) > >>> Also true that, with such few users, I could just create the homedirs > manually when needed (this is not an organisation where many users come and > go) and just mount the individually. > >>> Any tips about this? > >>> > >>> Best, Roberto > >>> > >>> > >>> > >>> > >> Some of these questions are really outside the scope of this list. > >> You might consider asking them on the NFS list. > >> > >> -- > >> 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. > > > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > > > -- > > Manage your subscription for the Freeipa-users mailing list: > > https://www.redhat.com/mailman/listinfo/freeipa-users > > Go to http://freeipa.org for more info on the project > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Mar 19 20:55:59 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Mar 2015 16:55:59 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: Message-ID: <550B37DF.9000504@redhat.com> On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: > Hi, > > This should really work like a charm, and I'm sure it is a stupid > mistake of mine if it doesn't, but I really can't find out what goes > wrong. > > Both IPA server and client are on FC21, very up to date. > Server installation (standard, with dns) worked well. Required ports > open in the firewall. Everything seems to work. > > I did try to use the IPA server as a DNS (with forwarders) and NTP > server from non-ipa clients, no problem. > I also tried to use it as LDAP server, from a non-fedora machine (a > synology). It worked well and I could see users. > > When trying to enroll a client, the enrollment itself seems to > succeed, but: > - Unable to sync time with NTP server > - Unable to update DNS > - Unable to find users > > I include below the short installation log (I changed the real domain > into hq.example.com ), and in attachment, the > full log with debug on. > > From the debug log, about the DNS update failure, I can see this: > > ; Communication with 192.168.0.72#53 failed: operation canceled > could not reach any name server > > I'm not sure what communication problem this could be, as the server > (which is both the IPA and the DNS servers), clearly can be reached. > > Any idea where to look at? Do you have the IPA DNS server in the resolv.conf of the client? > > Thanks, > Roberto > > > [root at meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns > --force-ntpd --hostname=meson.hq.example.com > > Discovery was successful! > Hostname: meson.hq.example.com > Realm: HQ.EXAMPLE.COM > DNS Domain: hq.example.com > IPA Server: ipa.hq.example.com > BaseDN: dc=hq,dc=example,dc=com > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > *Unable to sync time with IPA NTP server, assuming the time is in > sync. Please check that 123 UDP port is opened.* > User authorized to enroll computers: admin > Password for admin at HQ.EXAMPLE.COM : > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM > > Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM > > Valid From: Mon Mar 16 18:44:35 2015 UTC > Valid Until: Fri Mar 16 18:44:35 2035 UTC > > Enrolled in IPA realm HQ.EXAMPLE.COM > 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 HQ.EXAMPLE.COM > > trying https://ipa.hq.example.com/ipa/json > Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' > Forwarding 'ca_is_enabled' to json server > 'https://ipa.hq.example.com/ipa/json' > Systemwide CA database updated. > Added CA certificates to the default NSS database. > Hostname (meson.hq.example.com ) not > found in DNS > *Failed to update DNS records.* > Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json' > *Could not update DNS SSHFP records.* > SSSD enabled > Configured /etc/openldap/ldap.conf > *Unable to find 'admin' user with 'getent passwd admin at hq.example.com > '!* > *Unable to reliably detect configuration. Check NSS setup manually.* > NTP enabled > Configured /etc/ssh/ssh_config > Configured /etc/ssh/sshd_config > Configuring hq.example.com as NIS domain. > Client configuration complete. > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Thu Mar 19 21:04:12 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Thu, 19 Mar 2015 22:04:12 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550B37DF.9000504@redhat.com> References: <550B37DF.9000504@redhat.com> Message-ID: Yes. [root at meson ~]# cat /etc/resolv.conf search hq.example.com nameserver 192.168.0.72 Sorry from the short log I posted it's not visible, but that ip address is the address of the ipa server (ipa.hq.example.com) [root at meson ~]# dig ipa.hq.spinque.com ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com ;; global options: +cmd ;; Got answer: ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238 ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 ;; OPT PSEUDOSECTION: ; EDNS: version: 0, flags:; udp: 4096 ;; QUESTION SECTION: ;ipa.hq.example.com. IN A ;; ANSWER SECTION: ipa.hq.example.com. 1200 IN A 192.168.0.72 ;; AUTHORITY SECTION: hq.example.com. 86400 IN NS ipa.hq.example.com. ;; Query time: 1 msec ;; SERVER: 192.168.0.72#53(192.168.0.72) ;; WHEN: do mrt 19 22:02:04 CET 2015 ;; MSG SIZE rcvd: 83 On 19 March 2015 at 21:55, Dmitri Pal wrote: > On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: > > Hi, > > This should really work like a charm, and I'm sure it is a stupid > mistake of mine if it doesn't, but I really can't find out what goes wrong. > > Both IPA server and client are on FC21, very up to date. > Server installation (standard, with dns) worked well. Required ports open > in the firewall. Everything seems to work. > > I did try to use the IPA server as a DNS (with forwarders) and NTP > server from non-ipa clients, no problem. > I also tried to use it as LDAP server, from a non-fedora machine (a > synology). It worked well and I could see users. > > When trying to enroll a client, the enrollment itself seems to succeed, > but: > - Unable to sync time with NTP server > - Unable to update DNS > - Unable to find users > > I include below the short installation log (I changed the real domain > into hq.example.com), and in attachment, the full log with debug on. > > From the debug log, about the DNS update failure, I can see this: > > ; Communication with 192.168.0.72#53 failed: operation canceled > could not reach any name server > > I'm not sure what communication problem this could be, as the server > (which is both the IPA and the DNS servers), clearly can be reached. > > Any idea where to look at? > > > Do you have the IPA DNS server in the resolv.conf of the client? > > > > > Thanks, > Roberto > > > [root at meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns > --force-ntpd --hostname=meson.hq.example.com > Discovery was successful! > Hostname: meson.hq.example.com > Realm: HQ.EXAMPLE.COM > DNS Domain: hq.example.com > IPA Server: ipa.hq.example.com > BaseDN: dc=hq,dc=example,dc=com > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > *Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened.* > User authorized to enroll computers: admin > Password for admin at HQ.EXAMPLE.COM: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Valid From: Mon Mar 16 18:44:35 2015 UTC > Valid Until: Fri Mar 16 18:44:35 2035 UTC > > Enrolled in IPA realm HQ.EXAMPLE.COM > 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 HQ.EXAMPLE.COM > trying https://ipa.hq.example.com/ipa/json > Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' > Forwarding 'ca_is_enabled' to json server ' > https://ipa.hq.example.com/ipa/json' > Systemwide CA database updated. > Added CA certificates to the default NSS database. > Hostname (meson.hq.example.com) not found in DNS > *Failed to update DNS records.* > Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json' > *Could not update DNS SSHFP records.* > SSSD enabled > Configured /etc/openldap/ldap.conf > *Unable to find 'admin' user with 'getent passwd admin at hq.example.com > '!* > *Unable to reliably detect configuration. Check NSS setup manually.* > NTP enabled > Configured /etc/ssh/ssh_config > Configured /etc/ssh/sshd_config > Configuring hq.example.com as NIS domain. > Client configuration complete. > > > > > > -- > 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 roberto.cornacchia at gmail.com Thu Mar 19 21:06:26 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Thu, 19 Mar 2015 22:06:26 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> Message-ID: > > [root at meson ~]# dig ipa.hq.spinque.com > humph, sorry about the confusion, I missed one in my anonymisation step.. that would be "dig ipa.hq.example.com" -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Thu Mar 19 21:32:08 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 19 Mar 2015 22:32:08 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <20150319164610.GS3591@hendrix.arn.redhat.com> References: <5509B1D0.1050602@redhat.com> <20150319092924.GD3591@hendrix.arn.redhat.com> <20150319163309.GQ3591@hendrix.arn.redhat.com> <20150319164610.GS3591@hendrix.arn.redhat.com> Message-ID: > > > I wasn't precise enough, I meant the sssd version, sorry. But given that > you're on RHEL-7, I think you can switch to: > sudo_provider=ipa > That does indeed seem to work. Thanks! > > and remove all the ldap_ config parameters as well as krb5_server. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Thu Mar 19 21:50:50 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 19 Mar 2015 17:50:50 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: <8B409FD7-FB59-4B6B-91D7-E9053DABFA7D@redhat.com> References: <5509CE2D.8080108@redhat.com> <5509F468.2040400@redhat.com> <20150319155704.GA1389@redhat.com> <8B409FD7-FB59-4B6B-91D7-E9053DABFA7D@redhat.com> Message-ID: It's just that /var/lib/sss/db is not cleared between subsequent server installs and uninstall, and that seems to be creating problems on the server since the server is also a client. If you do install-uninstall-install on the server with the same domain name for both the installs, you cannot authenticate using sssd after the second install. A simple command like 'ssh admin at localhost' on the server gives permission denied. I don't know if this is a regression, but it would help if someone could reproduce this error. On Thu, Mar 19, 2015 at 4:19 PM, Jakub Hrozek wrote: > > > On 19 Mar 2015, at 20:09, Prasun Gera wrote: > > > > I thought a bit more about the issue of conflicts in /var/lib/sss/db, > and I think it's a pretty significant problem, probably from a security > standpoint too. The fact that it's trying to authenticate against something > stale and incorrect would imply that it might erroneously authenticate > against something it should not. Also, this problem would lock out all > clients and be a nightmare to deal with if the master server needs to be > replaced/migrated. > > > > I'm sorry to come late into this thread, but from the subject it wasn't > clear it's also about SSSD. > > Can you describe the problem better? How did you manage to create > conflicts in sssd database? > > > On Thu, Mar 19, 2015 at 11:57 AM, Nalin Dahyabhai > wrote: > > On Wed, Mar 18, 2015 at 05:55:52PM -0400, Rob Crittenden wrote: > > > > getcert status > > > > process 31282: arguments to dbus_message_new_method_call() were > > > > incorrect, assertion "path != NULL" failed in file dbus-message.c > line 1262. > > > > This is normally a bug in some application using the D-Bus library. > > > > D-Bus not built with -rdynamic so unable to print a backtrace > > > > Aborted (core dumped) > > > > > > Please open a bug against certmonger. > > > > I'm pretty sure this one's already being tracked as #1148001. > > > > Cheers, > > > > Nalin > > > > -- > > 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 Thu Mar 19 23:53:34 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Mar 2015 19:53:34 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> Message-ID: <550B617E.8040103@redhat.com> On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: > Yes. > > [root at meson ~]# cat /etc/resolv.conf > search hq.example.com > nameserver 192.168.0.72 > > Sorry from the short log I posted it's not visible, but that ip > address is the address of the ipa server (ipa.hq.example.com > ) > > [root at meson ~]# dig ipa.hq.spinque.com > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com > > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;ipa.hq.example.com.INA > > ;; ANSWER SECTION: > ipa.hq.example.com. 1200INA192.168.0.72 > > ;; AUTHORITY SECTION: > hq.example.com.86400INNSipa.hq.example.com. > > ;; Query time: 1 msec > ;; SERVER: 192.168.0.72#53(192.168.0.72) > ;; WHEN: do mrt 19 22:02:04 CET 2015 > ;; MSG SIZE rcvd: 83 OK so you can in fact lookup the server. Have you opened all required ports for ldap and kerberos and other protocols in the firewall both UDP and TCP? > > > On 19 March 2015 at 21:55, Dmitri Pal > wrote: > > On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: >> Hi, >> >> This should really work like a charm, and I'm sure it is a stupid >> mistake of mine if it doesn't, but I really can't find out what >> goes wrong. >> >> Both IPA server and client are on FC21, very up to date. >> Server installation (standard, with dns) worked well. Required >> ports open in the firewall. Everything seems to work. >> >> I did try to use the IPA server as a DNS (with forwarders) and >> NTP server from non-ipa clients, no problem. >> I also tried to use it as LDAP server, from a non-fedora machine >> (a synology). It worked well and I could see users. >> >> When trying to enroll a client, the enrollment itself seems to >> succeed, but: >> - Unable to sync time with NTP server >> - Unable to update DNS >> - Unable to find users >> >> I include below the short installation log (I changed the real >> domain into hq.example.com ), and in >> attachment, the full log with debug on. >> >> From the debug log, about the DNS update failure, I can see this: >> >> ; Communication with 192.168.0.72#53 failed: operation canceled >> could not reach any name server >> >> I'm not sure what communication problem this could be, as the >> server (which is both the IPA and the DNS servers), clearly can >> be reached. >> >> Any idea where to look at? > > Do you have the IPA DNS server in the resolv.conf of the client? > > > >> >> Thanks, >> Roberto >> >> >> [root at meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns >> --force-ntpd --hostname=meson.hq.example.com >> >> Discovery was successful! >> Hostname: meson.hq.example.com >> Realm: HQ.EXAMPLE.COM >> DNS Domain: hq.example.com >> IPA Server: ipa.hq.example.com >> BaseDN: dc=hq,dc=example,dc=com >> >> Continue to configure the system with these values? [no]: yes >> Synchronizing time with KDC... >> *Unable to sync time with IPA NTP server, assuming the time is in >> sync. Please check that 123 UDP port is opened.* >> User authorized to enroll computers: admin >> Password for admin at HQ.EXAMPLE.COM : >> Successfully retrieved CA cert >> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> >> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> >> Valid From: Mon Mar 16 18:44:35 2015 UTC >> Valid Until: Fri Mar 16 18:44:35 2035 UTC >> >> Enrolled in IPA realm HQ.EXAMPLE.COM >> 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 HQ.EXAMPLE.COM >> >> trying https://ipa.hq.example.com/ipa/json >> Forwarding 'ping' to json server >> 'https://ipa.hq.example.com/ipa/json' >> Forwarding 'ca_is_enabled' to json server >> 'https://ipa.hq.example.com/ipa/json' >> Systemwide CA database updated. >> Added CA certificates to the default NSS database. >> Hostname (meson.hq.example.com ) not >> found in DNS >> *Failed to update DNS records.* >> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> Forwarding 'host_mod' to json server >> 'https://ipa.hq.example.com/ipa/json' >> *Could not update DNS SSHFP records.* >> SSSD enabled >> Configured /etc/openldap/ldap.conf >> *Unable to find 'admin' user with 'getent passwd >> admin at hq.example.com '!* >> *Unable to reliably detect configuration. Check NSS setup manually.* >> NTP enabled >> Configured /etc/ssh/ssh_config >> Configured /etc/ssh/sshd_config >> Configuring hq.example.com as NIS domain. >> Client configuration complete. >> >> >> > > > -- > 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 nathan at nathanpeters.com Thu Mar 19 23:55:19 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Thu, 19 Mar 2015 16:55:19 -0700 Subject: [Freeipa-users] AD users not getting single sign on (Solaris) Message-ID: <127387e6bc1ec1c0b2446eb9ded966da.squirrel@webmail.nathanpeters.com> I have finally gotten all of my Solaris servers to accept AD users but the behavior is inconsistent. In my FreeIPA domain, I can login to a Linux server and then ssh to the Solaris server and I am automatically logged in because of my Kerberos ticket (I assume). But when I ssh from the first Solaris machine to the 2nd I am prompted for a password instead of being automatically signed in. The strange thing is that it doesn't matter which machine I login to first, it's only the 2nd hop that asks for a password. Below are my console recording. ipaclient1 is Linux, ipaclient5 and ipaclient6 are Solaris. Login from Linux -> Solaris 1 works without password Login from Linux -> Solaris 2 works without password Login from Solaris 1 -> Solaris 2 prompts Login from Solaris 2 -> Solaris 1 prompts. Any ideas? ---- snip ---- login as: nathan.peters nathan.peters at 10.21.19.12's password: Last login: Thu Mar 19 16:42:27 2015 from 10.5.5.57 [nathan.peters at datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$ klist Ticket cache: FILE:/tmp/krb5cc_1539201103_L8tfu1 Default principal: nathan.peters at DATACENTER.MYDOMAIN.NET Valid starting Expires Service principal 03/19/15 16:44:27 03/20/15 02:44:16 krbtgt/DATACENTER.MYDOMAIN.NET at DATACENTER.MYDOMAIN.NET renew until 03/20/15 16:44:27 [nathan.peters at datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$ ssh ipaclient5-sandbox-atdev-van Last login: Thu Mar 19 23:43:24 2015 from 10.21.19.12 Oracle Corporation SunOS 5.10 Generic Patch January 2005 [11:45 PM] ipaclient5-sandbox-atdev-van:~$ klist Ticket cache: FILE:/tmp/krb5cc_1539201103 Default principal: nathan.peters at DATACENTER.MYDOMAIN.NET Valid starting Expires Service principal 03/19/15 23:40:06 03/20/15 09:39:23 krbtgt/DATACENTER.MYDOMAIN.NET at DATACENTER.MYDOMAIN.NET renew until 03/26/15 23:40:06 [11:45 PM] ipaclient5-sandbox-atdev-van:~$ ssh ipaclient6-sandbox-atdev-van Password: Last login: Thu Mar 19 16:40:49 2015 from ipaclient5-sand Oracle Corporation SunOS 5.10 Generic Patch January 2005 -bash-3.00$ klist klist: No credentials cache file found (ticket cache FILE:/tmp/krb5cc_1539201103) -bash-3.00$ exit logout Connection to ipaclient6-sandbox-atdev-van closed. [11:48 PM] ipaclient5-sandbox-atdev-van:~$ exit logout Connection to ipaclient5-sandbox-atdev-van closed. [nathan.peters at datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$ ssh ipaclient6-sandbox-atdev-van Last login: Thu Mar 19 16:45:50 2015 from ipaclient5-sand Oracle Corporation SunOS 5.10 Generic Patch January 2005 -bash-3.00$ klist klist: No credentials cache file found (ticket cache FILE:/tmp/krb5cc_1539201103) -bash-3.00$ ssh ipaclient5-sandbox-atdev-van The authenticity of host 'ipaclient5-sandbox-atdev-van (10.21.19.16)' can't be established. RSA key fingerprint is b0:65:8d:c6:82:78:c2:7f:60:16:d0:6a:30:c0:09:a1. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'ipaclient5-sandbox-atdev-van,10.21.19.16' (RSA) to the list of known hosts. Password: Last login: Thu Mar 19 23:45:19 2015 from 10.21.19.12 Oracle Corporation SunOS 5.10 Generic Patch January 2005 [11:49 PM] ipaclient5-sandbox-atdev-van:~$ From dpal at redhat.com Fri Mar 20 00:02:56 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 19 Mar 2015 20:02:56 -0400 Subject: [Freeipa-users] AD users not getting single sign on (Solaris) In-Reply-To: <127387e6bc1ec1c0b2446eb9ded966da.squirrel@webmail.nathanpeters.com> References: <127387e6bc1ec1c0b2446eb9ded966da.squirrel@webmail.nathanpeters.com> Message-ID: <550B63B0.5010600@redhat.com> On 03/19/2015 07:55 PM, nathan at nathanpeters.com wrote: > I have finally gotten all of my Solaris servers to accept AD users but the > behavior is inconsistent. > > In my FreeIPA domain, I can login to a Linux server and then ssh to the > Solaris server and I am automatically logged in because of my Kerberos > ticket (I assume). > > But when I ssh from the first Solaris machine to the 2nd I am prompted for > a password instead of being automatically signed in. The strange thing is > that it doesn't matter which machine I login to first, it's only the 2nd > hop that asks for a password. > > Below are my console recording. ipaclient1 is Linux, ipaclient5 and > ipaclient6 are Solaris. > Login from Linux -> Solaris 1 works without password > Login from Linux -> Solaris 2 works without password > Login from Solaris 1 -> Solaris 2 prompts > Login from Solaris 2 -> Solaris 1 prompts. Assuming that you have: IPA and AD in trust and Solaris boxes are configured against the IPA compat tree then it would be the expected behavior. SSO is possible only with Kerberos. You authentication on Linux is against AD (through trust) so you get a Kerberos ticket. If you issued keytabs for your Solaris systems and configured SSH to use GSSAPI then SSH would provide SSO as you describe from Linux to Solaris. But once you login into Solaris box you do not have a Kerberos ticket because it is an LDAP authentication. You would ask what can be done about it? Not much. To have SSO you would need to have one of the latest Kerberos versions and something like SSSD on Solaris. It does not exist and Oracle is not eager to create one. Bottom line... move to Linux :-) > > Any ideas? > > ---- snip ---- > login as: nathan.peters > nathan.peters at 10.21.19.12's password: > Last login: Thu Mar 19 16:42:27 2015 from 10.5.5.57 > [nathan.peters at datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$ klist > Ticket cache: FILE:/tmp/krb5cc_1539201103_L8tfu1 > Default principal: nathan.peters at DATACENTER.MYDOMAIN.NET > > Valid starting Expires Service principal > 03/19/15 16:44:27 03/20/15 02:44:16 > krbtgt/DATACENTER.MYDOMAIN.NET at DATACENTER.MYDOMAIN.NET > renew until 03/20/15 16:44:27 > [nathan.peters at datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$ > ssh ipaclient5-sandbox-atdev-van > Last login: Thu Mar 19 23:43:24 2015 from 10.21.19.12 > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > [11:45 PM] ipaclient5-sandbox-atdev-van:~$ klist > Ticket cache: FILE:/tmp/krb5cc_1539201103 > Default principal: nathan.peters at DATACENTER.MYDOMAIN.NET > > Valid starting Expires Service principal > 03/19/15 23:40:06 03/20/15 09:39:23 > krbtgt/DATACENTER.MYDOMAIN.NET at DATACENTER.MYDOMAIN.NET > renew until 03/26/15 23:40:06 > [11:45 PM] ipaclient5-sandbox-atdev-van:~$ ssh ipaclient6-sandbox-atdev-van > Password: > Last login: Thu Mar 19 16:40:49 2015 from ipaclient5-sand > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > -bash-3.00$ klist > klist: No credentials cache file found (ticket cache > FILE:/tmp/krb5cc_1539201103) > -bash-3.00$ exit > logout > Connection to ipaclient6-sandbox-atdev-van closed. > [11:48 PM] ipaclient5-sandbox-atdev-van:~$ exit > logout > Connection to ipaclient5-sandbox-atdev-van closed. > [nathan.peters at datacenter.mydomain.net@ipaclient1-sandbox-atdev-van ~]$ > ssh ipaclient6-sandbox-atdev-van > Last login: Thu Mar 19 16:45:50 2015 from ipaclient5-sand > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > -bash-3.00$ klist > klist: No credentials cache file found (ticket cache > FILE:/tmp/krb5cc_1539201103) > -bash-3.00$ ssh ipaclient5-sandbox-atdev-van > The authenticity of host 'ipaclient5-sandbox-atdev-van (10.21.19.16)' > can't be established. > RSA key fingerprint is b0:65:8d:c6:82:78:c2:7f:60:16:d0:6a:30:c0:09:a1. > Are you sure you want to continue connecting (yes/no)? yes > Warning: Permanently added 'ipaclient5-sandbox-atdev-van,10.21.19.16' > (RSA) to the list of known hosts. > Password: > Last login: Thu Mar 19 23:45:19 2015 from 10.21.19.12 > Oracle Corporation SunOS 5.10 Generic Patch January 2005 > [11:49 PM] ipaclient5-sandbox-atdev-van:~$ > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From rcritten at redhat.com Fri Mar 20 02:44:42 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 19 Mar 2015 22:44:42 -0400 Subject: [Freeipa-users] AD users not getting single sign on (Solaris) In-Reply-To: <127387e6bc1ec1c0b2446eb9ded966da.squirrel@webmail.nathanpeters.com> References: <127387e6bc1ec1c0b2446eb9ded966da.squirrel@webmail.nathanpeters.com> Message-ID: <550B899A.6070008@redhat.com> nathan at nathanpeters.com wrote: > I have finally gotten all of my Solaris servers to accept AD users but the > behavior is inconsistent. > > In my FreeIPA domain, I can login to a Linux server and then ssh to the > Solaris server and I am automatically logged in because of my Kerberos > ticket (I assume). > > But when I ssh from the first Solaris machine to the 2nd I am prompted for > a password instead of being automatically signed in. The strange thing is > that it doesn't matter which machine I login to first, it's only the 2nd > hop that asks for a password. > > Below are my console recording. ipaclient1 is Linux, ipaclient5 and > ipaclient6 are Solaris. > Login from Linux -> Solaris 1 works without password > Login from Linux -> Solaris 2 works without password > Login from Solaris 1 -> Solaris 2 prompts > Login from Solaris 2 -> Solaris 1 prompts. > > Any ideas? You log into Linux and get a TGT . Using that TGT you can log into any other box (Solaris or otherwise). Unless you are delegating that TGT with each ssh login you won't have one after the first login to another system, it will be used for authentication only. See the -K option of ssh, or SSAPIDelegateCredentials yes in sshd. rob From jhrozek at redhat.com Fri Mar 20 08:00:28 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Mar 2015 09:00:28 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: References: <5509B1D0.1050602@redhat.com> <20150319092924.GD3591@hendrix.arn.redhat.com> <20150319163309.GQ3591@hendrix.arn.redhat.com> <20150319164610.GS3591@hendrix.arn.redhat.com> Message-ID: <20150320080028.GA8409@hendrix.redhat.com> On Thu, Mar 19, 2015 at 10:32:08PM +0100, Andrew Holway wrote: > > > > > > I wasn't precise enough, I meant the sssd version, sorry. But given that > > you're on RHEL-7, I think you can switch to: > > sudo_provider=ipa > > > > That does indeed seem to work. Thanks! You're welcome, btw if you set up your client using some documentation we might want to correct those docs.. From andrew.holway at gmail.com Fri Mar 20 08:16:51 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 20 Mar 2015 09:16:51 +0100 Subject: [Freeipa-users] Minimum rights to enrol a client Message-ID: Hello, I'd like to find our what the minimum role would be to allow a user to join a new client to freeipa. Currently our enrol command looks like: ipa-client-install --force-join --enable-dns-updates -U -p admin -w xxxxxxxx: Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Mar 20 08:18:58 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Mar 2015 09:18:58 +0100 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX In-Reply-To: References: <20150319152348.GL3591@hendrix.arn.redhat.com> <8B69617A-9B4B-4FF6-A9B4-ACEFBE1E2A80@redhat.com> Message-ID: <20150320081858.GB8409@hendrix.redhat.com> On Thu, Mar 19, 2015 at 05:29:39PM -0400, Gould, Joshua wrote: > Thank you! You're welcome, please try these builds: https://jhrozek.fedorapeople.org/sssd-test-builds/sssd-7.1-gr-request/ But please note that when POSIX attributes are requested, the lookups will /always/ be slower. With ID mapping, we can do just a single base-scoped lookup to retrieve the multi-valued tokenGroups attribute and map the SIDs to IDs. With POSIX attributes, we must simply go to the server for each group and look up the GID.. From andrew.holway at gmail.com Fri Mar 20 08:20:15 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 20 Mar 2015 09:20:15 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <20150320080028.GA8409@hendrix.redhat.com> References: <5509B1D0.1050602@redhat.com> <20150319092924.GD3591@hendrix.arn.redhat.com> <20150319163309.GQ3591@hendrix.arn.redhat.com> <20150319164610.GS3591@hendrix.arn.redhat.com> <20150320080028.GA8409@hendrix.redhat.com> Message-ID: Actually, I stumbled across this which explains everything you need to do to get sudo working on Centos6 clients. https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html I have had to kind of scratch together bits of information from various sources including this list (thanks!!) but we are trying to do all of this automated with saltstack which is a bit of a challenge. Thanks, Andrew On 20 March 2015 at 09:00, Jakub Hrozek wrote: > On Thu, Mar 19, 2015 at 10:32:08PM +0100, Andrew Holway wrote: > > > > > > > > > I wasn't precise enough, I meant the sssd version, sorry. But given > that > > > you're on RHEL-7, I think you can switch to: > > > sudo_provider=ipa > > > > > > > That does indeed seem to work. Thanks! > > You're welcome, btw if you set up your client using some documentation > we might want to correct those docs.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Mar 20 08:25:04 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Mar 2015 09:25:04 +0100 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: References: <5509CE2D.8080108@redhat.com> <5509F468.2040400@redhat.com> <20150319155704.GA1389@redhat.com> <8B409FD7-FB59-4B6B-91D7-E9053DABFA7D@redhat.com> Message-ID: <20150320082504.GC8409@hendrix.redhat.com> On Thu, Mar 19, 2015 at 05:50:50PM -0400, Prasun Gera wrote: > It's just that /var/lib/sss/db is not cleared between subsequent server > installs and uninstall, and that seems to be creating problems on the > server since the server is also a client. If you do > install-uninstall-install on the server with the same domain name for both > the installs, you cannot authenticate using sssd after the second install. > A simple command like 'ssh admin at localhost' on the server gives permission > denied. I don't know if this is a regression, but it would help if someone > could reproduce this error. I don't think it's such a grave error, but feel free to open a ticket against IPA to remove the database on uninstall.. From dkupka at redhat.com Fri Mar 20 08:37:11 2015 From: dkupka at redhat.com (David Kupka) Date: Fri, 20 Mar 2015 09:37:11 +0100 Subject: [Freeipa-users] Minimum rights to enrol a client In-Reply-To: References: Message-ID: <550BDC37.3080904@redhat.com> On 03/20/2015 09:16 AM, Andrew Holway wrote: > Hello, > > I'd like to find our what the minimum role would be to allow a user to join > a new client to freeipa. > > Currently our enrol command looks like: > ipa-client-install --force-join --enable-dns-updates -U -p admin -w > xxxxxxxx: > > Thanks, > > Andrew > > > Hello! AFAIK there is 'Host Enrollment' privilege created during IPA server installation. You need to create new role and add this privilege to the newly created role. The role can then be assigned to any user or group. User with this privilege have enough permissions to enroll a host to IPA domain. -- David Kupka From jhrozek at redhat.com Fri Mar 20 08:37:47 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Mar 2015 09:37:47 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: References: <5509B1D0.1050602@redhat.com> <20150319092924.GD3591@hendrix.arn.redhat.com> <20150319163309.GQ3591@hendrix.arn.redhat.com> <20150319164610.GS3591@hendrix.arn.redhat.com> <20150320080028.GA8409@hendrix.redhat.com> Message-ID: <20150320083747.GE8409@hendrix.redhat.com> On Fri, Mar 20, 2015 at 09:20:15AM +0100, Andrew Holway wrote: > Actually, I stumbled across this which explains everything you need to do > to get sudo working on Centos6 clients. > https://www.redhat.com/archives/freeipa-users/2013-June/msg00064.html > > I have had to kind of scratch together bits of information from various > sources including this list (thanks!!) but we are trying to do all of this > automated with saltstack which is a bit of a challenge. Ah, right, that's an old post in freeipa's terms :-) We simplified the sudo configuration in 6.6 to the single line that sets sudo_provider to ipa. I'm glad your setup works now. From roberto.cornacchia at gmail.com Fri Mar 20 08:53:55 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 09:53:55 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550B617E.8040103@redhat.com> References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> Message-ID: It seems so: $ firewall-cmd --list-all FedoraServer (default, active) interfaces: em2 sources: services: cockpit dhcpv6-client ssh ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp 9445/tcp 8011/tcp 53/udp 8082/tcp masquerade: no forward-ports: icmp-blocks: rich rules: On 20 March 2015 at 00:53, Dmitri Pal wrote: > On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: > > Yes. > > [root at meson ~]# cat /etc/resolv.conf > search hq.example.com > nameserver 192.168.0.72 > > Sorry from the short log I posted it's not visible, but that ip address > is the address of the ipa server (ipa.hq.example.com) > > [root at meson ~]# dig ipa.hq.spinque.com > > ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com > ;; global options: +cmd > ;; Got answer: > ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238 > ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 > > ;; OPT PSEUDOSECTION: > ; EDNS: version: 0, flags:; udp: 4096 > ;; QUESTION SECTION: > ;ipa.hq.example.com. IN A > > ;; ANSWER SECTION: > ipa.hq.example.com. 1200 IN A 192.168.0.72 > > ;; AUTHORITY SECTION: > hq.example.com. 86400 IN NS ipa.hq.example.com. > > ;; Query time: 1 msec > ;; SERVER: 192.168.0.72#53(192.168.0.72) > ;; WHEN: do mrt 19 22:02:04 CET 2015 > ;; MSG SIZE rcvd: 83 > > > > OK so you can in fact lookup the server. > Have you opened all required ports for ldap and kerberos and other > protocols in the firewall both UDP and TCP? > > > > > On 19 March 2015 at 21:55, Dmitri Pal wrote: > >> On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: >> >> Hi, >> >> This should really work like a charm, and I'm sure it is a stupid >> mistake of mine if it doesn't, but I really can't find out what goes wrong. >> >> Both IPA server and client are on FC21, very up to date. >> Server installation (standard, with dns) worked well. Required ports open >> in the firewall. Everything seems to work. >> >> I did try to use the IPA server as a DNS (with forwarders) and NTP >> server from non-ipa clients, no problem. >> I also tried to use it as LDAP server, from a non-fedora machine (a >> synology). It worked well and I could see users. >> >> When trying to enroll a client, the enrollment itself seems to succeed, >> but: >> - Unable to sync time with NTP server >> - Unable to update DNS >> - Unable to find users >> >> I include below the short installation log (I changed the real domain >> into hq.example.com), and in attachment, the full log with debug on. >> >> From the debug log, about the DNS update failure, I can see this: >> >> ; Communication with 192.168.0.72#53 failed: operation canceled >> could not reach any name server >> >> I'm not sure what communication problem this could be, as the server >> (which is both the IPA and the DNS servers), clearly can be reached. >> >> Any idea where to look at? >> >> >> Do you have the IPA DNS server in the resolv.conf of the client? >> >> >> >> >> Thanks, >> Roberto >> >> >> [root at meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns >> --force-ntpd --hostname=meson.hq.example.com >> Discovery was successful! >> Hostname: meson.hq.example.com >> Realm: HQ.EXAMPLE.COM >> DNS Domain: hq.example.com >> IPA Server: ipa.hq.example.com >> BaseDN: dc=hq,dc=example,dc=com >> >> Continue to configure the system with these values? [no]: yes >> Synchronizing time with KDC... >> *Unable to sync time with IPA NTP server, assuming the time is in sync. >> Please check that 123 UDP port is opened.* >> User authorized to enroll computers: admin >> Password for admin at HQ.EXAMPLE.COM: >> Successfully retrieved CA cert >> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> Valid From: Mon Mar 16 18:44:35 2015 UTC >> Valid Until: Fri Mar 16 18:44:35 2035 UTC >> >> Enrolled in IPA realm HQ.EXAMPLE.COM >> 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 HQ.EXAMPLE.COM >> trying https://ipa.hq.example.com/ipa/json >> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' >> Forwarding 'ca_is_enabled' to json server ' >> https://ipa.hq.example.com/ipa/json' >> Systemwide CA database updated. >> Added CA certificates to the default NSS database. >> Hostname (meson.hq.example.com) not found in DNS >> *Failed to update DNS records.* >> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json >> ' >> *Could not update DNS SSHFP records.* >> SSSD enabled >> Configured /etc/openldap/ldap.conf >> *Unable to find 'admin' user with 'getent passwd admin at hq.example.com >> '!* >> *Unable to reliably detect configuration. Check NSS setup manually.* >> NTP enabled >> Configured /etc/ssh/ssh_config >> Configured /etc/ssh/sshd_config >> Configuring hq.example.com as NIS domain. >> Client configuration complete. >> >> >> >> >> >> -- >> 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. > > > -- > 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 abokovoy at redhat.com Fri Mar 20 08:55:36 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 20 Mar 2015 10:55:36 +0200 Subject: [Freeipa-users] Minimum rights to enrol a client In-Reply-To: <550BDC37.3080904@redhat.com> References: <550BDC37.3080904@redhat.com> Message-ID: <20150320085536.GM3878@redhat.com> On Fri, 20 Mar 2015, David Kupka wrote: >On 03/20/2015 09:16 AM, Andrew Holway wrote: >>Hello, >> >>I'd like to find our what the minimum role would be to allow a user to join >>a new client to freeipa. >> >>Currently our enrol command looks like: >>ipa-client-install --force-join --enable-dns-updates -U -p admin -w >>xxxxxxxx: >> >>Thanks, >> >>Andrew >> >> >> >Hello! > >AFAIK there is 'Host Enrollment' privilege created during IPA server >installation. You need to create new role and add this privilege to >the newly created role. >The role can then be assigned to any user or group. User with this >privilege have enough permissions to enroll a host to IPA domain. That is not a full story. To enroll hosts you have to have 'Host Enrollment' privilege but this privilege does not give you rights to create a host object. Creating hosts is a separate permission ('System: Add Hosts') granted to a separate privilege, 'Host Administrators'. -- / Alexander Bokovoy From prasun.gera at gmail.com Fri Mar 20 09:24:40 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Fri, 20 Mar 2015 05:24:40 -0400 Subject: [Freeipa-users] Problems with ssh and install-uninstall-install sequence on the server In-Reply-To: <20150320082504.GC8409@hendrix.redhat.com> References: <5509CE2D.8080108@redhat.com> <5509F468.2040400@redhat.com> <20150319155704.GA1389@redhat.com> <8B409FD7-FB59-4B6B-91D7-E9053DABFA7D@redhat.com> <20150320082504.GC8409@hendrix.redhat.com> Message-ID: I'll open a ticket. It should probably be cleared, unless handled in some other way, before installs too. This looks like more of a client side issue than a server one. The database should be cleared when a client is explicitly uninstalled, and also if the client tries to register to a different server with the same domain name (in a scenario where the master has been replaced or something similar). I don't know how that is handled, but it could create similar problems. On Fri, Mar 20, 2015 at 4:25 AM, Jakub Hrozek wrote: > On Thu, Mar 19, 2015 at 05:50:50PM -0400, Prasun Gera wrote: > > It's just that /var/lib/sss/db is not cleared between subsequent server > > installs and uninstall, and that seems to be creating problems on the > > server since the server is also a client. If you do > > install-uninstall-install on the server with the same domain name for > both > > the installs, you cannot authenticate using sssd after the second > install. > > A simple command like 'ssh admin at localhost' on the server gives > permission > > denied. I don't know if this is a regression, but it would help if > someone > > could reproduce this error. > > I don't think it's such a grave error, but feel free to open a ticket > against IPA to remove the database on uninstall.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpazdziora at redhat.com Fri Mar 20 10:06:04 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 20 Mar 2015 11:06:04 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <5509B1D0.1050602@redhat.com> References: <5509B1D0.1050602@redhat.com> Message-ID: <20150320100604.GF17619@redhat.com> On Wed, Mar 18, 2015 at 01:11:44PM -0400, Rob Crittenden wrote: > On Wed, Mar 18, 2015 at 17:40:19 +0100, Andrew Holway wrote: > > > > Im wondering how we should be handing SSSD for redundant configurations > > on our freeipa clients. We have three freeipa servers; how can we make > > SSSD check another freeipa in the event that one goes down? > > > > [...] > > > > ipa_server = _srv_, test-freeipa-2.cloud.domain.de > > _srv_ tells SSSD to check DNS for SRV records. The trailing server gives > it a hardcoded fallback in case DNS fails for some reason. Their current > configuration is correct. However, it does not set priority for the preferred IPA server which can be useful if they are in different geos and by default you want the traffic to go to the local server. In that case ipa_server = test-freeipa-2.cloud.domain.de, _srv_ might actually be preferred. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From bobby.prins at proxy.nl Fri Mar 20 10:44:43 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Fri, 20 Mar 2015 11:44:43 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150319171119.GI27609@p.redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> <20150319171119.GI27609@p.redhat.com> Message-ID: <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >> Hi there, >> >> I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup (described here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust was created all seems to work well on the freeIPA server. I can also do a lookup of AD users and groups on an AIX test server. >> >> But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 >> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >> [12299] 1426773524.361880: Produced preauth for next request: 2 >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >> [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 >> [12299] 1426773524.368482: Response was not from master KDC >> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP >> [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >> [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 >> [12299] 1426773524.384237: Response was not from master KDC >> [12299] 1426773524.384263: Processing preauth types: 19 >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >> [12299] 1426773524.384275: Produced preauth for next request: (empty) >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 >> [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB >> [12299] 1426773524.384333: FAST negotiation: unavailable >> [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v >> >> Any ideas? > >Can you log in to the IPA server as this user? If yes I would assume >that the password gets garbled somewhere on the way from AIX through the >IPA machinery to SSSD. Does the password contain some special characters >which some LDAP processing calls might want the escape? > >bye, >Sumit > Yes, I can login with the account on the IPA server without any problems. I tried it with different password to rule out problems with special characters. Finally I did a tcpdump on the IPA server. The AIX server sends the word 'INCORRECT' to the IPA server instead of the password. So I guess I have to do some more configuration checks on the AIX server. >> >> Thanks, >> >> Bobby >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project > >-- >Manage your subscription for the Freeipa-users mailing list: >https://www.redhat.com/mailman/listinfo/freeipa-users >Go to http://freeipa.org for more info on the project From sbose at redhat.com Fri Mar 20 10:51:09 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 20 Mar 2015 11:51:09 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> <20150319171119.GI27609@p.redhat.com> <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> Message-ID: <20150320105109.GQ27609@p.redhat.com> On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote: > On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: > >> Hi there, > >> > >> I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup (described here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust was created all seems to work well on the freeIPA server. I can also do a lookup of AD users and groups on an AIX test server. > >> > >> But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] > >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 > >> > >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': > >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 > >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 > >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success > >> [12299] 1426773524.361880: Produced preauth for next request: 2 > >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP > >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. > >> [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 > >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 > >> [12299] 1426773524.368482: Response was not from master KDC > >> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP > >> [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP > >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) > >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. > >> [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 > >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 > >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 > >> [12299] 1426773524.384237: Response was not from master KDC > >> [12299] 1426773524.384263: Processing preauth types: 19 > >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" > >> [12299] 1426773524.384275: Produced preauth for next request: (empty) > >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 > >> [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB > >> [12299] 1426773524.384333: FAST negotiation: unavailable > >> [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP > >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v > >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v > >> [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 > >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v > >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v > >> > >> Any ideas? > > > >Can you log in to the IPA server as this user? If yes I would assume > >that the password gets garbled somewhere on the way from AIX through the > >IPA machinery to SSSD. Does the password contain some special characters > >which some LDAP processing calls might want the escape? > > > >bye, > >Sumit > > > Yes, I can login with the account on the IPA server without any problems. I tried it with different password to rule out problems with special characters. Finally I did a tcpdump on the IPA server. The AIX server sends the word 'INCORRECT' to the IPA server instead of the password. So I guess I have to do some more configuration checks on the AIX server. Thank you for the feedback. Just a wild guess, since you were able to see anything in the tcpdump I guess an unencrypted connection is used. Maybe AIX prevents that the password is send via a clear text connection? bye, Sumit > >> > >> Thanks, > >> > >> Bobby > >> > >> -- > >> Manage your subscription for the Freeipa-users mailing list: > >> https://www.redhat.com/mailman/listinfo/freeipa-users > >> Go to http://freeipa.org for more info on the project > > > >-- > >Manage your subscription for the Freeipa-users mailing list: > >https://www.redhat.com/mailman/listinfo/freeipa-users > >Go to http://freeipa.org for more info on the project From jhrozek at redhat.com Fri Mar 20 10:51:14 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Mar 2015 11:51:14 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <20150320100604.GF17619@redhat.com> References: <5509B1D0.1050602@redhat.com> <20150320100604.GF17619@redhat.com> Message-ID: <20150320105114.GJ8409@hendrix.redhat.com> On Fri, Mar 20, 2015 at 11:06:04AM +0100, Jan Pazdziora wrote: > On Wed, Mar 18, 2015 at 01:11:44PM -0400, Rob Crittenden wrote: > > On Wed, Mar 18, 2015 at 17:40:19 +0100, Andrew Holway wrote: > > > > > > Im wondering how we should be handing SSSD for redundant configurations > > > on our freeipa clients. We have three freeipa servers; how can we make > > > SSSD check another freeipa in the event that one goes down? > > > > > > [...] > > > > > > ipa_server = _srv_, test-freeipa-2.cloud.domain.de > > > > _srv_ tells SSSD to check DNS for SRV records. The trailing server gives > > it a hardcoded fallback in case DNS fails for some reason. Their current > > configuration is correct. > > However, it does not set priority for the preferred IPA server which > can be useful if they are in different geos and by default you want > the traffic to go to the local server. In that case > > ipa_server = test-freeipa-2.cloud.domain.de, _srv_ > > might actually be preferred. Or even better, set the weight and priority fields on the server and keep using SRV resolution :-) From abokovoy at redhat.com Fri Mar 20 11:10:50 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 20 Mar 2015 13:10:50 +0200 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150320105109.GQ27609@p.redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> <20150319171119.GI27609@p.redhat.com> <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> Message-ID: <20150320111050.GN3878@redhat.com> On Fri, 20 Mar 2015, Sumit Bose wrote: >On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote: >> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >> >> Hi there, >> >> >> >> I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup (described here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust was created all seems to work well on the freeIPA server. I can also do a lookup of AD users and groups on an AIX test server. >> >> >> >> But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] >> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 >> >> >> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': >> >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 >> >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >> >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >> >> [12299] 1426773524.361880: Produced preauth for next request: 2 >> >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP >> >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >> >> [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 >> >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 >> >> [12299] 1426773524.368482: Response was not from master KDC >> >> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP >> >> [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP >> >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) >> >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >> >> [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 >> >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 >> >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 >> >> [12299] 1426773524.384237: Response was not from master KDC >> >> [12299] 1426773524.384263: Processing preauth types: 19 >> >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >> >> [12299] 1426773524.384275: Produced preauth for next request: (empty) >> >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 >> >> [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB >> >> [12299] 1426773524.384333: FAST negotiation: unavailable >> >> [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP >> >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v >> >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v >> >> [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 >> >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v >> >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v >> >> >> >> Any ideas? >> > >> >Can you log in to the IPA server as this user? If yes I would assume >> >that the password gets garbled somewhere on the way from AIX through the >> >IPA machinery to SSSD. Does the password contain some special characters >> >which some LDAP processing calls might want the escape? >> > >> >bye, >> >Sumit >> > >> Yes, I can login with the account on the IPA server without any problems. I tried it with different password to rule out problems with special characters. Finally I did a tcpdump on the IPA server. The AIX server sends the word 'INCORRECT' to the IPA server instead of the password. So I guess I have to do some more configuration checks on the AIX server. > >Thank you for the feedback. > >Just a wild guess, since you were able to see anything in the tcpdump I >guess an unencrypted connection is used. Maybe AIX prevents that the >password is send via a clear text connection? It is openssh behavior. It sends INCORRECT line as part of the password when there is no valid shell for that user to login. OpenSSH validates content of 'struct passwd' returned for the user, including checks on whether shell is there as an executable file. This check fails and user is considered 'invalid'. Still, OpenSSH competes PAM authentication, making sure the password field is filled with specially constructed string "\b\n\r\177INCORRECT", to ensure there is registered failed login attempt. -- / Alexander Bokovoy From mbasti at redhat.com Fri Mar 20 11:31:37 2015 From: mbasti at redhat.com (Martin Basti) Date: Fri, 20 Mar 2015 12:31:37 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> Message-ID: <550C0519.1040609@redhat.com> Hello, do you have enabled DNS dynamic updates for hq.example.zone? You can check it in zone settings. Are there any log entries in dns log related to nsupdate executed from a client? $ journalctl -b -u named-pkcs11 On 20/03/15 09:53, Roberto Cornacchia wrote: > It seems so: > > $ firewall-cmd --list-all > FedoraServer (default, active) > interfaces: em2 > sources: > services: cockpit dhcpv6-client ssh > ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp > 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp > 9444/tcp 9445/tcp 8011/tcp 53/udp 8082/tcp > masquerade: no > forward-ports: > icmp-blocks: > rich rules: > > > On 20 March 2015 at 00:53, Dmitri Pal > wrote: > > On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: >> Yes. >> >> [root at meson ~]# cat /etc/resolv.conf >> search hq.example.com >> nameserver 192.168.0.72 >> >> Sorry from the short log I posted it's not visible, but that ip >> address is the address of the ipa server (ipa.hq.example.com >> ) >> >> [root at meson ~]# dig ipa.hq.spinque.com >> >> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> >> ipa.hq.example.com >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, >> ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;ipa.hq.example.com.INA >> >> ;; ANSWER SECTION: >> ipa.hq.example.com. 1200INA192.168.0.72 >> >> ;; AUTHORITY SECTION: >> hq.example.com.86400INNSipa.hq.example.com. >> >> ;; Query time: 1 msec >> ;; SERVER: 192.168.0.72#53(192.168.0.72) >> ;; WHEN: do mrt 19 22:02:04 CET 2015 >> ;; MSG SIZE rcvd: 83 > > > OK so you can in fact lookup the server. > Have you opened all required ports for ldap and kerberos and other > protocols in the firewall both UDP and TCP? > > >> >> >> On 19 March 2015 at 21:55, Dmitri Pal > > wrote: >> >> On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: >>> Hi, >>> >>> This should really work like a charm, and I'm sure it is a >>> stupid mistake of mine if it doesn't, but I really can't >>> find out what goes wrong. >>> >>> Both IPA server and client are on FC21, very up to date. >>> Server installation (standard, with dns) worked well. >>> Required ports open in the firewall. Everything seems to work. >>> >>> I did try to use the IPA server as a DNS (with forwarders) >>> and NTP server from non-ipa clients, no problem. >>> I also tried to use it as LDAP server, from a non-fedora >>> machine (a synology). It worked well and I could see users. >>> >>> When trying to enroll a client, the enrollment itself seems >>> to succeed, but: >>> - Unable to sync time with NTP server >>> - Unable to update DNS >>> - Unable to find users >>> >>> I include below the short installation log (I changed the >>> real domain into hq.example.com ), >>> and in attachment, the full log with debug on. >>> >>> From the debug log, about the DNS update failure, I can see >>> this: >>> >>> ; Communication with 192.168.0.72#53 failed: operation >>> canceled >>> could not reach any name server >>> >>> I'm not sure what communication problem this could be, as >>> the server (which is both the IPA and the DNS servers), >>> clearly can be reached. >>> >>> Any idea where to look at? >> >> Do you have the IPA DNS server in the resolv.conf of the client? >> >> >> >>> >>> Thanks, >>> Roberto >>> >>> >>> [root at meson ~]# ipa-client-install --mkhomedir >>> --ssh-trust-dns --force-ntpd --hostname=meson.hq.example.com >>> >>> Discovery was successful! >>> Hostname: meson.hq.example.com >>> Realm: HQ.EXAMPLE.COM >>> DNS Domain: hq.example.com >>> IPA Server: ipa.hq.example.com >>> BaseDN: dc=hq,dc=example,dc=com >>> >>> Continue to configure the system with these values? [no]: yes >>> Synchronizing time with KDC... >>> *Unable to sync time with IPA NTP server, assuming the time >>> is in sync. Please check that 123 UDP port is opened.* >>> User authorized to enroll computers: admin >>> Password for admin at HQ.EXAMPLE.COM >>> : >>> Successfully retrieved CA cert >>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>> >>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>> >>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>> >>> Enrolled in IPA realm HQ.EXAMPLE.COM >>> 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 HQ.EXAMPLE.COM >>> >>> trying https://ipa.hq.example.com/ipa/json >>> Forwarding 'ping' to json server >>> 'https://ipa.hq.example.com/ipa/json' >>> Forwarding 'ca_is_enabled' to json server >>> 'https://ipa.hq.example.com/ipa/json' >>> Systemwide CA database updated. >>> Added CA certificates to the default NSS database. >>> Hostname (meson.hq.example.com >>> ) not found in DNS >>> *Failed to update DNS records.* >>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>> Forwarding 'host_mod' to json server >>> 'https://ipa.hq.example.com/ipa/json' >>> *Could not update DNS SSHFP records.* >>> SSSD enabled >>> Configured /etc/openldap/ldap.conf >>> *Unable to find 'admin' user with 'getent passwd >>> admin at hq.example.com '!* >>> *Unable to reliably detect configuration. Check NSS setup >>> manually.* >>> NTP enabled >>> Configured /etc/ssh/ssh_config >>> Configured /etc/ssh/sshd_config >>> Configuring hq.example.com as NIS >>> domain. >>> Client configuration complete. >>> >>> >>> >> >> >> -- >> 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. > > > -- > 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 > > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobby.prins at proxy.nl Fri Mar 20 11:38:47 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Fri, 20 Mar 2015 12:38:47 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150320111050.GN3878@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> <20150319171119.GI27609@p.redhat.com> <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> <20150320111050.GN3878@redhat.com> Message-ID: <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> >On Fri, 20 Mar 2015, Sumit Bose wrote: >>On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote: >>> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >>> >> Hi there, >>> >> >>> >> I'm currently trying to use the 'AD Trust for Legacy Clients' freeIPA setup (described here: http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) to be able to autenticate AIX 7.1 clients against an AD domain using LDAP. After the trust was created all seems to work well on the freeIPA server. I can also do a lookup of AD users and groups on an AIX test server. >>> >> >>> >> But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] >>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 >>> >> >>> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': >>> >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 >>> >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >>> >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >>> >> [12299] 1426773524.361880: Produced preauth for next request: 2 >>> >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP >>> >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >>> >> [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 >>> >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 >>> >> [12299] 1426773524.368482: Response was not from master KDC >>> >> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP >>> >> [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP >>> >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) >>> >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >>> >> [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 >>> >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 >>> >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 >>> >> [12299] 1426773524.384237: Response was not from master KDC >>> >> [12299] 1426773524.384263: Processing preauth types: 19 >>> >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >>> >> [12299] 1426773524.384275: Produced preauth for next request: (empty) >>> >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 >>> >> [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB >>> >> [12299] 1426773524.384333: FAST negotiation: unavailable >>> >> [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP >>> >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v >>> >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v >>> >> [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 >>> >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v >>> >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v >>> >> >>> >> Any ideas? >>> > >>> >Can you log in to the IPA server as this user? If yes I would assume >>> >that the password gets garbled somewhere on the way from AIX through the >>> >IPA machinery to SSSD. Does the password contain some special characters >>> >which some LDAP processing calls might want the escape? >>> > >>> >bye, >>> >Sumit >>> > >>> Yes, I can login with the account on the IPA server without any problems. I tried it with different password to rule out problems with special characters. Finally I did a tcpdump on the IPA server. The AIX server sends the word 'INCORRECT' to the IPA server instead of the password. So I guess I have to do some more configuration checks on the AIX server. >> >>Thank you for the feedback. >> >>Just a wild guess, since you were able to see anything in the tcpdump I >>guess an unencrypted connection is used. Maybe AIX prevents that the >>password is send via a clear text connection? >It is openssh behavior. It sends INCORRECT line as part of the password >when there is no valid shell for that user to login. > >OpenSSH validates content of 'struct passwd' returned for the user, >including checks on whether shell is there as an executable file. This >check fails and user is considered 'invalid'. Still, OpenSSH competes >PAM authentication, making sure the password field is filled with >specially constructed string "\b\n\r\177INCORRECT", to ensure there is >registered failed login attempt. > >-- >/ Alexander Bokovoy Wow, thanks for that! If I do a lsuser/ldapsearch on the AIX host the shell/loginShell is missing for AD users. The admin IPA user has this attribute set and I can log in with that account. Can this be solved on the IPA server? From jpazdziora at redhat.com Fri Mar 20 12:02:58 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Fri, 20 Mar 2015 13:02:58 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <20150320105114.GJ8409@hendrix.redhat.com> References: <5509B1D0.1050602@redhat.com> <20150320100604.GF17619@redhat.com> <20150320105114.GJ8409@hendrix.redhat.com> Message-ID: <20150320120258.GG17619@redhat.com> On Fri, Mar 20, 2015 at 11:51:14AM +0100, Jakub Hrozek wrote: > > Or even better, set the weight and priority fields on the server and > keep using SRV resolution :-) How do you specify different priorities for different consumers if the DNS is IPA-based (== the records are in LDAP and replicated)? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From abokovoy at redhat.com Fri Mar 20 12:05:00 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 20 Mar 2015 14:05:00 +0200 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> <20150319171119.GI27609@p.redhat.com> <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> <20150320111050.GN3878@redhat.com> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> Message-ID: <20150320120500.GO3878@redhat.com> On Fri, 20 Mar 2015, Bobby Prins wrote: >>On Fri, 20 Mar 2015, Sumit Bose wrote: >>>On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote: >>>> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >>>> >> Hi there, >>>> >> >>>> >> I'm currently trying to use the 'AD Trust for Legacy Clients' >>>> >> freeIPA setup (described here: >>>> >> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) >>>> >> to be able to autenticate AIX 7.1 clients against an AD domain >>>> >> using LDAP. After the trust was created all seems to work well >>>> >> on the freeIPA server. I can also do a lookup of AD users and >>>> >> groups on an AIX test server. >>>> >> >>>> >> But as soon as I want to log in on the AIX system I get an SSSD error on the freeIPA server in krb5_child.log (debug_level = 10): >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS key obtained for encrypted timestamp: aes256-cts/2F5D >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: Encrypted timestamp (for 1426778442.525165): plain 301AA011180F32303135303331393135323034325AA105020308036D, encrypted 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: Produced preauth for next request: 2 >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: Sending request (238 bytes) to EXAMPLE.CORP >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: Resolving hostname dct020.example.corp. >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: Sending initial UDP request to dgram 192.168.143.1:88 >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: Received answer from dgram 192.168.143.1:88 >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: Response was not from master KDC >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: Received error from KDC: -1765328360/Preauthentication failed >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: Preauth tryagain input types: 16, 14, 19, 2 >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: Retrying AS request with master KDC >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: Getting initial credentials for BPrins at EXAMPLE.CORP >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: Sending request (160 bytes) to EXAMPLE.CORP (master) >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication failed] >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication failed] >>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] [k5c_send_data] (0x0200): Received error code 1432158214 >>>> >> >>>> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit BPrins at EXAMPLE.CORP': >>>> >> [12299] 1426773524.361785: AS key obtained for encrypted timestamp: aes256-cts/B997 >>>> >> [12299] 1426773524.361850: Encrypted timestamp (for 1426773524.277583): plain 301AA011180F32303135303331393133353834345AA1050203043C4F, encrypted ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >>>> >> [12299] 1426773524.361876: Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >>>> >> [12299] 1426773524.361880: Produced preauth for next request: 2 >>>> >> [12299] 1426773524.361901: Sending request (238 bytes) to EXAMPLE.CORP >>>> >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >>>> >> [12299] 1426773524.363841: Sending initial UDP request to dgram 192.168.141.1:88 >>>> >> [12299] 1426773524.368089: Received answer from dgram 192.168.141.1:88 >>>> >> [12299] 1426773524.368482: Response was not from master KDC >>>> >> [12299] 1426773524.368500: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP >>>> >> [12299] 1426773524.368506: Request or response is too big for UDP; retrying with TCP >>>> >> [12299] 1426773524.368511: Sending request (238 bytes) to EXAMPLE.CORP (tcp only) >>>> >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >>>> >> [12299] 1426773524.370056: Initiating TCP connection to stream 192.168.143.5:88 >>>> >> [12299] 1426773524.375140: Sending TCP request to stream 192.168.143.5:88 >>>> >> [12299] 1426773524.383801: Received answer from stream 192.168.143.5:88 >>>> >> [12299] 1426773524.384237: Response was not from master KDC >>>> >> [12299] 1426773524.384263: Processing preauth types: 19 >>>> >> [12299] 1426773524.384271: Selected etype info: etype aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >>>> >> [12299] 1426773524.384275: Produced preauth for next request: (empty) >>>> >> [12299] 1426773524.384282: AS key determined by preauth: aes256-cts/B997 >>>> >> [12299] 1426773524.384329: Decrypted AS reply; session key is: rc4-hmac/39AB >>>> >> [12299] 1426773524.384333: FAST negotiation: unavailable >>>> >> [12299] 1426773524.384357: Initializing KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ BPrins at EXAMPLE.CORP >>>> >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from KEYRING:persistent:0:krb_ccache_rhX3V4v >>>> >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in KEYRING:persistent:0:krb_ccache_rhX3V4v >>>> >> [12299] 1426773524.384469: Storing config in KEYRING:persistent:0:krb_ccache_rhX3V4v for krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 >>>> >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: from KEYRING:persistent:0:krb_ccache_rhX3V4v >>>> >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: in KEYRING:persistent:0:krb_ccache_rhX3V4v >>>> >> >>>> >> Any ideas? >>>> > >>>> >Can you log in to the IPA server as this user? If yes I would assume >>>> >that the password gets garbled somewhere on the way from AIX through the >>>> >IPA machinery to SSSD. Does the password contain some special characters >>>> >which some LDAP processing calls might want the escape? >>>> > >>>> >bye, >>>> >Sumit >>>> > >>>> Yes, I can login with the account on the IPA server without any >>>> problems. I tried it with different password to rule out problems >>>> with special characters. Finally I did a tcpdump on the IPA server. >>>> The AIX server sends the word 'INCORRECT' to the IPA server instead >>>> of the password. So I guess I have to do some more configuration >>>> checks on the AIX server. >>> >>>Thank you for the feedback. >>> >>>Just a wild guess, since you were able to see anything in the tcpdump I >>>guess an unencrypted connection is used. Maybe AIX prevents that the >>>password is send via a clear text connection? >>It is openssh behavior. It sends INCORRECT line as part of the password >>when there is no valid shell for that user to login. >> >>OpenSSH validates content of 'struct passwd' returned for the user, >>including checks on whether shell is there as an executable file. This >>check fails and user is considered 'invalid'. Still, OpenSSH competes >>PAM authentication, making sure the password field is filled with >>specially constructed string "\b\n\r\177INCORRECT", to ensure there is >>registered failed login attempt. >Wow, thanks for that! If I do a lsuser/ldapsearch on the AIX host the >shell/loginShell is missing for AD users. The admin IPA user has this >attribute set and I can log in with that account. Can this be solved on >the IPA server? In FreeIPA 4.1 (Fedora 21+ or RHEL7.1) you can do set shell separately for each AD user using ID Views: ipa idoverrideuser-add 'Default Trust View' 'AD\User' --shell /bin/ksh Compat tree and SSSD on RHEL7.1/Fedora21 should take default trust view into account for AD users. -- / Alexander Bokovoy From jhrozek at redhat.com Fri Mar 20 12:13:55 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Mar 2015 13:13:55 +0100 Subject: [Freeipa-users] SSSD in redundant configuration In-Reply-To: <20150320120258.GG17619@redhat.com> References: <5509B1D0.1050602@redhat.com> <20150320100604.GF17619@redhat.com> <20150320105114.GJ8409@hendrix.redhat.com> <20150320120258.GG17619@redhat.com> Message-ID: <20150320121355.GN8409@hendrix.redhat.com> On Fri, Mar 20, 2015 at 01:02:58PM +0100, Jan Pazdziora wrote: > On Fri, Mar 20, 2015 at 11:51:14AM +0100, Jakub Hrozek wrote: > > > > Or even better, set the weight and priority fields on the server and > > keep using SRV resolution :-) > > How do you specify different priorities for different consumers if > the DNS is IPA-based (== the records are in LDAP and replicated)? Ah, for different consumers..not sure currently. Maybe Petr Spacek has some idea, but then I think your approach makes sense. From dpal at redhat.com Fri Mar 20 13:33:03 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 09:33:03 -0400 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150320120500.GO3878@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <249254706.522174.1426780004932.JavaMail.zimbra@proxy.nl> <20150319171119.GI27609@p.redhat.com> <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> <20150320111050.GN3878@redhat.com> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> Message-ID: <550C218F.2000907@redhat.com> On 03/20/2015 08:05 AM, Alexander Bokovoy wrote: > On Fri, 20 Mar 2015, Bobby Prins wrote: >>> On Fri, 20 Mar 2015, Sumit Bose wrote: >>>> On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote: >>>>> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >>>>> >> Hi there, >>>>> >> >>>>> >> I'm currently trying to use the 'AD Trust for Legacy Clients' >>>>> >> freeIPA setup (described here: >>>>> >> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) >>>>> >> to be able to autenticate AIX 7.1 clients against an AD domain >>>>> >> using LDAP. After the trust was created all seems to work well >>>>> >> on the freeIPA server. I can also do a lookup of AD users and >>>>> >> groups on an AIX test server. >>>>> >> >>>>> >> But as soon as I want to log in on the AIX system I get an SSSD >>>>> error on the freeIPA server in krb5_child.log (debug_level = 10): >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS >>>>> key obtained for encrypted timestamp: aes256-cts/2F5D >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: >>>>> Encrypted timestamp (for 1426778442.525165): plain >>>>> 301AA011180F32303135303331393135323034325AA105020308036D, >>>>> encrypted >>>>> 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: >>>>> Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: >>>>> Produced preauth for next request: 2 >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: >>>>> Sending request (238 bytes) to EXAMPLE.CORP >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: >>>>> Resolving hostname dct020.example.corp. >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: >>>>> Sending initial UDP request to dgram 192.168.143.1:88 >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: >>>>> Received answer from dgram 192.168.143.1:88 >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: >>>>> Response was not from master KDC >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: >>>>> Received error from KDC: -1765328360/Preauthentication failed >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: >>>>> Preauth tryagain input types: 16, 14, 19, 2 >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: >>>>> Retrying AS request with master KDC >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: >>>>> Getting initial credentials for BPrins at EXAMPLE.CORP >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: >>>>> Sending request (160 bytes) to EXAMPLE.CORP (master) >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication >>>>> failed] >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication >>>>> failed] >>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>> [k5c_send_data] (0x0200): Received error code 1432158214 >>>>> >> >>>>> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit >>>>> BPrins at EXAMPLE.CORP': >>>>> >> [12299] 1426773524.361785: AS key obtained for encrypted >>>>> timestamp: aes256-cts/B997 >>>>> >> [12299] 1426773524.361850: Encrypted timestamp (for >>>>> 1426773524.277583): plain >>>>> 301AA011180F32303135303331393133353834345AA1050203043C4F, >>>>> encrypted >>>>> ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >>>>> >> [12299] 1426773524.361876: Preauth module encrypted_timestamp >>>>> (2) (flags=1) returned: 0/Success >>>>> >> [12299] 1426773524.361880: Produced preauth for next request: 2 >>>>> >> [12299] 1426773524.361901: Sending request (238 bytes) to >>>>> EXAMPLE.CORP >>>>> >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >>>>> >> [12299] 1426773524.363841: Sending initial UDP request to dgram >>>>> 192.168.141.1:88 >>>>> >> [12299] 1426773524.368089: Received answer from dgram >>>>> 192.168.141.1:88 >>>>> >> [12299] 1426773524.368482: Response was not from master KDC >>>>> >> [12299] 1426773524.368500: Received error from KDC: >>>>> -1765328332/Response too big for UDP, retry with TCP >>>>> >> [12299] 1426773524.368506: Request or response is too big for >>>>> UDP; retrying with TCP >>>>> >> [12299] 1426773524.368511: Sending request (238 bytes) to >>>>> EXAMPLE.CORP (tcp only) >>>>> >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >>>>> >> [12299] 1426773524.370056: Initiating TCP connection to stream >>>>> 192.168.143.5:88 >>>>> >> [12299] 1426773524.375140: Sending TCP request to stream >>>>> 192.168.143.5:88 >>>>> >> [12299] 1426773524.383801: Received answer from stream >>>>> 192.168.143.5:88 >>>>> >> [12299] 1426773524.384237: Response was not from master KDC >>>>> >> [12299] 1426773524.384263: Processing preauth types: 19 >>>>> >> [12299] 1426773524.384271: Selected etype info: etype >>>>> aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >>>>> >> [12299] 1426773524.384275: Produced preauth for next request: >>>>> (empty) >>>>> >> [12299] 1426773524.384282: AS key determined by preauth: >>>>> aes256-cts/B997 >>>>> >> [12299] 1426773524.384329: Decrypted AS reply; session key is: >>>>> rc4-hmac/39AB >>>>> >> [12299] 1426773524.384333: FAST negotiation: unavailable >>>>> >> [12299] 1426773524.384357: Initializing >>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ >>>>> BPrins at EXAMPLE.CORP >>>>> >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> >>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from >>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>> >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> >>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in >>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>> >> [12299] 1426773524.384469: Storing config in >>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v for >>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 >>>>> >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> >>>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: >>>>> from KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>> >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> >>>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: >>>>> in KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>> >> >>>>> >> Any ideas? >>>>> > >>>>> >Can you log in to the IPA server as this user? If yes I would assume >>>>> >that the password gets garbled somewhere on the way from AIX >>>>> through the >>>>> >IPA machinery to SSSD. Does the password contain some special >>>>> characters >>>>> >which some LDAP processing calls might want the escape? >>>>> > >>>>> >bye, >>>>> >Sumit >>>>> > >>>>> Yes, I can login with the account on the IPA server without any >>>>> problems. I tried it with different password to rule out problems >>>>> with special characters. Finally I did a tcpdump on the IPA server. >>>>> The AIX server sends the word 'INCORRECT' to the IPA server instead >>>>> of the password. So I guess I have to do some more configuration >>>>> checks on the AIX server. >>>> >>>> Thank you for the feedback. >>>> >>>> Just a wild guess, since you were able to see anything in the >>>> tcpdump I >>>> guess an unencrypted connection is used. Maybe AIX prevents that the >>>> password is send via a clear text connection? >>> It is openssh behavior. It sends INCORRECT line as part of the password >>> when there is no valid shell for that user to login. >>> >>> OpenSSH validates content of 'struct passwd' returned for the user, >>> including checks on whether shell is there as an executable file. This >>> check fails and user is considered 'invalid'. Still, OpenSSH competes >>> PAM authentication, making sure the password field is filled with >>> specially constructed string "\b\n\r\177INCORRECT", to ensure there is >>> registered failed login attempt. >> Wow, thanks for that! If I do a lsuser/ldapsearch on the AIX host the >> shell/loginShell is missing for AD users. The admin IPA user has this >> attribute set and I can log in with that account. Can this be solved on >> the IPA server? > In FreeIPA 4.1 (Fedora 21+ or RHEL7.1) you can do set shell separately > for each AD user using ID Views: > > ipa idoverrideuser-add 'Default Trust View' 'AD\User' --shell /bin/ksh > > Compat tree and SSSD on RHEL7.1/Fedora21 should take default trust view > into account for AD users. > Once we are out of the woods here it would be really nice to have a blog or a wiki page about how to configure AIX clients properly to leverage trusts including this interesting aspect related to the shell. Bobby would you be able to share this information? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From Joshua.Gould at osumc.edu Fri Mar 20 13:41:08 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Fri, 20 Mar 2015 09:41:08 -0400 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX In-Reply-To: <20150320081858.GB8409@hendrix.redhat.com> References: <20150319152348.GL3591@hendrix.arn.redhat.com> <8B69617A-9B4B-4FF6-A9B4-ACEFBE1E2A80@redhat.com> <20150320081858.GB8409@hendrix.redhat.com> Message-ID: Updated: libipa_hbac.x86_64 0:1.12.2-58.el7_1.6.1 libipa_hbac-python.x86_64 0:1.12.2-58.el7_1.6.1 libsss_idmap.x86_64 0:1.12.2-58.el7_1.6.1 libsss_nss_idmap.x86_64 0:1.12.2-58.el7_1.6.1 libsss_nss_idmap-python.x86_64 0:1.12.2-58.el7_1.6.1 python-sssdconfig.noarch 0:1.12.2-58.el7_1.6.1 sssd.x86_64 0:1.12.2-58.el7_1.6.1 sssd-ad.x86_64 0:1.12.2-58.el7_1.6.1 sssd-client.x86_64 0:1.12.2-58.el7_1.6.1 sssd-common.x86_64 0:1.12.2-58.el7_1.6.1 sssd-common-pac.x86_64 0:1.12.2-58.el7_1.6.1 sssd-ipa.x86_64 0:1.12.2-58.el7_1.6.1 sssd-krb5.x86_64 0:1.12.2-58.el7_1.6.1 sssd-krb5-common.x86_64 0:1.12.2-58.el7_1.6.1 sssd-ldap.x86_64 0:1.12.2-58.el7_1.6.1 sssd-proxy.x86_64 0:1.12.2-58.el7_1.6.1 sssd-tools.x86_64 0:1.12.2-58.el7_1.6.1 It?s dramatically faster. Thank you! Mar 20 09:38:46 mid-ipa-vp01 sshd[3081]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.234.49.39 user=gould Mar 20 09:38:46 mid-ipa-vp01 sshd[3081]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=10.234.49.39 user=gould Mar 20 09:38:48 mid-ipa-vp01 sshd[3081]: Accepted password for gould from 10.134.249.39 port 60170 ssh2 Mar 20 09:38:48 mid-ipa-vp01 sshd[3081]: pam_unix(sshd:session): session opened for user gould by (uid=0) On 3/20/15, 4:18 AM, "Jakub Hrozek" wrote: >On Thu, Mar 19, 2015 at 05:29:39PM -0400, Gould, Joshua wrote: >> Thank you! > >You're welcome, please try these builds: >https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople. >org_sssd-2Dtest-2Dbuilds_sssd-2D7.1-2Dgr-2Drequest_&d=AwIBAg&c=k9MF1d71ITt >kuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwo >jC24&m=Q_JEJ-95yaJpaXtkuLwVxfpPN9Dm_PXXZhd4bG1d0ZY&s=6dKxT6QZrN5FoquwdwM62 >Y4GJFQ6QqWn6Y6aGj4CXIc&e= > >But please note that when POSIX attributes are requested, the lookups >will /always/ be slower. With ID mapping, we can do just a single >base-scoped lookup to retrieve the multi-valued tokenGroups attribute >and map the SIDs to IDs. With POSIX attributes, we must simply go to the >server for each group and look up the GID.. From jhrozek at redhat.com Fri Mar 20 14:34:08 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Mar 2015 15:34:08 +0100 Subject: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX In-Reply-To: References: <20150319152348.GL3591@hendrix.arn.redhat.com> <8B69617A-9B4B-4FF6-A9B4-ACEFBE1E2A80@redhat.com> <20150320081858.GB8409@hendrix.redhat.com> Message-ID: <20150320143408.GT8409@hendrix.redhat.com> On Fri, Mar 20, 2015 at 09:41:08AM -0400, Gould, Joshua wrote: > Updated: > libipa_hbac.x86_64 0:1.12.2-58.el7_1.6.1 > libipa_hbac-python.x86_64 0:1.12.2-58.el7_1.6.1 > libsss_idmap.x86_64 0:1.12.2-58.el7_1.6.1 > libsss_nss_idmap.x86_64 0:1.12.2-58.el7_1.6.1 > libsss_nss_idmap-python.x86_64 0:1.12.2-58.el7_1.6.1 > python-sssdconfig.noarch 0:1.12.2-58.el7_1.6.1 > sssd.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-ad.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-client.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-common.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-common-pac.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-ipa.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-krb5.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-krb5-common.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-ldap.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-proxy.x86_64 0:1.12.2-58.el7_1.6.1 > sssd-tools.x86_64 0:1.12.2-58.el7_1.6.1 > > > It?s dramatically faster. Thank you! Thank Sumit who identified the issue and wrote the patch :-) btw if you have a RHEL subscription, it would be nice to open a customer case so that it's easier for us to include the patch in RHEL given customer testing experience. You can send the RHEL customer case number to me. > > Mar 20 09:38:46 mid-ipa-vp01 sshd[3081]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.234.49.39 user=gould > Mar 20 09:38:46 mid-ipa-vp01 sshd[3081]: pam_sss(sshd:auth): > authentication success; logname= uid=0 euid=0 tty=ssh ruser= > rhost=10.234.49.39 user=gould > Mar 20 09:38:48 mid-ipa-vp01 sshd[3081]: Accepted password for gould from > 10.134.249.39 port 60170 ssh2 > Mar 20 09:38:48 mid-ipa-vp01 sshd[3081]: pam_unix(sshd:session): session > opened for user gould by (uid=0) > > > > On 3/20/15, 4:18 AM, "Jakub Hrozek" wrote: > > >On Thu, Mar 19, 2015 at 05:29:39PM -0400, Gould, Joshua wrote: > >> Thank you! > > > >You're welcome, please try these builds: > >https://urldefense.proofpoint.com/v2/url?u=https-3A__jhrozek.fedorapeople. > >org_sssd-2Dtest-2Dbuilds_sssd-2D7.1-2Dgr-2Drequest_&d=AwIBAg&c=k9MF1d71ITt > >kuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwo > >jC24&m=Q_JEJ-95yaJpaXtkuLwVxfpPN9Dm_PXXZhd4bG1d0ZY&s=6dKxT6QZrN5FoquwdwM62 > >Y4GJFQ6QqWn6Y6aGj4CXIc&e= > > > >But please note that when POSIX attributes are requested, the lookups > >will /always/ be slower. With ID mapping, we can do just a single > >base-scoped lookup to retrieve the multi-valued tokenGroups attribute > >and map the SIDs to IDs. With POSIX attributes, we must simply go to the > >server for each group and look up the GID.. > > From rcritten at redhat.com Fri Mar 20 14:39:00 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Mar 2015 10:39:00 -0400 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> Message-ID: <550C3104.5050500@redhat.com> Matt . wrote: > The right way to sequest a SAN, this seems to need some extra config file ? Like I said before, use certmonger, it makes life easier. I'll create a new host balancer.example.com with a HTTP service. I'll generate a cert with a SAN for idp.example.com in that service. I'm generating the cert on idp.example.com, hence the service-add-host bit. On 4.1 (freeipa-server-4.1.3-2.fc22.x86_64) # kinit admin # ipa host-add balancer.example.com # ipa service-add HTTP/balancer.example.com --force # ipa service-add-host --hosts=idp.example.com HTTP/balancer.example.com # ipa-getcert request -f /etc/pki/tls/certs/balancer.pem -k /etc/pki/tls/private/balancer.key -N CN=balancer.example.com -K HTTP/balancer.example.com -D idp.example.com # getcert list -i until it goes to MONITORING # openssl x509 -text -in /etc/pki/tls/certs/balancer.pem Certificate: Data: Version: 3 (0x2) Serial Number: 11 (0xb) Signature Algorithm: sha256WithRSAEncryption Issuer: O=EXAMPLE.COM, CN=Certificate Authority Validity Not Before: Mar 20 14:29:33 2015 GMT Not After : Mar 20 14:29:33 2017 GMT Subject: O=EXAMPLE.COM, CN=balancer.example.com [SNIP] X509v3 extensions: [SNIP] X509v3 Subject Alternative Name: DNS:idp.example.com, othername:, othername: [SNIP] SAN was definitely not supported in 3.0. Not sure about 3.3, should work in 4.0+. rob > > 2015-03-19 15:04 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> Isn't this documented well (yet) ? >> >> Is what documented yet? >> >> rob >> >>> >>> The RH docs are always very detailed about it, but I'm not sure >>> here... I see solutions but not 100% from A to Z to make sure we do it >>> the proper way. >>> >>> 2015-03-12 16:59 GMT+01:00 Matt . : >>>> Not worried, I need to try. >>>> >>>> I think it's not an issue as we use persistance for the connection. We >>>> only do some user adding/chaging stuff, nothing really fancy but it >>>> needs to be decent. As persistence comes in I think we don't have to >>>> worry about it, we discussed that here earlier as I remember. >>>> >>>> Or do I ? >>>> >>>> Something else; did you had a nice PTO ? >>>> >>>> 2015-03-12 15:54 GMT+01:00 Rob Crittenden : >>>>> Matt . wrote: >>>>>> Hi, >>>>>> >>>>>> Security wise I can understand that. >>>>>> >>>>>> Yes I have read about that... but that would let me use the >>>>>> loadbalancer to connect ? I was not sure if the SAN would "connect" as >>>>>> "other" host. >>>>> >>>>> Kerberos through a load balancer can be a problem. Is this what you're >>>>> worried about? >>>>> >>>>> rob >>>>> >>>>>> >>>>>> 2015-03-12 15:07 GMT+01:00 Rob Crittenden : >>>>>>> Matt . wrote: >>>>>>>> Hi Guys, >>>>>>>> >>>>>>>> Is Rob able to look at this ? I hope he has some sparetime as I'm >>>>>>>> kinda stuck with this issue. >>>>>>> >>>>>>> Wildcard certs are not supported. >>>>>>> >>>>>>> You can request a SAN with certmonger using -D . That will work >>>>>>> with IPA 4.x for sure, maybe 3.3.5. >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> >>>>>>>> Thanks! >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> 2015-03-08 12:30 GMT+01:00 Matt . : >>>>>>>>> I'm reviewing some things. >>>>>>>>> >>>>>>>>> When I'm using a loadbalancer, which I prefer in this setup I need to >>>>>>>>> have the same certificates on both servers. Maybe a wildcard for my >>>>>>>>> domain could do instead of having only both fqdn's of the servers >>>>>>>>> including the loadbalancer's fqdn. >>>>>>>>> >>>>>>>>> But the question remains, how? >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I will balance with IP persistance so I think there won't be any >>>>>>>>>> mixing as long as that "used" server is online. >>>>>>>>>> >>>>>>>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>>>>>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>>>>>>>> >>>>>>>>>>>> OK, understood. >>>>>>>>>>>> >>>>>>>>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>>>>>>>> record and the first is not reacable, would it try to do it again or >>>>>>>>>>>> will handle DNS this in front of it ? >>>>>>>>>>>> >>>>>>>>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>>>>>>>> checked if the user was able to auth himself using his ldap >>>>>>>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>>>>>>>> to the IPA server. >>>>>>>>>>>> >>>>>>>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>>>>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>>>>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>>>>>>>> from PHP for an example. Building in extra checks in front could be >>>>>>>>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>>>>>>>> better. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>>>>>>>> Rob. What is our failover logic for API? >>>>>>>>>>> >>>>>>>>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>>>>>>>> whole conversation goes to the same server you should be fine. I do not >>>>>>>>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>>>>>>>> cert there then if you can enforce the use of the same server in this case. >>>>>>>>>>> >>>>>>>>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>>>>>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>>>>>>>> >>>>>>>>>>> Rob does that make sense for you? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Thanks! >>>>>>>>>>>> >>>>>>>>>>>> Cheers, >>>>>>>>>>>> >>>>>>>>>>>> Matt >>>>>>>>>>>> >>>>>>>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>>>>>>>> >>>>>>>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>> >>>>>>>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>>>>>>>> SRV won't fit here sorry to say. >>>>>>>>>>>>>> >>>>>>>>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>>>>>>>> believe ? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>>>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>>>>>>>> it >>>>>>>>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>>>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>>>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>>>>>>>> you >>>>>>>>>>>>> do not have any load balancers and this is the common case. You are >>>>>>>>>>>>> trying >>>>>>>>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>>>>>>>> 100% there in step 6 >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Matthijs >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>>>>>>>> curl/json. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>>>>>>>> It >>>>>>>>>>>>>>> will >>>>>>>>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>>>>>>>> easiest >>>>>>>>>>>>>>> way. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>>>>>>>> way >>>>>>>>>>>>>>> is to >>>>>>>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>>>>>>>> works >>>>>>>>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>>>>>>>> and >>>>>>>>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>>>>>>>> IPA >>>>>>>>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>>>>>>>> own >>>>>>>>>>>>>>> keytab with different key. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>>>>>>>> possibility >>>>>>>>>>>>>>> of >>>>>>>>>>>>>>> sharing keytabs between IPA services. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Does this make it more clear ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>>>>>>>> clients. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>>>>>>>> ipa >>>>>>>>>>>>>>>>>> server ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Any other options ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>>>>>>>> detail, please? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>>>>>>>> possible to use >>>>>>>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>>>>>>>> to ipa >>>>>>>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>>>>>>>> classical load >>>>>>>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>>>>>>>> you to mess >>>>>>>>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> Petr Spacek @ Red Hat >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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. >>>>>>>>>>> >>>>>>>>>>> -- >>>>>>>>>>> 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 roberto.cornacchia at gmail.com Fri Mar 20 14:56:45 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 15:56:45 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550C0519.1040609@redhat.com> References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> Message-ID: The zone settings: $ ipa dnszone-show --all Zone name: hq.example.com. dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com Zone name: hq.example.com. Active zone: TRUE Authoritative nameserver: ipa.hq.example.com. Administrator e-mail address: hostmaster.hq.example.com. SOA serial: 1426857128 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * AAAA; grant HQ.EXAMPLE.COM krb5-self * SSHFP; Dynamic update: TRUE Allow query: any; Allow transfer: none; nsrecord: ipa.hq.example.com. objectclass: idnszone, top, idnsrecord The DNS log doesn't mention anything about updates. It does contain some errors about unreachable hosts, but that's because I had a temporary interruption towards the gateway from the ipa server. One thing I did after installing the IPA server is to turn off support for ipv6, using $ echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf $ sysctl -p Do you think it could have any influence? On 20 March 2015 at 12:31, Martin Basti wrote: > Hello, > > do you have enabled DNS dynamic updates for hq.example.zone? > You can check it in zone settings. > > Are there any log entries in dns log related to nsupdate executed from a > client? > $ journalctl -b -u named-pkcs11 > > > On 20/03/15 09:53, Roberto Cornacchia wrote: > > It seems so: > > $ firewall-cmd --list-all > FedoraServer (default, active) > interfaces: em2 > sources: > services: cockpit dhcpv6-client ssh > ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp 464/udp > 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp 9445/tcp > 8011/tcp 53/udp 8082/tcp > masquerade: no > forward-ports: > icmp-blocks: > rich rules: > > > On 20 March 2015 at 00:53, Dmitri Pal wrote: > >> On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: >> >> Yes. >> >> [root at meson ~]# cat /etc/resolv.conf >> search hq.example.com >> nameserver 192.168.0.72 >> >> Sorry from the short log I posted it's not visible, but that ip address >> is the address of the ipa server (ipa.hq.example.com) >> >> [root at meson ~]# dig ipa.hq.example.com >> >> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com >> ;; global options: +cmd >> ;; Got answer: >> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238 >> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 >> >> ;; OPT PSEUDOSECTION: >> ; EDNS: version: 0, flags:; udp: 4096 >> ;; QUESTION SECTION: >> ;ipa.hq.example.com. IN A >> >> ;; ANSWER SECTION: >> ipa.hq.example.com. 1200 IN A 192.168.0.72 >> >> ;; AUTHORITY SECTION: >> hq.example.com. 86400 IN NS ipa.hq.example.com. >> >> ;; Query time: 1 msec >> ;; SERVER: 192.168.0.72#53(192.168.0.72) >> ;; WHEN: do mrt 19 22:02:04 CET 2015 >> ;; MSG SIZE rcvd: 83 >> >> >> >> OK so you can in fact lookup the server. >> Have you opened all required ports for ldap and kerberos and other >> protocols in the firewall both UDP and TCP? >> >> >> >> >> On 19 March 2015 at 21:55, Dmitri Pal wrote: >> >>> On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: >>> >>> Hi, >>> >>> This should really work like a charm, and I'm sure it is a stupid >>> mistake of mine if it doesn't, but I really can't find out what goes wrong. >>> >>> Both IPA server and client are on FC21, very up to date. >>> Server installation (standard, with dns) worked well. Required ports >>> open in the firewall. Everything seems to work. >>> >>> I did try to use the IPA server as a DNS (with forwarders) and NTP >>> server from non-ipa clients, no problem. >>> I also tried to use it as LDAP server, from a non-fedora machine (a >>> synology). It worked well and I could see users. >>> >>> When trying to enroll a client, the enrollment itself seems to >>> succeed, but: >>> - Unable to sync time with NTP server >>> - Unable to update DNS >>> - Unable to find users >>> >>> I include below the short installation log (I changed the real domain >>> into hq.example.com), and in attachment, the full log with debug on. >>> >>> From the debug log, about the DNS update failure, I can see this: >>> >>> ; Communication with 192.168.0.72#53 failed: operation canceled >>> could not reach any name server >>> >>> I'm not sure what communication problem this could be, as the server >>> (which is both the IPA and the DNS servers), clearly can be reached. >>> >>> Any idea where to look at? >>> >>> >>> Do you have the IPA DNS server in the resolv.conf of the client? >>> >>> >>> >>> >>> Thanks, >>> Roberto >>> >>> >>> [root at meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns >>> --force-ntpd --hostname=meson.hq.example.com >>> Discovery was successful! >>> Hostname: meson.hq.example.com >>> Realm: HQ.EXAMPLE.COM >>> DNS Domain: hq.example.com >>> IPA Server: ipa.hq.example.com >>> BaseDN: dc=hq,dc=example,dc=com >>> >>> Continue to configure the system with these values? [no]: yes >>> Synchronizing time with KDC... >>> *Unable to sync time with IPA NTP server, assuming the time is in sync. >>> Please check that 123 UDP port is opened.* >>> User authorized to enroll computers: admin >>> Password for admin at HQ.EXAMPLE.COM: >>> Successfully retrieved CA cert >>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>> >>> Enrolled in IPA realm HQ.EXAMPLE.COM >>> 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 HQ.EXAMPLE.COM >>> trying https://ipa.hq.example.com/ipa/json >>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' >>> Forwarding 'ca_is_enabled' to json server ' >>> https://ipa.hq.example.com/ipa/json' >>> Systemwide CA database updated. >>> Added CA certificates to the default NSS database. >>> Hostname (meson.hq.example.com) not found in DNS >>> *Failed to update DNS records.* >>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>> Forwarding 'host_mod' to json server ' >>> https://ipa.hq.example.com/ipa/json' >>> *Could not update DNS SSHFP records.* >>> SSSD enabled >>> Configured /etc/openldap/ldap.conf >>> *Unable to find 'admin' user with 'getent passwd admin at hq.example.com >>> '!* >>> *Unable to reliably detect configuration. Check NSS setup manually.* >>> NTP enabled >>> Configured /etc/ssh/ssh_config >>> Configured /etc/ssh/sshd_config >>> Configuring hq.example.com as NIS domain. >>> Client configuration complete. >>> >>> >>> >>> >>> >>> -- >>> 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. >> >> >> -- >> 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 >> > > > > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.holway at gmail.com Fri Mar 20 15:05:56 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Fri, 20 Mar 2015 16:05:56 +0100 Subject: [Freeipa-users] SSSD in redundant configuration - part 2 Message-ID: Hi, I am having one of those really annoying pesky troubles. I add clients to freeipa but the first time I am logging in and trying to sudo with my freeipa credentials the sudo is not working. If I restart the SSSD process this usually fixes it but not always. Im going to try and do some systematic tests and collect some logs but I thought someone might have a clue. I noticed that when I was using "ldap_uri = _srv_" vs "ldap_uri = ldap://address" I was getting the same problem so I am thinking its a DNS lookup glitch? Cheers, Andrew [domain/cloud.domain.de] cache_credentials = True krb5_store_password_if_offline = True ipa_domain = cloud.domain.de id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = test-freeipa-client-3.cloud.domain.de chpass_provider = ipa ipa_dyndns_update = True #check DNS SRV record for ipa service location. ipa_server = _srv_ ldap_tls_cacert = /etc/ipa/ca.crt # For the SUDO integration sudo_provider = ipa #ldap_uri = _srv_ #ldap_sudo_search_base = ou=sudoers,dc=cloud,dc=domain,dc=de #ldap_sasl_mech = GSSAPI #ldap_sasl_authid = host/test-freeipa-client-3.cloud.domain.de #ldap_sasl_realm = CLOUD.DOMAIN.DE #krb5_server = _srv_ debug_level = 9 [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = cloud.domain.de debug_level = 9 [nss] [pam] [sudo] [autofs] [ssh] [pac] -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Mar 20 15:37:45 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 20 Mar 2015 16:37:45 +0100 Subject: [Freeipa-users] SSSD in redundant configuration - part 2 In-Reply-To: References: Message-ID: <20150320153745.GV8409@hendrix.redhat.com> On Fri, Mar 20, 2015 at 04:05:56PM +0100, Andrew Holway wrote: > Hi, > > I am having one of those really annoying pesky troubles. > > I add clients to freeipa but the first time I am logging in and trying to > sudo with my freeipa credentials the sudo is not working. If I restart the > SSSD process this usually fixes it but not always. Im going to try and do > some systematic tests and collect some logs but I thought someone might > have a clue. > > I noticed that when I was using "ldap_uri = _srv_" vs "ldap_uri = > ldap://address" I was getting the same problem so I am thinking its a DNS > lookup glitch? Is it only the first time on a new client with totally empty cache or also first time a new user runs sudo? From dpal at redhat.com Fri Mar 20 16:06:49 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 12:06:49 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> Message-ID: <550C4599.7040806@redhat.com> On 03/20/2015 10:56 AM, Roberto Cornacchia wrote: > The zone settings: > > $ ipa dnszone-show --all > Zone name: hq.example.com . > dn: idnsname=hq.example.com > .,cn=dns,dc=hq,dc=example,dc=com > Zone name: hq.example.com . > Active zone: TRUE > Authoritative nameserver: ipa.hq.example.com > . > Administrator e-mail address: hostmaster.hq.example.com > . > SOA serial: 1426857128 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant HQ.EXAMPLE.COM > krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * AAAA; grant > HQ.EXAMPLE.COM krb5-self * SSHFP; > Dynamic update: TRUE > Allow query: any; > Allow transfer: none; > nsrecord: ipa.hq.example.com . > objectclass: idnszone, top, idnsrecord > > The DNS log doesn't mention anything about updates. It does contain > some errors about unreachable hosts, but that's because I had a > temporary interruption towards the gateway from the ipa server. > > One thing I did after installing the IPA server is to turn off support > for ipv6, using > $ echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf > $ sysctl -p > > Do you think it could have any influence? I think it can. I have a vague recollection of a bug related to that is some of the packages we depend on or something like. Can you try enabling it and see if it makes a difference? > > > On 20 March 2015 at 12:31, Martin Basti > wrote: > > Hello, > > do you have enabled DNS dynamic updates for hq.example.zone? > You can check it in zone settings. > > Are there any log entries in dns log related to nsupdate executed > from a client? > $ journalctl -b -u named-pkcs11 > > > On 20/03/15 09:53, Roberto Cornacchia wrote: >> It seems so: >> >> $ firewall-cmd --list-all >> FedoraServer (default, active) >> interfaces: em2 >> sources: >> services: cockpit dhcpv6-client ssh >> ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp >> 88/udp 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp >> 7389/tcp 9444/tcp 9445/tcp 8011/tcp 53/udp 8082/tcp >> masquerade: no >> forward-ports: >> icmp-blocks: >> rich rules: >> >> >> On 20 March 2015 at 00:53, Dmitri Pal > > wrote: >> >> On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: >>> Yes. >>> >>> [root at meson ~]# cat /etc/resolv.conf >>> search hq.example.com >>> nameserver 192.168.0.72 >>> >>> Sorry from the short log I posted it's not visible, but that >>> ip address is the address of the ipa server >>> (ipa.hq.example.com ) >>> >>> [root at meson ~]# dig ipa.hq.example.com >>> >>> >>> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> >>> ipa.hq.example.com >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238 >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, >>> ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;ipa.hq.example.com.INA >>> >>> ;; ANSWER SECTION: >>> ipa.hq.example.com. 1200INA192.168.0.72 >>> >>> ;; AUTHORITY SECTION: >>> hq.example.com.86400INNSipa.hq.example.com. >>> >>> ;; Query time: 1 msec >>> ;; SERVER: 192.168.0.72#53(192.168.0.72) >>> ;; WHEN: do mrt 19 22:02:04 CET 2015 >>> ;; MSG SIZE rcvd: 83 >> >> >> OK so you can in fact lookup the server. >> Have you opened all required ports for ldap and kerberos and >> other protocols in the firewall both UDP and TCP? >> >> >>> >>> >>> On 19 March 2015 at 21:55, Dmitri Pal >> > wrote: >>> >>> On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: >>>> Hi, >>>> >>>> This should really work like a charm, and I'm sure it >>>> is a stupid mistake of mine if it doesn't, but I really >>>> can't find out what goes wrong. >>>> >>>> Both IPA server and client are on FC21, very up to date. >>>> Server installation (standard, with dns) worked well. >>>> Required ports open in the firewall. Everything seems >>>> to work. >>>> >>>> I did try to use the IPA server as a DNS (with >>>> forwarders) and NTP server from non-ipa clients, no >>>> problem. >>>> I also tried to use it as LDAP server, from a >>>> non-fedora machine (a synology). It worked well and I >>>> could see users. >>>> >>>> When trying to enroll a client, the enrollment itself >>>> seems to succeed, but: >>>> - Unable to sync time with NTP server >>>> - Unable to update DNS >>>> - Unable to find users >>>> >>>> I include below the short installation log (I changed >>>> the real domain into hq.example.com >>>> ), and in attachment, the full >>>> log with debug on. >>>> >>>> From the debug log, about the DNS update failure, I can >>>> see this: >>>> >>>> ; Communication with 192.168.0.72#53 failed: >>>> operation canceled >>>> could not reach any name server >>>> >>>> I'm not sure what communication problem this could be, >>>> as the server (which is both the IPA and the DNS >>>> servers), clearly can be reached. >>>> >>>> Any idea where to look at? >>> >>> Do you have the IPA DNS server in the resolv.conf of the >>> client? >>> >>> >>> >>>> >>>> Thanks, >>>> Roberto >>>> >>>> >>>> [root at meson ~]# ipa-client-install --mkhomedir >>>> --ssh-trust-dns --force-ntpd >>>> --hostname=meson.hq.example.com >>>> >>>> Discovery was successful! >>>> Hostname: meson.hq.example.com >>>> >>>> Realm: HQ.EXAMPLE.COM >>>> DNS Domain: hq.example.com >>>> IPA Server: ipa.hq.example.com >>>> BaseDN: dc=hq,dc=example,dc=com >>>> >>>> Continue to configure the system with these values? >>>> [no]: yes >>>> Synchronizing time with KDC... >>>> *Unable to sync time with IPA NTP server, assuming the >>>> time is in sync. Please check that 123 UDP port is opened.* >>>> User authorized to enroll computers: admin >>>> Password for admin at HQ.EXAMPLE.COM >>>> : >>>> Successfully retrieved CA cert >>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>> >>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>> >>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>> >>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>> >>>> 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 HQ.EXAMPLE.COM >>>> >>>> trying https://ipa.hq.example.com/ipa/json >>>> Forwarding 'ping' to json server >>>> 'https://ipa.hq.example.com/ipa/json' >>>> Forwarding 'ca_is_enabled' to json server >>>> 'https://ipa.hq.example.com/ipa/json' >>>> Systemwide CA database updated. >>>> Added CA certificates to the default NSS database. >>>> Hostname (meson.hq.example.com >>>> ) not found in DNS >>>> *Failed to update DNS records.* >>>> Adding SSH public key from >>>> /etc/ssh/ssh_host_ed25519_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>> Forwarding 'host_mod' to json server >>>> 'https://ipa.hq.example.com/ipa/json' >>>> *Could not update DNS SSHFP records.* >>>> SSSD enabled >>>> Configured /etc/openldap/ldap.conf >>>> *Unable to find 'admin' user with 'getent passwd >>>> admin at hq.example.com '!* >>>> *Unable to reliably detect configuration. Check NSS >>>> setup manually.* >>>> NTP enabled >>>> Configured /etc/ssh/ssh_config >>>> Configured /etc/ssh/sshd_config >>>> Configuring hq.example.com as >>>> NIS domain. >>>> Client configuration complete. >>>> >>>> >>>> >>> >>> >>> -- >>> 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. >> >> >> -- >> 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 >> >> >> >> > > > -- > Martin Basti > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Fri Mar 20 17:04:04 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 18:04:04 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550C4599.7040806@redhat.com> References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> Message-ID: ipv6 re-enabled. No luck yet :( On 20 March 2015 at 17:06, Dmitri Pal wrote: > On 03/20/2015 10:56 AM, Roberto Cornacchia wrote: > > The zone settings: > > $ ipa dnszone-show --all > Zone name: hq.example.com. > dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com > Zone name: hq.example.com. > Active zone: TRUE > Authoritative nameserver: ipa.hq.example.com. > Administrator e-mail address: hostmaster.hq.example.com. > SOA serial: 1426857128 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM > krb5-self * AAAA; grant HQ.EXAMPLE.COM krb5-self * SSHFP; > Dynamic update: TRUE > Allow query: any; > Allow transfer: none; > nsrecord: ipa.hq.example.com. > objectclass: idnszone, top, idnsrecord > > The DNS log doesn't mention anything about updates. It does contain > some errors about unreachable hosts, but that's because I had a temporary > interruption towards the gateway from the ipa server. > > One thing I did after installing the IPA server is to turn off support > for ipv6, using > $ echo "net.ipv6.conf.all.disable_ipv6 = 1" >> /etc/sysctl.conf > $ sysctl -p > > Do you think it could have any influence? > > > I think it can. > I have a vague recollection of a bug related to that is some of the > packages we depend on or something like. > Can you try enabling it and see if it makes a difference? > > > > > On 20 March 2015 at 12:31, Martin Basti wrote: > >> Hello, >> >> do you have enabled DNS dynamic updates for hq.example.zone? >> You can check it in zone settings. >> >> Are there any log entries in dns log related to nsupdate executed from a >> client? >> $ journalctl -b -u named-pkcs11 >> >> >> On 20/03/15 09:53, Roberto Cornacchia wrote: >> >> It seems so: >> >> $ firewall-cmd --list-all >> FedoraServer (default, active) >> interfaces: em2 >> sources: >> services: cockpit dhcpv6-client ssh >> ports: 8009/tcp 443/tcp 7999/tcp 464/tcp 9443/tcp 636/tcp 88/udp >> 464/udp 8010/tcp 88/tcp 7990/tcp 123/udp 80/tcp 389/tcp 7389/tcp 9444/tcp >> 9445/tcp 8011/tcp 53/udp 8082/tcp >> masquerade: no >> forward-ports: >> icmp-blocks: >> rich rules: >> >> >> On 20 March 2015 at 00:53, Dmitri Pal wrote: >> >>> On 03/19/2015 05:04 PM, Roberto Cornacchia wrote: >>> >>> Yes. >>> >>> [root at meson ~]# cat /etc/resolv.conf >>> search hq.example.com >>> nameserver 192.168.0.72 >>> >>> Sorry from the short log I posted it's not visible, but that ip >>> address is the address of the ipa server (ipa.hq.example.com) >>> >>> [root at meson ~]# dig ipa.hq.example.com >>> >>> ; <<>> DiG 9.9.6-P1-RedHat-9.9.6-8.P1.fc21 <<>> ipa.hq.example.com >>> ;; global options: +cmd >>> ;; Got answer: >>> ;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 53238 >>> ;; flags: qr aa rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 1, ADDITIONAL: 1 >>> >>> ;; OPT PSEUDOSECTION: >>> ; EDNS: version: 0, flags:; udp: 4096 >>> ;; QUESTION SECTION: >>> ;ipa.hq.example.com. IN A >>> >>> ;; ANSWER SECTION: >>> ipa.hq.example.com. 1200 IN A 192.168.0.72 >>> >>> ;; AUTHORITY SECTION: >>> hq.example.com. 86400 IN NS ipa.hq.example.com. >>> >>> ;; Query time: 1 msec >>> ;; SERVER: 192.168.0.72#53(192.168.0.72) >>> ;; WHEN: do mrt 19 22:02:04 CET 2015 >>> ;; MSG SIZE rcvd: 83 >>> >>> >>> >>> OK so you can in fact lookup the server. >>> Have you opened all required ports for ldap and kerberos and other >>> protocols in the firewall both UDP and TCP? >>> >>> >>> >>> >>> On 19 March 2015 at 21:55, Dmitri Pal wrote: >>> >>>> On 03/19/2015 04:46 PM, Roberto Cornacchia wrote: >>>> >>>> Hi, >>>> >>>> This should really work like a charm, and I'm sure it is a stupid >>>> mistake of mine if it doesn't, but I really can't find out what goes wrong. >>>> >>>> Both IPA server and client are on FC21, very up to date. >>>> Server installation (standard, with dns) worked well. Required ports >>>> open in the firewall. Everything seems to work. >>>> >>>> I did try to use the IPA server as a DNS (with forwarders) and NTP >>>> server from non-ipa clients, no problem. >>>> I also tried to use it as LDAP server, from a non-fedora machine (a >>>> synology). It worked well and I could see users. >>>> >>>> When trying to enroll a client, the enrollment itself seems to >>>> succeed, but: >>>> - Unable to sync time with NTP server >>>> - Unable to update DNS >>>> - Unable to find users >>>> >>>> I include below the short installation log (I changed the real domain >>>> into hq.example.com), and in attachment, the full log with debug on. >>>> >>>> From the debug log, about the DNS update failure, I can see this: >>>> >>>> ; Communication with 192.168.0.72#53 failed: operation canceled >>>> could not reach any name server >>>> >>>> I'm not sure what communication problem this could be, as the server >>>> (which is both the IPA and the DNS servers), clearly can be reached. >>>> >>>> Any idea where to look at? >>>> >>>> >>>> Do you have the IPA DNS server in the resolv.conf of the client? >>>> >>>> >>>> >>>> >>>> Thanks, >>>> Roberto >>>> >>>> >>>> [root at meson ~]# ipa-client-install --mkhomedir --ssh-trust-dns >>>> --force-ntpd --hostname=meson.hq.example.com >>>> Discovery was successful! >>>> Hostname: meson.hq.example.com >>>> Realm: HQ.EXAMPLE.COM >>>> DNS Domain: hq.example.com >>>> IPA Server: ipa.hq.example.com >>>> BaseDN: dc=hq,dc=example,dc=com >>>> >>>> Continue to configure the system with these values? [no]: yes >>>> Synchronizing time with KDC... >>>> *Unable to sync time with IPA NTP server, assuming the time is in sync. >>>> Please check that 123 UDP port is opened.* >>>> User authorized to enroll computers: admin >>>> Password for admin at HQ.EXAMPLE.COM: >>>> Successfully retrieved CA cert >>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>> >>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>> 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 HQ.EXAMPLE.COM >>>> trying https://ipa.hq.example.com/ipa/json >>>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' >>>> Forwarding 'ca_is_enabled' to json server ' >>>> https://ipa.hq.example.com/ipa/json' >>>> Systemwide CA database updated. >>>> Added CA certificates to the default NSS database. >>>> Hostname (meson.hq.example.com) not found in DNS >>>> *Failed to update DNS records.* >>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>> Forwarding 'host_mod' to json server ' >>>> https://ipa.hq.example.com/ipa/json' >>>> *Could not update DNS SSHFP records.* >>>> SSSD enabled >>>> Configured /etc/openldap/ldap.conf >>>> *Unable to find 'admin' user with 'getent passwd admin at hq.example.com >>>> '!* >>>> *Unable to reliably detect configuration. Check NSS setup manually.* >>>> NTP enabled >>>> Configured /etc/ssh/ssh_config >>>> Configured /etc/ssh/sshd_config >>>> Configuring hq.example.com as NIS domain. >>>> Client configuration complete. >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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 >>> >> >> >> >> >> >> -- >> Martin Basti >> >> > > > > > -- > 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 roberto.cornacchia at gmail.com Fri Mar 20 17:18:43 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 18:18:43 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> Message-ID: Update: I tried from another client. Also FC21, same network, same settings from the same DHCP. But obviously it must have something different because it partially succeeded. - I do not get errors about LDAP users. - I do not get errors about DNS update However: - I still get the initial error about NTP - The host is enrolled, but not added to the DNS zone Now, I don't care much about the previous client. It was pretty much empty and can re-install Fedora from scratch. But I'd like to understand if this is still a problem. It should be added to the zone, shouldn't it? $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd Discovery was successful! Hostname: photon.example.com Realm: HQ.EXAMPLE.COM DNS Domain: hq.example.com IPA Server: ipa.hq.example.com BaseDN: dc=hq,dc=example,dc=com Continue to configure the system with these values? [no]: yes Synchronizing time with KDC... *Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened.* User authorized to enroll computers: admin Password for admin at HQ.EXAMPLE.COM: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM Valid From: Mon Mar 16 18:44:35 2015 UTC Valid Until: Fri Mar 16 18:44:35 2035 UTC Enrolled in IPA realm HQ.EXAMPLE.COM 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 HQ.EXAMPLE.COM trying https://ipa.hq.example.com/ipa/json Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' Forwarding 'ca_is_enabled' to json server ' https://ipa.hq.example.com/ipa/json' Systemwide CA database updated. Added CA certificates to the default NSS database. Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json' *Could not update DNS SSHFP records.* SSSD enabled Configured /etc/openldap/ldap.conf NTP enabled Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Configuring hq.example.com as NIS domain. Client configuration complete. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Fri Mar 20 17:25:39 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 18:25:39 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> Message-ID: Oops. Not true, forget last email. This secon client installation went different just because it took the wrong domain. It used *example.com * (what was previously set) instead of *hq.example.com * Uninstalled, tried again with --hostname=photon.hq.example.com And then it behaves precisely like the previous client. So something seems wrong in the server. On 20 March 2015 at 18:18, Roberto Cornacchia wrote: > Update: > I tried from another client. Also FC21, same network, same settings from > the same DHCP. > But obviously it must have something different because it partially > succeeded. > > - I do not get errors about LDAP users. > - I do not get errors about DNS update > > However: > - I still get the initial error about NTP > - The host is enrolled, but not added to the DNS zone > > Now, I don't care much about the previous client. It was pretty much empty > and can re-install Fedora from scratch. > > But I'd like to understand if this is still a problem. > It should be added to the zone, shouldn't it? > > $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd > Discovery was successful! > Hostname: photon.example.com > Realm: HQ.EXAMPLE.COM > DNS Domain: hq.example.com > IPA Server: ipa.hq.example.com > BaseDN: dc=hq,dc=example,dc=com > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > *Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened.* > User authorized to enroll computers: admin > Password for admin at HQ.EXAMPLE.COM: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Valid From: Mon Mar 16 18:44:35 2015 UTC > Valid Until: Fri Mar 16 18:44:35 2035 UTC > > Enrolled in IPA realm HQ.EXAMPLE.COM > 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 HQ.EXAMPLE.COM > trying https://ipa.hq.example.com/ipa/json > Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' > Forwarding 'ca_is_enabled' to json server ' > https://ipa.hq.example.com/ipa/json' > Systemwide CA database updated. > Added CA certificates to the default NSS database. > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json' > *Could not update DNS SSHFP records.* > SSSD enabled > Configured /etc/openldap/ldap.conf > NTP enabled > Configured /etc/ssh/ssh_config > Configured /etc/ssh/sshd_config > Configuring hq.example.com as NIS domain. > Client configuration complete. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 20 17:37:17 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 13:37:17 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> Message-ID: <550C5ACD.6070904@redhat.com> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: > Oops. Not true, forget last email. > > This secon client installation went different just because it took the > wrong domain. > It used *example.com * (what was previously set) > instead of *hq.example.com * > > Uninstalled, tried again with --hostname=photon.hq.example.com > > And then it behaves precisely like the previous client. > > So something seems wrong in the server. > > On 20 March 2015 at 18:18, Roberto Cornacchia > > > wrote: > > Update: > I tried from another client. Also FC21, same network, same > settings from the same DHCP. > But obviously it must have something different because it > partially succeeded. > > - I do not get errors about LDAP users. > - I do not get errors about DNS update > > However: > - I still get the initial error about NTP > - The host is enrolled, but not added to the DNS zone > > Now, I don't care much about the previous client. It was pretty > much empty and can re-install Fedora from scratch. > > But I'd like to understand if this is still a problem. > It should be added to the zone, shouldn't it? > > $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd > Discovery was successful! > Hostname: photon.example.com > Realm: HQ.EXAMPLE.COM > DNS Domain: hq.example.com > IPA Server: ipa.hq.example.com > BaseDN: dc=hq,dc=example,dc=com > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > *Unable to sync time with IPA NTP server, assuming the time is in > sync. Please check that 123 UDP port is opened.* > User authorized to enroll computers: admin > Password for admin at HQ.EXAMPLE.COM : > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM > > Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM > > Valid From: Mon Mar 16 18:44:35 2015 UTC > Valid Until: Fri Mar 16 18:44:35 2035 UTC > > Enrolled in IPA realm HQ.EXAMPLE.COM > 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 HQ.EXAMPLE.COM > > trying https://ipa.hq.example.com/ipa/json > Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' > Forwarding 'ca_is_enabled' to json server > 'https://ipa.hq.example.com/ipa/json' > Systemwide CA database updated. > Added CA certificates to the default NSS database. > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub > Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Forwarding 'host_mod' to json server > 'https://ipa.hq.example.com/ipa/json' > *Could not update DNS SSHFP records.* > SSSD enabled > Configured /etc/openldap/ldap.conf > NTP enabled > Configured /etc/ssh/ssh_config > Configured /etc/ssh/sshd_config > Configuring hq.example.com as NIS domain. > Client configuration complete. > > > > It is different. It does not have the same failure about admin as you had in the first email. So may be it is the permissions issue and a separate NTP issue? Did you play with any permissions on the server side? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Fri Mar 20 17:55:57 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 18:55:57 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550C5ACD.6070904@redhat.com> References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> Message-ID: No, sorry about the confusion, i shouldn't have posted so quickly. When I use the correct domain (hq.example.com), then I really get all the same errors as before, also in the new client. On 20 Mar 2015 18:39, "Dmitri Pal" wrote: > On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: > > Oops. Not true, forget last email. > > This secon client installation went different just because it took the > wrong domain. > It used *example.com * (what was previously set) > instead of *hq.example.com * > > Uninstalled, tried again with --hostname=photon.hq.example.com > And then it behaves precisely like the previous client. > > So something seems wrong in the server. > > On 20 March 2015 at 18:18, Roberto Cornacchia < > roberto.cornacchia at gmail.com> wrote: > >> Update: >> I tried from another client. Also FC21, same network, same settings from >> the same DHCP. >> But obviously it must have something different because it partially >> succeeded. >> >> - I do not get errors about LDAP users. >> - I do not get errors about DNS update >> >> However: >> - I still get the initial error about NTP >> - The host is enrolled, but not added to the DNS zone >> >> Now, I don't care much about the previous client. It was pretty much >> empty and can re-install Fedora from scratch. >> >> But I'd like to understand if this is still a problem. >> It should be added to the zone, shouldn't it? >> >> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >> Discovery was successful! >> Hostname: photon.example.com >> Realm: HQ.EXAMPLE.COM >> DNS Domain: hq.example.com >> IPA Server: ipa.hq.example.com >> BaseDN: dc=hq,dc=example,dc=com >> >> Continue to configure the system with these values? [no]: yes >> Synchronizing time with KDC... >> *Unable to sync time with IPA NTP server, assuming the time is in sync. >> Please check that 123 UDP port is opened.* >> User authorized to enroll computers: admin >> Password for admin at HQ.EXAMPLE.COM: >> Successfully retrieved CA cert >> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> Valid From: Mon Mar 16 18:44:35 2015 UTC >> Valid Until: Fri Mar 16 18:44:35 2035 UTC >> >> Enrolled in IPA realm HQ.EXAMPLE.COM >> 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 HQ.EXAMPLE.COM >> trying https://ipa.hq.example.com/ipa/json >> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' >> Forwarding 'ca_is_enabled' to json server ' >> https://ipa.hq.example.com/ipa/json' >> Systemwide CA database updated. >> Added CA certificates to the default NSS database. >> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >> Forwarding 'host_mod' to json server ' >> https://ipa.hq.example.com/ipa/json' >> *Could not update DNS SSHFP records.* >> SSSD enabled >> Configured /etc/openldap/ldap.conf >> NTP enabled >> Configured /etc/ssh/ssh_config >> Configured /etc/ssh/sshd_config >> Configuring hq.example.com as NIS domain. >> Client configuration complete. >> >> > > > > It is different. It does not have the same failure about admin as you had > in the first email. > So may be it is the permissions issue and a separate NTP issue? > Did you play with any permissions on the server side? > > > -- > 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 roberto.cornacchia at gmail.com Fri Mar 20 17:57:53 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 18:57:53 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> Message-ID: But the ipa server itself is also enrolled as a client, just after the server installation, right?. And that worked fine. On 20 March 2015 at 18:55, Roberto Cornacchia wrote: > No, sorry about the confusion, i shouldn't have posted so quickly. > > When I use the correct domain (hq.example.com), then I really get all the > same errors as before, also in the new client. > > > > On 20 Mar 2015 18:39, "Dmitri Pal" wrote: > >> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >> >> Oops. Not true, forget last email. >> >> This secon client installation went different just because it took the >> wrong domain. >> It used *example.com * (what was previously set) >> instead of *hq.example.com * >> >> Uninstalled, tried again with --hostname=photon.hq.example.com >> And then it behaves precisely like the previous client. >> >> So something seems wrong in the server. >> >> On 20 March 2015 at 18:18, Roberto Cornacchia < >> roberto.cornacchia at gmail.com> wrote: >> >>> Update: >>> I tried from another client. Also FC21, same network, same settings from >>> the same DHCP. >>> But obviously it must have something different because it partially >>> succeeded. >>> >>> - I do not get errors about LDAP users. >>> - I do not get errors about DNS update >>> >>> However: >>> - I still get the initial error about NTP >>> - The host is enrolled, but not added to the DNS zone >>> >>> Now, I don't care much about the previous client. It was pretty much >>> empty and can re-install Fedora from scratch. >>> >>> But I'd like to understand if this is still a problem. >>> It should be added to the zone, shouldn't it? >>> >>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>> Discovery was successful! >>> Hostname: photon.example.com >>> Realm: HQ.EXAMPLE.COM >>> DNS Domain: hq.example.com >>> IPA Server: ipa.hq.example.com >>> BaseDN: dc=hq,dc=example,dc=com >>> >>> Continue to configure the system with these values? [no]: yes >>> Synchronizing time with KDC... >>> *Unable to sync time with IPA NTP server, assuming the time is in sync. >>> Please check that 123 UDP port is opened.* >>> User authorized to enroll computers: admin >>> Password for admin at HQ.EXAMPLE.COM: >>> Successfully retrieved CA cert >>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>> >>> Enrolled in IPA realm HQ.EXAMPLE.COM >>> 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 HQ.EXAMPLE.COM >>> trying https://ipa.hq.example.com/ipa/json >>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' >>> Forwarding 'ca_is_enabled' to json server ' >>> https://ipa.hq.example.com/ipa/json' >>> Systemwide CA database updated. >>> Added CA certificates to the default NSS database. >>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>> Forwarding 'host_mod' to json server ' >>> https://ipa.hq.example.com/ipa/json' >>> *Could not update DNS SSHFP records.* >>> SSSD enabled >>> Configured /etc/openldap/ldap.conf >>> NTP enabled >>> Configured /etc/ssh/ssh_config >>> Configured /etc/ssh/sshd_config >>> Configuring hq.example.com as NIS domain. >>> Client configuration complete. >>> >>> >> >> >> >> It is different. It does not have the same failure about admin as you had >> in the first email. >> So may be it is the permissions issue and a separate NTP issue? >> Did you play with any permissions on the server side? >> >> >> -- >> 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 dpal at redhat.com Fri Mar 20 18:00:17 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 14:00:17 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> Message-ID: <550C6031.2060605@redhat.com> On 03/20/2015 01:55 PM, Roberto Cornacchia wrote: > > No, sorry about the confusion, i shouldn't have posted so quickly. > > When I use the correct domain (hq.example.com > ), then I really get all the same errors as > before, also in the new client. > Does it really hit the right domain controller? Can it be that there is something else on the network that overshadows IPA server? Can you do everything correctly on the server itself? kinit, ipa commands? UI? > > > On 20 Mar 2015 18:39, "Dmitri Pal" > wrote: > > On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >> Oops. Not true, forget last email. >> >> This secon client installation went different just because it >> took the wrong domain. >> It used *example.com * (what was previously >> set) instead of *hq.example.com * >> >> Uninstalled, tried again with --hostname=photon.hq.example.com >> >> And then it behaves precisely like the previous client. >> >> So something seems wrong in the server. >> >> On 20 March 2015 at 18:18, Roberto Cornacchia >> > > wrote: >> >> Update: >> I tried from another client. Also FC21, same network, same >> settings from the same DHCP. >> But obviously it must have something different because it >> partially succeeded. >> >> - I do not get errors about LDAP users. >> - I do not get errors about DNS update >> >> However: >> - I still get the initial error about NTP >> - The host is enrolled, but not added to the DNS zone >> >> Now, I don't care much about the previous client. It was >> pretty much empty and can re-install Fedora from scratch. >> >> But I'd like to understand if this is still a problem. >> It should be added to the zone, shouldn't it? >> >> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >> Discovery was successful! >> Hostname: photon.example.com >> Realm: HQ.EXAMPLE.COM >> DNS Domain: hq.example.com >> IPA Server: ipa.hq.example.com >> BaseDN: dc=hq,dc=example,dc=com >> >> Continue to configure the system with these values? [no]: yes >> Synchronizing time with KDC... >> *Unable to sync time with IPA NTP server, assuming the time >> is in sync. Please check that 123 UDP port is opened.* >> User authorized to enroll computers: admin >> Password for admin at HQ.EXAMPLE.COM : >> Successfully retrieved CA cert >> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> >> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> >> Valid From: Mon Mar 16 18:44:35 2015 UTC >> Valid Until: Fri Mar 16 18:44:35 2035 UTC >> >> Enrolled in IPA realm HQ.EXAMPLE.COM >> 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 HQ.EXAMPLE.COM >> >> trying https://ipa.hq.example.com/ipa/json >> Forwarding 'ping' to json server >> 'https://ipa.hq.example.com/ipa/json' >> Forwarding 'ca_is_enabled' to json server >> 'https://ipa.hq.example.com/ipa/json' >> Systemwide CA database updated. >> Added CA certificates to the default NSS database. >> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >> Forwarding 'host_mod' to json server >> 'https://ipa.hq.example.com/ipa/json' >> *Could not update DNS SSHFP records.* >> SSSD enabled >> Configured /etc/openldap/ldap.conf >> NTP enabled >> Configured /etc/ssh/ssh_config >> Configured /etc/ssh/sshd_config >> Configuring hq.example.com as NIS domain. >> Client configuration complete. >> >> >> >> > > It is different. It does not have the same failure about admin as > you had in the first email. > So may be it is the permissions issue and a separate NTP issue? > Did you play with any permissions on the server side? > > > -- > 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 dpal at redhat.com Fri Mar 20 18:41:58 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 14:41:58 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> Message-ID: <550C69F6.7040508@redhat.com> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: > But the ipa server itself is also enrolled as a client, just after the > server installation, right?. And that worked fine. Are these VMs? There have been a similar case when the network was not set properly for the virtual test environment. > > On 20 March 2015 at 18:55, Roberto Cornacchia > > > wrote: > > No, sorry about the confusion, i shouldn't have posted so quickly. > > When I use the correct domain (hq.example.com > ), then I really get all the same errors as > before, also in the new client. > > > > On 20 Mar 2015 18:39, "Dmitri Pal" > wrote: > > On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >> Oops. Not true, forget last email. >> >> This secon client installation went different just because it >> took the wrong domain. >> It used *example.com * (what was >> previously set) instead of *hq.example.com >> * >> >> Uninstalled, tried again with >> --hostname=photon.hq.example.com >> And then it behaves precisely like the previous client. >> >> So something seems wrong in the server. >> >> On 20 March 2015 at 18:18, Roberto Cornacchia >> > > wrote: >> >> Update: >> I tried from another client. Also FC21, same network, >> same settings from the same DHCP. >> But obviously it must have something different because it >> partially succeeded. >> >> - I do not get errors about LDAP users. >> - I do not get errors about DNS update >> >> However: >> - I still get the initial error about NTP >> - The host is enrolled, but not added to the DNS zone >> >> Now, I don't care much about the previous client. It was >> pretty much empty and can re-install Fedora from scratch. >> >> But I'd like to understand if this is still a problem. >> It should be added to the zone, shouldn't it? >> >> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >> Discovery was successful! >> Hostname: photon.example.com >> Realm: HQ.EXAMPLE.COM >> DNS Domain: hq.example.com >> IPA Server: ipa.hq.example.com >> BaseDN: dc=hq,dc=example,dc=com >> >> Continue to configure the system with these values? [no]: yes >> Synchronizing time with KDC... >> *Unable to sync time with IPA NTP server, assuming the >> time is in sync. Please check that 123 UDP port is opened.* >> User authorized to enroll computers: admin >> Password for admin at HQ.EXAMPLE.COM >> : >> Successfully retrieved CA cert >> Subject: CN=Certificate >> Authority,O=HQ.EXAMPLE.COM >> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> >> Valid From: Mon Mar 16 18:44:35 2015 UTC >> Valid Until: Fri Mar 16 18:44:35 2035 UTC >> >> Enrolled in IPA realm HQ.EXAMPLE.COM >> 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 HQ.EXAMPLE.COM >> >> trying https://ipa.hq.example.com/ipa/json >> Forwarding 'ping' to json server >> 'https://ipa.hq.example.com/ipa/json' >> Forwarding 'ca_is_enabled' to json server >> 'https://ipa.hq.example.com/ipa/json' >> Systemwide CA database updated. >> Added CA certificates to the default NSS database. >> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >> Forwarding 'host_mod' to json server >> 'https://ipa.hq.example.com/ipa/json' >> *Could not update DNS SSHFP records.* >> SSSD enabled >> Configured /etc/openldap/ldap.conf >> NTP enabled >> Configured /etc/ssh/ssh_config >> Configured /etc/ssh/sshd_config >> Configuring hq.example.com as NIS >> domain. >> Client configuration complete. >> >> >> >> > > It is different. It does not have the same failure about admin > as you had in the first email. > So may be it is the permissions issue and a separate NTP issue? > Did you play with any permissions on the server side? > > > -- > 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 roberto.cornacchia at gmail.com Fri Mar 20 18:48:07 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 19:48:07 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550C69F6.7040508@redhat.com> References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> Message-ID: No, all real machines. I'm really sorry it's taking so much of your time. I had tried almost everything on a VM setting first, and everything was fine. Everything always works fine, until you actually need it. On 20 March 2015 at 19:41, Dmitri Pal wrote: > On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: > > But the ipa server itself is also enrolled as a client, just after the > server installation, right?. And that worked fine. > > > Are these VMs? > There have been a similar case when the network was not set properly for > the virtual test environment. > > > > On 20 March 2015 at 18:55, Roberto Cornacchia < > roberto.cornacchia at gmail.com> wrote: > >> No, sorry about the confusion, i shouldn't have posted so quickly. >> >> When I use the correct domain (hq.example.com), then I really get all >> the same errors as before, also in the new client. >> >> >> >> On 20 Mar 2015 18:39, "Dmitri Pal" wrote: >> >>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>> >>> Oops. Not true, forget last email. >>> >>> This secon client installation went different just because it took the >>> wrong domain. >>> It used *example.com * (what was previously set) >>> instead of *hq.example.com * >>> >>> Uninstalled, tried again with --hostname=photon.hq.example.com >>> And then it behaves precisely like the previous client. >>> >>> So something seems wrong in the server. >>> >>> On 20 March 2015 at 18:18, Roberto Cornacchia < >>> roberto.cornacchia at gmail.com> wrote: >>> >>>> Update: >>>> I tried from another client. Also FC21, same network, same settings >>>> from the same DHCP. >>>> But obviously it must have something different because it partially >>>> succeeded. >>>> >>>> - I do not get errors about LDAP users. >>>> - I do not get errors about DNS update >>>> >>>> However: >>>> - I still get the initial error about NTP >>>> - The host is enrolled, but not added to the DNS zone >>>> >>>> Now, I don't care much about the previous client. It was pretty much >>>> empty and can re-install Fedora from scratch. >>>> >>>> But I'd like to understand if this is still a problem. >>>> It should be added to the zone, shouldn't it? >>>> >>>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>>> Discovery was successful! >>>> Hostname: photon.example.com >>>> Realm: HQ.EXAMPLE.COM >>>> DNS Domain: hq.example.com >>>> IPA Server: ipa.hq.example.com >>>> BaseDN: dc=hq,dc=example,dc=com >>>> >>>> Continue to configure the system with these values? [no]: yes >>>> Synchronizing time with KDC... >>>> *Unable to sync time with IPA NTP server, assuming the time is in sync. >>>> Please check that 123 UDP port is opened.* >>>> User authorized to enroll computers: admin >>>> Password for admin at HQ.EXAMPLE.COM: >>>> Successfully retrieved CA cert >>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>> >>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>> 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 HQ.EXAMPLE.COM >>>> trying https://ipa.hq.example.com/ipa/json >>>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' >>>> Forwarding 'ca_is_enabled' to json server ' >>>> https://ipa.hq.example.com/ipa/json' >>>> Systemwide CA database updated. >>>> Added CA certificates to the default NSS database. >>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>> Forwarding 'host_mod' to json server ' >>>> https://ipa.hq.example.com/ipa/json' >>>> *Could not update DNS SSHFP records.* >>>> SSSD enabled >>>> Configured /etc/openldap/ldap.conf >>>> NTP enabled >>>> Configured /etc/ssh/ssh_config >>>> Configured /etc/ssh/sshd_config >>>> Configuring hq.example.com as NIS domain. >>>> Client configuration complete. >>>> >>>> >>> >>> >>> >>> It is different. It does not have the same failure about admin as you >>> had in the first email. >>> So may be it is the permissions issue and a separate NTP issue? >>> Did you play with any permissions on the server side? >>> >>> >>> -- >>> 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. > > > -- > 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 Fri Mar 20 19:24:07 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 15:24:07 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> Message-ID: <550C73D7.7060007@redhat.com> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: > No, all real machines. > > I'm really sorry it's taking so much of your time. > I had tried almost everything on a VM setting first, and everything > was fine. > Everything always works fine, until you actually need it. We try to help as much as we can. Can you do LDAP lookups as a directory manager from client host to server? Can you ssh from client to server? When you try to install client is there anything in the logs on the server? Does it even get there? > > > On 20 March 2015 at 19:41, Dmitri Pal > wrote: > > On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >> But the ipa server itself is also enrolled as a client, just >> after the server installation, right?. And that worked fine. > > Are these VMs? > There have been a similar case when the network was not set > properly for the virtual test environment. > > >> >> On 20 March 2015 at 18:55, Roberto Cornacchia >> > > wrote: >> >> No, sorry about the confusion, i shouldn't have posted so >> quickly. >> >> When I use the correct domain (hq.example.com >> ), then I really get all the same >> errors as before, also in the new client. >> >> >> >> On 20 Mar 2015 18:39, "Dmitri Pal" > > wrote: >> >> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>> Oops. Not true, forget last email. >>> >>> This secon client installation went different just >>> because it took the wrong domain. >>> It used *example.com * (what was >>> previously set) instead of *hq.example.com >>> * >>> >>> Uninstalled, tried again with >>> --hostname=photon.hq.example.com >>> >>> And then it behaves precisely like the previous client. >>> >>> So something seems wrong in the server. >>> >>> On 20 March 2015 at 18:18, Roberto Cornacchia >>> >> > wrote: >>> >>> Update: >>> I tried from another client. Also FC21, same >>> network, same settings from the same DHCP. >>> But obviously it must have something different >>> because it partially succeeded. >>> >>> - I do not get errors about LDAP users. >>> - I do not get errors about DNS update >>> >>> However: >>> - I still get the initial error about NTP >>> - The host is enrolled, but not added to the DNS zone >>> >>> Now, I don't care much about the previous client. It >>> was pretty much empty and can re-install Fedora from >>> scratch. >>> >>> But I'd like to understand if this is still a problem. >>> It should be added to the zone, shouldn't it? >>> >>> $ ipa-client-install --mkhomedir --ssh-trust-dns >>> --force-ntpd >>> Discovery was successful! >>> Hostname: photon.example.com >>> Realm: HQ.EXAMPLE.COM >>> DNS Domain: hq.example.com >>> IPA Server: ipa.hq.example.com >>> >>> BaseDN: dc=hq,dc=example,dc=com >>> >>> Continue to configure the system with these values? >>> [no]: yes >>> Synchronizing time with KDC... >>> *Unable to sync time with IPA NTP server, assuming >>> the time is in sync. Please check that 123 UDP port >>> is opened.* >>> User authorized to enroll computers: admin >>> Password for admin at HQ.EXAMPLE.COM >>> : >>> Successfully retrieved CA cert >>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>> >>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>> >>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>> >>> Enrolled in IPA realm HQ.EXAMPLE.COM >>> >>> 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 >>> HQ.EXAMPLE.COM >>> trying https://ipa.hq.example.com/ipa/json >>> Forwarding 'ping' to json server >>> 'https://ipa.hq.example.com/ipa/json' >>> Forwarding 'ca_is_enabled' to json server >>> 'https://ipa.hq.example.com/ipa/json' >>> Systemwide CA database updated. >>> Added CA certificates to the default NSS database. >>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>> Adding SSH public key from >>> /etc/ssh/ssh_host_ed25519_key.pub >>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>> Adding SSH public key from >>> /etc/ssh/ssh_host_ecdsa_key.pub >>> Forwarding 'host_mod' to json server >>> 'https://ipa.hq.example.com/ipa/json' >>> *Could not update DNS SSHFP records.* >>> SSSD enabled >>> Configured /etc/openldap/ldap.conf >>> NTP enabled >>> Configured /etc/ssh/ssh_config >>> Configured /etc/ssh/sshd_config >>> Configuring hq.example.com >>> as NIS domain. >>> Client configuration complete. >>> >>> >>> >>> >> >> It is different. It does not have the same failure about >> admin as you had in the first email. >> So may be it is the permissions issue and a separate NTP >> issue? >> Did you play with any permissions on the server side? >> >> >> -- >> 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. > > > -- > 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 nathan at nathanpeters.com Fri Mar 20 20:51:56 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 20 Mar 2015 13:51:56 -0700 Subject: [Freeipa-users] Certificate and key problems in Linux Message-ID: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> I have FreeIPA installed on several types of Linux machines and they are all experiencing strange issues with certificates and host keys. Here is the setup: Server : FreeIPA 4.1.2 on Centos 7 Client 1&2 : FreeIPA 3.0.0-42.el6 with sssd 1.11.6-30.el6_6.4 on CentOS 6.5 Client 3&4 : FreeIPA 4.1.2-1.el7 on Centos 7 First the FreeIPA clients running client 3.0.0 do not seem to be properly getting their host keys from the server. Whenever I ssh from one client to another (or even to the IPA server itself) I am prompted to answer yes or no to the host key. The host keys are both listed in the host record if I login to the domain controller web interface (and match what is on the server), and the DNS SSHFP records exist also. # sss_ssh_authorizedkeys --debug 10 admin (Fri Mar 20 13:43:52:706986 2015) [sss_ssh_authorizedkeys] [main] (0x0020): sss_ssh_get_ent() failed (2): No such file or directory Error looking up public keys I've seen some bug reports that this was a problem with sssd 1.10 but with a recent (updated today) version of sssd 1.11 I would assume that is not the issue? The second issue is that whenver I join a FreeIPA 4.1.2 client, I can't login with FreeIPA or AD users. I believe this is due to the fact that when I login to the domain controller web interface and look at the freshly enrolled client it says "kerberos key present, host provisioned" but the next line is "Status No Valid Certificate". Unenrolling and re-enrolling the client leads to the same issue with "No Valid Certificate". Here is a grep of my client install log filtered for 'certificate'. I don't see any errors. 2015-03-20T20:33:28Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpuZCwlm' '-A' '-n' 'CA certificate 1' '-t' 'C,,' 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True is_server=False 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True is_server=False 2015-03-20T20:33:30Z DEBUG Adding CA certificates to the IPA NSS database. 2015-03-20T20:33:32Z DEBUG Attempting to add CA certificates to the default NSS database. 2015-03-20T20:33:32Z INFO Added CA certificates to the default NSS database. 2015-03-20T20:33:32Z DEBUG auth_certificate_callback: check_sig=True is_server=False From james.mcevoy at hp.com Fri Mar 20 20:59:44 2015 From: james.mcevoy at hp.com (McEvoy, James) Date: Fri, 20 Mar 2015 20:59:44 +0000 Subject: [Freeipa-users] Firewalld rules to allow AD Join Message-ID: <6301806E96421841896741228C6B1A2764C5A1AE@G4W3216.americas.hpqcorp.net> Hi FreeIPA Users: I can only get my new Fedora 21 freeipa to server to setup a trust with Active Directory if I turn off the firewall on the ipa server. I have looked through all the doc on which ports to open but have had no luck getting the join to work with firewalld running... Can someone tell me what firewalld is blocking on me? --jim These are my open services: # firewall-cmd --zone=public --list-all public (default) interfaces: sources: services: dhcpv6-client dns freeipa-ldap freeipa-ldaps http https kerberos kpasswd ldap ldaps mdns ntp samba ssh ports: masquerade: no forward-ports: icmp-blocks: [root at ipa ~]# ipa trust-add ENAS.NET --type=ad --admin=Administrator --password Active Directory domain administrator's password: ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue As soon as I turn off the firewall it works: [root at ipa ~]# systemctl stop firewalld [root at ipa ~]# ipa trust-add ENAS.NET --type=ad --admin=Administrator --password Active Directory domain administrator's password: ----------------------------------------- Re-established trust to domain "enas.net" ----------------------------------------- Realm name: enas.net Domain NetBIOS name: ENAS Domain Security Identifier: S-1-5-21-1497210546-3194758708-3931123408 SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, S-1-1, S-1-0, S-1-5-19, S-1-5-18 Trust direction: Two-way trust Trust type: Active Directory domain Trust status: Established and verified The only error the I have found is in the samba logs where lsasd has the following: [2015/03/19 18:19:22.792043, 1] ipa_sam.c:1671(search_krb_princ) get_trusted_domain_int: no object found with filter 'krbPrincipalName=krbtgt/ENAS.NET at LNX.LAB'. [2015/03/19 18:19:23.080328, 1] ipa_sam.c:1671(search_krb_princ) get_trusted_domain_int: no object found with filter 'krbPrincipalName=krbtgt/LNX.LAB at ENAS.NET'. and winbindd-imap has this in it: [2015/03/20 14:21:14.966125, 1] ../source3/winbindd/idmap.c:202(idmap_init_domain) idmap range not specified for domain * [2015/03/20 14:21:14.968671, 1] ../source3/winbindd/idmap.c:202(idmap_init_domain) idmap range not specified for domain * From nathan at nathanpeters.com Fri Mar 20 21:23:12 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 20 Mar 2015 14:23:12 -0700 Subject: [Freeipa-users] AD users not getting single sign on (Solaris) In-Reply-To: <550B899A.6070008@redhat.com> References: <127387e6bc1ec1c0b2446eb9ded966da.squirrel@webmail.nathanpeters.com> <550B899A.6070008@redhat.com> Message-ID: <1a84670f27daed2cdac5c7e5c2e77e2f.squirrel@webmail.nathanpeters.com> > nathan at nathanpeters.com wrote: >> I have finally gotten all of my Solaris servers to accept AD users but >> the >> behavior is inconsistent. >> >> In my FreeIPA domain, I can login to a Linux server and then ssh to the >> Solaris server and I am automatically logged in because of my Kerberos >> ticket (I assume). >> >> But when I ssh from the first Solaris machine to the 2nd I am prompted >> for >> a password instead of being automatically signed in. The strange thing >> is >> that it doesn't matter which machine I login to first, it's only the 2nd >> hop that asks for a password. >> >> Below are my console recording. ipaclient1 is Linux, ipaclient5 and >> ipaclient6 are Solaris. >> Login from Linux -> Solaris 1 works without password >> Login from Linux -> Solaris 2 works without password >> Login from Solaris 1 -> Solaris 2 prompts >> Login from Solaris 2 -> Solaris 1 prompts. >> >> Any ideas? > > You log into Linux and get a TGT . Using that TGT you can log into any > other box (Solaris or otherwise). Unless you are delegating that TGT > with each ssh login you won't have one after the first login to another > system, it will be used for authentication only. > > See the -K option of ssh, or SSAPIDelegateCredentials yes in sshd. > > rob > Oh I see. Thank you, adding the Delegation line in my /etc/ssh/ssh_config fixed that. Two more questions: I seem to have to add the Delegation line in my Linux clients too. Dimitri's earlier answer seemed to indicate that the feature was automatic with the sssd but I still have to do -K or add the line to the config for it to work. Was he mistaken or was I interpreting his answer wrong? Second Question if you know... Does Solaris support host key identification the same way Linux does? I noticed that my Solaris hosts do not get SSHFP entries so I assume I could possible manually add the host keys and SSHFP entries for it, but there is not ssh_knownwhosts proxy on Solaris is there? From rcritten at redhat.com Fri Mar 20 21:23:19 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 20 Mar 2015 17:23:19 -0400 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> Message-ID: <550C8FC7.3060405@redhat.com> nathan at nathanpeters.com wrote: > I have FreeIPA installed on several types of Linux machines and they are > all experiencing strange issues with certificates and host keys. > Here is the setup: > > Server : FreeIPA 4.1.2 on Centos 7 > Client 1&2 : FreeIPA 3.0.0-42.el6 with sssd 1.11.6-30.el6_6.4 on CentOS 6.5 > Client 3&4 : FreeIPA 4.1.2-1.el7 on Centos 7 > > > First the FreeIPA clients running client 3.0.0 do not seem to be properly > getting their host keys from the server. Whenever I ssh from one client > to another (or even to the IPA server itself) I am prompted to answer yes > or no to the host key. The host keys are both listed in the host record > if I login to the domain controller web interface (and match what is on > the server), and the DNS SSHFP records exist also. > > # sss_ssh_authorizedkeys --debug 10 admin > (Fri Mar 20 13:43:52:706986 2015) [sss_ssh_authorizedkeys] [main] > (0x0020): sss_ssh_get_ent() failed (2): No such file or directory > Error looking up public keys > > I've seen some bug reports that this was a problem with sssd 1.10 but with > a recent (updated today) version of sssd 1.11 I would assume that is not > the issue? I think you'll need to wait for one of the SSSD guys on this one. strace might point the way if the error is happening on the user side of dbus. > The second issue is that whenver I join a FreeIPA 4.1.2 client, I can't > login with FreeIPA or AD users. I believe this is due to the fact that > when I login to the domain controller web interface and look at the > freshly enrolled client it says "kerberos key present, host provisioned" > but the next line is "Status No Valid Certificate". Unenrolling and > re-enrolling the client leads to the same issue with "No Valid > Certificate". > > Here is a grep of my client install log filtered for 'certificate'. I > don't see any errors. > 2015-03-20T20:33:28Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpuZCwlm' > '-A' '-n' 'CA certificate 1' '-t' 'C,,' > 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True > is_server=False > 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True > is_server=False > 2015-03-20T20:33:30Z DEBUG Adding CA certificates to the IPA NSS database. > 2015-03-20T20:33:32Z DEBUG Attempting to add CA certificates to the > default NSS database. > 2015-03-20T20:33:32Z INFO Added CA certificates to the default NSS database. > 2015-03-20T20:33:32Z DEBUG auth_certificate_callback: check_sig=True > is_server=False The host certificate is not used for anything so it isn't the problem. One is not obtained automatically in 4.1 any more. It wouldn't be used at login in any case. Did you disable the HBAC allow-all rule? I'd bump up the sssd debug level and check the logs. rob From dpal at redhat.com Fri Mar 20 21:24:12 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 17:24:12 -0400 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> Message-ID: <550C8FFC.4060102@redhat.com> On 03/20/2015 04:51 PM, nathan at nathanpeters.com wrote: > I have FreeIPA installed on several types of Linux machines and they are > all experiencing strange issues with certificates and host keys. > Here is the setup: > > Server : FreeIPA 4.1.2 on Centos 7 > Client 1&2 : FreeIPA 3.0.0-42.el6 with sssd 1.11.6-30.el6_6.4 on CentOS 6.5 > Client 3&4 : FreeIPA 4.1.2-1.el7 on Centos 7 > > > First the FreeIPA clients running client 3.0.0 do not seem to be properly > getting their host keys from the server. Whenever I ssh from one client > to another (or even to the IPA server itself) I am prompted to answer yes > or no to the host key. The host keys are both listed in the host record > if I login to the domain controller web interface (and match what is on > the server), and the DNS SSHFP records exist also. > > # sss_ssh_authorizedkeys --debug 10 admin > (Fri Mar 20 13:43:52:706986 2015) [sss_ssh_authorizedkeys] [main] > (0x0020): sss_ssh_get_ent() failed (2): No such file or directory > Error looking up public keys It seems that you might be missing the integration between sssd and ssh. Can you please check you configuration as described here: http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf > I've seen some bug reports that this was a problem with sssd 1.10 but with > a recent (updated today) version of sssd 1.11 I would assume that is not > the issue? > > The second issue is that whenver I join a FreeIPA 4.1.2 client, I can't > login with FreeIPA or AD users. I believe this is due to the fact that > when I login to the domain controller web interface and look at the > freshly enrolled client it says "kerberos key present, host provisioned" > but the next line is "Status No Valid Certificate". Unenrolling and > re-enrolling the client leads to the same issue with "No Valid > Certificate". > > Here is a grep of my client install log filtered for 'certificate'. I > don't see any errors. > 2015-03-20T20:33:28Z DEBUG args='/usr/bin/certutil' '-d' '/tmp/tmpuZCwlm' > '-A' '-n' 'CA certificate 1' '-t' 'C,,' > 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True > is_server=False > 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True > is_server=False > 2015-03-20T20:33:30Z DEBUG Adding CA certificates to the IPA NSS database. > 2015-03-20T20:33:32Z DEBUG Attempting to add CA certificates to the > default NSS database. > 2015-03-20T20:33:32Z INFO Added CA certificates to the default NSS database. > 2015-03-20T20:33:32Z DEBUG auth_certificate_callback: check_sig=True > is_server=False > > > This is because in 4.x we do not automatically provision a cert for the host any more. It was not used for anything. We provisioned it just in case it will be needed but it turns out it was not need and it was an extra step for no reason. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From roberto.cornacchia at gmail.com Fri Mar 20 21:28:53 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 22:28:53 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550C73D7.7060007@redhat.com> References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> Message-ID: It certainly gets there, because the client gets in fact enrolled as a domain host. I can see it from the UI in Identity / Hosts. But not in the DNS zone. *Before ipa-client-install, all these do work: * $ ssh ipa.hq.example.com $ ntpdate ipa.hq.example.com $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com uid=admin *After running ipa-client-install, all these do work:* $ kinit admin Password for admin at HQ.EXAMPLE.COM: $ ipa dnszone-show --all [...] $ ntpq -p remote refid st t when poll reach delay offset jitter ============================================================================== *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 -0.006 0.000 LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 0.000 *But this does NOT work:* $ getent passwd admin at hq.example.com *On the server, in /var/log/krb5kdc.log, I see many of these:* Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: admin at HQ.EXAMPLE.COM for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM, Additional pre-authentication required Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM for krbtgt/ HQ.EXAMPLE.COM at HQ.EXAMPLE.COM 192.168.0.207 is the IP of the client I'm trying to install. However, higher up in the log, I also see such errors for the ipa server itself. On 20 March 2015 at 20:24, Dmitri Pal wrote: > On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: > > No, all real machines. > > I'm really sorry it's taking so much of your time. > I had tried almost everything on a VM setting first, and everything was > fine. > Everything always works fine, until you actually need it. > > > > We try to help as much as we can. > Can you do LDAP lookups as a directory manager from client host to server? > Can you ssh from client to server? > > When you try to install client is there anything in the logs on the > server? Does it even get there? > > > > > > > On 20 March 2015 at 19:41, Dmitri Pal wrote: > >> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >> >> But the ipa server itself is also enrolled as a client, just after the >> server installation, right?. And that worked fine. >> >> >> Are these VMs? >> There have been a similar case when the network was not set properly for >> the virtual test environment. >> >> >> >> On 20 March 2015 at 18:55, Roberto Cornacchia < >> roberto.cornacchia at gmail.com> wrote: >> >>> No, sorry about the confusion, i shouldn't have posted so quickly. >>> >>> When I use the correct domain (hq.example.com), then I really get all >>> the same errors as before, also in the new client. >>> >>> >>> >>> On 20 Mar 2015 18:39, "Dmitri Pal" wrote: >>> >>>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>> >>>> Oops. Not true, forget last email. >>>> >>>> This secon client installation went different just because it took >>>> the wrong domain. >>>> It used *example.com * (what was previously set) >>>> instead of *hq.example.com * >>>> >>>> Uninstalled, tried again with --hostname=photon.hq.example.com >>>> And then it behaves precisely like the previous client. >>>> >>>> So something seems wrong in the server. >>>> >>>> On 20 March 2015 at 18:18, Roberto Cornacchia < >>>> roberto.cornacchia at gmail.com> wrote: >>>> >>>>> Update: >>>>> I tried from another client. Also FC21, same network, same settings >>>>> from the same DHCP. >>>>> But obviously it must have something different because it partially >>>>> succeeded. >>>>> >>>>> - I do not get errors about LDAP users. >>>>> - I do not get errors about DNS update >>>>> >>>>> However: >>>>> - I still get the initial error about NTP >>>>> - The host is enrolled, but not added to the DNS zone >>>>> >>>>> Now, I don't care much about the previous client. It was pretty much >>>>> empty and can re-install Fedora from scratch. >>>>> >>>>> But I'd like to understand if this is still a problem. >>>>> It should be added to the zone, shouldn't it? >>>>> >>>>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>>>> Discovery was successful! >>>>> Hostname: photon.example.com >>>>> Realm: HQ.EXAMPLE.COM >>>>> DNS Domain: hq.example.com >>>>> IPA Server: ipa.hq.example.com >>>>> BaseDN: dc=hq,dc=example,dc=com >>>>> >>>>> Continue to configure the system with these values? [no]: yes >>>>> Synchronizing time with KDC... >>>>> *Unable to sync time with IPA NTP server, assuming the time is in >>>>> sync. Please check that 123 UDP port is opened.* >>>>> User authorized to enroll computers: admin >>>>> Password for admin at HQ.EXAMPLE.COM: >>>>> Successfully retrieved CA cert >>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>> >>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>> 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 HQ.EXAMPLE.COM >>>>> trying https://ipa.hq.example.com/ipa/json >>>>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' >>>>> Forwarding 'ca_is_enabled' to json server ' >>>>> https://ipa.hq.example.com/ipa/json' >>>>> Systemwide CA database updated. >>>>> Added CA certificates to the default NSS database. >>>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>>> Forwarding 'host_mod' to json server ' >>>>> https://ipa.hq.example.com/ipa/json' >>>>> *Could not update DNS SSHFP records.* >>>>> SSSD enabled >>>>> Configured /etc/openldap/ldap.conf >>>>> NTP enabled >>>>> Configured /etc/ssh/ssh_config >>>>> Configured /etc/ssh/sshd_config >>>>> Configuring hq.example.com as NIS domain. >>>>> Client configuration complete. >>>>> >>>>> >>>> >>>> >>>> >>>> It is different. It does not have the same failure about admin as you >>>> had in the first email. >>>> So may be it is the permissions issue and a separate NTP issue? >>>> Did you play with any permissions on the server side? >>>> >>>> >>>> -- >>>> 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. >> >> >> -- >> 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. > > > -- > 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 Fri Mar 20 21:33:42 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 17:33:42 -0400 Subject: [Freeipa-users] AD users not getting single sign on (Solaris) In-Reply-To: <1a84670f27daed2cdac5c7e5c2e77e2f.squirrel@webmail.nathanpeters.com> References: <127387e6bc1ec1c0b2446eb9ded966da.squirrel@webmail.nathanpeters.com> <550B899A.6070008@redhat.com> <1a84670f27daed2cdac5c7e5c2e77e2f.squirrel@webmail.nathanpeters.com> Message-ID: <550C9236.2000304@redhat.com> On 03/20/2015 05:23 PM, nathan at nathanpeters.com wrote: >> nathan at nathanpeters.com wrote: >>> I have finally gotten all of my Solaris servers to accept AD users but >>> the >>> behavior is inconsistent. >>> >>> In my FreeIPA domain, I can login to a Linux server and then ssh to the >>> Solaris server and I am automatically logged in because of my Kerberos >>> ticket (I assume). >>> >>> But when I ssh from the first Solaris machine to the 2nd I am prompted >>> for >>> a password instead of being automatically signed in. The strange thing >>> is >>> that it doesn't matter which machine I login to first, it's only the 2nd >>> hop that asks for a password. >>> >>> Below are my console recording. ipaclient1 is Linux, ipaclient5 and >>> ipaclient6 are Solaris. >>> Login from Linux -> Solaris 1 works without password >>> Login from Linux -> Solaris 2 works without password >>> Login from Solaris 1 -> Solaris 2 prompts >>> Login from Solaris 2 -> Solaris 1 prompts. >>> >>> Any ideas? >> You log into Linux and get a TGT . Using that TGT you can log into any >> other box (Solaris or otherwise). Unless you are delegating that TGT >> with each ssh login you won't have one after the first login to another >> system, it will be used for authentication only. >> >> See the -K option of ssh, or SSAPIDelegateCredentials yes in sshd. >> >> rob >> > Oh I see. Thank you, adding the Delegation line in my /etc/ssh/ssh_config > fixed that. > > Two more questions: > I seem to have to add the Delegation line in my Linux clients too. > Dimitri's earlier answer seemed to indicate that the feature was automatic > with the sssd but I still have to do -K or add the line to the config for > it to work. Was he mistaken or was I interpreting his answer wrong? What I meant to say is that SSSD does kerberos by default. It does not delegate by default. So you can hop once. On Solaris you can't hop at all because there is no Kerberos, the auth is done using LDAP. > > Second Question if you know... > Does Solaris support host key identification the same way Linux does? I > noticed that my Solaris hosts do not get SSHFP entries so I assume I could > possible manually add the host keys and SSHFP entries for it, but there is > not ssh_knownwhosts proxy on Solaris is there? I do not know. > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Fri Mar 20 21:37:09 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 17:37:09 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> Message-ID: <550C9305.90900@redhat.com> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: > It certainly gets there, because the client gets in fact enrolled as a > domain host. I can see it from the UI in Identity / Hosts. But not in > the DNS zone. > > *Before ipa-client-install, all these do work: * > > $ ssh ipa.hq.example.com > $ ntpdate ipa.hq.example.com > $ ldapsearch -x -h ipa.hq.example.com -b > dc=hq,dc=example,dc=com uid=admin > > > *After running ipa-client-install, all these do work:* > > $ kinit admin > Password for admin at HQ.EXAMPLE.COM : > $ ipa dnszone-show --all > [...] > $ ntpq -p > remote refid st t when poll reach delay offset jitter > ============================================================================== > *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 -0.006 > 0.000 > LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 > 0.000 > > *But this does NOT work:* > $ getent passwd admin at hq.example.com What do SSSD logs show on the client? Please rise the SSSD debug_level and provide SSSD logs. > > *On the server, in /var/log/krb5kdc.log, I see many of these:* > > Mar 20 21:53:17 ipa.hq.example.com > krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) > 192.168.0.207 : NEEDED_PREAUTH: > admin at HQ.EXAMPLE.COM for > krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM , > Additional pre-authentication required > Mar 20 21:53:17 ipa.hq.example.com > krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) > 192.168.0.207 : ISSUE: authtime 1426884797, > etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM > for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM > This is not an error. It is a normal user authentication. OK so it is DNS that is not working. Is DNS server running on the server? What do Bind logs show? > > 192.168.0.207 is the IP of the client I'm trying to install. However, > higher up in the log, I also see such errors for the ipa server itself. > > On 20 March 2015 at 20:24, Dmitri Pal > wrote: > > On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >> No, all real machines. >> >> I'm really sorry it's taking so much of your time. >> I had tried almost everything on a VM setting first, and >> everything was fine. >> Everything always works fine, until you actually need it. > > > We try to help as much as we can. > Can you do LDAP lookups as a directory manager from client host to > server? > Can you ssh from client to server? > > When you try to install client is there anything in the logs on > the server? Does it even get there? > > > > >> >> >> On 20 March 2015 at 19:41, Dmitri Pal > > wrote: >> >> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>> But the ipa server itself is also enrolled as a client, just >>> after the server installation, right?. And that worked fine. >> >> Are these VMs? >> There have been a similar case when the network was not set >> properly for the virtual test environment. >> >> >>> >>> On 20 March 2015 at 18:55, Roberto Cornacchia >>> >> > wrote: >>> >>> No, sorry about the confusion, i shouldn't have posted >>> so quickly. >>> >>> When I use the correct domain (hq.example.com >>> ), then I really get all the same >>> errors as before, also in the new client. >>> >>> >>> >>> On 20 Mar 2015 18:39, "Dmitri Pal" >> > wrote: >>> >>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>> Oops. Not true, forget last email. >>>> >>>> This secon client installation went different just >>>> because it took the wrong domain. >>>> It used *example.com * (what >>>> was previously set) instead of *hq.example.com >>>> * >>>> >>>> Uninstalled, tried again with >>>> --hostname=photon.hq.example.com >>>> >>>> And then it behaves precisely like the previous client. >>>> >>>> So something seems wrong in the server. >>>> >>>> On 20 March 2015 at 18:18, Roberto Cornacchia >>>> >>> > wrote: >>>> >>>> Update: >>>> I tried from another client. Also FC21, same >>>> network, same settings from the same DHCP. >>>> But obviously it must have something different >>>> because it partially succeeded. >>>> >>>> - I do not get errors about LDAP users. >>>> - I do not get errors about DNS update >>>> >>>> However: >>>> - I still get the initial error about NTP >>>> - The host is enrolled, but not added to the >>>> DNS zone >>>> >>>> Now, I don't care much about the previous >>>> client. It was pretty much empty and can >>>> re-install Fedora from scratch. >>>> >>>> But I'd like to understand if this is still a >>>> problem. >>>> It should be added to the zone, shouldn't it? >>>> >>>> $ ipa-client-install --mkhomedir >>>> --ssh-trust-dns --force-ntpd >>>> Discovery was successful! >>>> Hostname: photon.example.com >>>> >>>> Realm: HQ.EXAMPLE.COM >>>> DNS Domain: hq.example.com >>>> IPA Server: ipa.hq.example.com >>>> >>>> BaseDN: dc=hq,dc=example,dc=com >>>> >>>> Continue to configure the system with these >>>> values? [no]: yes >>>> Synchronizing time with KDC... >>>> *Unable to sync time with IPA NTP server, >>>> assuming the time is in sync. Please check that >>>> 123 UDP port is opened.* >>>> User authorized to enroll computers: admin >>>> Password for admin at HQ.EXAMPLE.COM >>>> : >>>> Successfully retrieved CA cert >>>> Subject: CN=Certificate >>>> Authority,O=HQ.EXAMPLE.COM >>>> Issuer: CN=Certificate >>>> Authority,O=HQ.EXAMPLE.COM >>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>> >>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>> >>>> 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 >>>> HQ.EXAMPLE.COM >>>> trying https://ipa.hq.example.com/ipa/json >>>> Forwarding 'ping' to json server >>>> 'https://ipa.hq.example.com/ipa/json' >>>> Forwarding 'ca_is_enabled' to json server >>>> 'https://ipa.hq.example.com/ipa/json' >>>> Systemwide CA database updated. >>>> Added CA certificates to the default NSS database. >>>> Adding SSH public key from >>>> /etc/ssh/ssh_host_rsa_key.pub >>>> Adding SSH public key from >>>> /etc/ssh/ssh_host_ed25519_key.pub >>>> Adding SSH public key from >>>> /etc/ssh/ssh_host_dsa_key.pub >>>> Adding SSH public key from >>>> /etc/ssh/ssh_host_ecdsa_key.pub >>>> Forwarding 'host_mod' to json server >>>> 'https://ipa.hq.example.com/ipa/json' >>>> *Could not update DNS SSHFP records.* >>>> SSSD enabled >>>> Configured /etc/openldap/ldap.conf >>>> NTP enabled >>>> Configured /etc/ssh/ssh_config >>>> Configured /etc/ssh/sshd_config >>>> Configuring hq.example.com >>>> as NIS domain. >>>> Client configuration complete. >>>> >>>> >>>> >>>> >>> >>> It is different. It does not have the same failure >>> about admin as you had in the first email. >>> So may be it is the permissions issue and a separate >>> NTP issue? >>> Did you play with any permissions on the server side? >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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 roberto.cornacchia at gmail.com Fri Mar 20 21:59:36 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Fri, 20 Mar 2015 22:59:36 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550C9305.90900@redhat.com> References: <550B37DF.9000504@redhat.com> <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> Message-ID: SSSD logs are empty so far. Isn't sssd.conf written by ipa-client-install? If I raise the debug level after client installation, what activities do you suggest to attempt from the client? On 20 March 2015 at 22:37, Dmitri Pal wrote: > On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: > > It certainly gets there, because the client gets in fact enrolled as a > domain host. I can see it from the UI in Identity / Hosts. But not in the > DNS zone. > > *Before ipa-client-install, all these do work: * > > $ ssh ipa.hq.example.com > $ ntpdate ipa.hq.example.com > $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com uid=admin > > > *After running ipa-client-install, all these do work:* > > $ kinit admin > Password for admin at HQ.EXAMPLE.COM: > $ ipa dnszone-show --all > [...] > $ ntpq -p > remote refid st t when poll reach delay offset > jitter > > ============================================================================== > *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 -0.006 > 0.000 > LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 > 0.000 > > *But this does NOT work:* > $ getent passwd admin at hq.example.com > > > What do SSSD logs show on the client? > Please rise the SSSD debug_level and provide SSSD logs. > > > *On the server, in /var/log/krb5kdc.log, I see many of these:* > > Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: admin at HQ.EXAMPLE.COM > for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM, Additional pre-authentication > required > Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes > {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes > {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM for krbtgt/ > HQ.EXAMPLE.COM at HQ.EXAMPLE.COM > > > This is not an error. It is a normal user authentication. > OK so it is DNS that is not working. Is DNS server running on the server? > What do Bind logs show? > > > > 192.168.0.207 is the IP of the client I'm trying to install. However, > higher up in the log, I also see such errors for the ipa server itself. > > On 20 March 2015 at 20:24, Dmitri Pal wrote: > >> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >> >> No, all real machines. >> >> I'm really sorry it's taking so much of your time. >> I had tried almost everything on a VM setting first, and everything was >> fine. >> Everything always works fine, until you actually need it. >> >> >> >> We try to help as much as we can. >> Can you do LDAP lookups as a directory manager from client host to server? >> Can you ssh from client to server? >> >> When you try to install client is there anything in the logs on the >> server? Does it even get there? >> >> >> >> >> >> >> On 20 March 2015 at 19:41, Dmitri Pal wrote: >> >>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>> >>> But the ipa server itself is also enrolled as a client, just after the >>> server installation, right?. And that worked fine. >>> >>> >>> Are these VMs? >>> There have been a similar case when the network was not set properly for >>> the virtual test environment. >>> >>> >>> >>> On 20 March 2015 at 18:55, Roberto Cornacchia < >>> roberto.cornacchia at gmail.com> wrote: >>> >>>> No, sorry about the confusion, i shouldn't have posted so quickly. >>>> >>>> When I use the correct domain (hq.example.com), then I really get all >>>> the same errors as before, also in the new client. >>>> >>>> >>>> >>>> On 20 Mar 2015 18:39, "Dmitri Pal" wrote: >>>> >>>>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>>> >>>>> Oops. Not true, forget last email. >>>>> >>>>> This secon client installation went different just because it took >>>>> the wrong domain. >>>>> It used *example.com * (what was previously set) >>>>> instead of *hq.example.com * >>>>> >>>>> Uninstalled, tried again with --hostname=photon.hq.example.com >>>>> And then it behaves precisely like the previous client. >>>>> >>>>> So something seems wrong in the server. >>>>> >>>>> On 20 March 2015 at 18:18, Roberto Cornacchia < >>>>> roberto.cornacchia at gmail.com> wrote: >>>>> >>>>>> Update: >>>>>> I tried from another client. Also FC21, same network, same settings >>>>>> from the same DHCP. >>>>>> But obviously it must have something different because it partially >>>>>> succeeded. >>>>>> >>>>>> - I do not get errors about LDAP users. >>>>>> - I do not get errors about DNS update >>>>>> >>>>>> However: >>>>>> - I still get the initial error about NTP >>>>>> - The host is enrolled, but not added to the DNS zone >>>>>> >>>>>> Now, I don't care much about the previous client. It was pretty >>>>>> much empty and can re-install Fedora from scratch. >>>>>> >>>>>> But I'd like to understand if this is still a problem. >>>>>> It should be added to the zone, shouldn't it? >>>>>> >>>>>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>>>>> Discovery was successful! >>>>>> Hostname: photon.example.com >>>>>> Realm: HQ.EXAMPLE.COM >>>>>> DNS Domain: hq.example.com >>>>>> IPA Server: ipa.hq.example.com >>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>> >>>>>> Continue to configure the system with these values? [no]: yes >>>>>> Synchronizing time with KDC... >>>>>> *Unable to sync time with IPA NTP server, assuming the time is in >>>>>> sync. Please check that 123 UDP port is opened.* >>>>>> User authorized to enroll computers: admin >>>>>> Password for admin at HQ.EXAMPLE.COM: >>>>>> Successfully retrieved CA cert >>>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>>> >>>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>>> 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 HQ.EXAMPLE.COM >>>>>> trying https://ipa.hq.example.com/ipa/json >>>>>> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json >>>>>> ' >>>>>> Forwarding 'ca_is_enabled' to json server ' >>>>>> https://ipa.hq.example.com/ipa/json' >>>>>> Systemwide CA database updated. >>>>>> Added CA certificates to the default NSS database. >>>>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>>>> Forwarding 'host_mod' to json server ' >>>>>> https://ipa.hq.example.com/ipa/json' >>>>>> *Could not update DNS SSHFP records.* >>>>>> SSSD enabled >>>>>> Configured /etc/openldap/ldap.conf >>>>>> NTP enabled >>>>>> Configured /etc/ssh/ssh_config >>>>>> Configured /etc/ssh/sshd_config >>>>>> Configuring hq.example.com as NIS domain. >>>>>> Client configuration complete. >>>>>> >>>>>> >>>>> >>>>> >>>>> >>>>> It is different. It does not have the same failure about admin as you >>>>> had in the first email. >>>>> So may be it is the permissions issue and a separate NTP issue? >>>>> Did you play with any permissions on the server side? >>>>> >>>>> >>>>> -- >>>>> 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. >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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 Fri Mar 20 22:03:19 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 18:03:19 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> Message-ID: <550C9927.1040308@redhat.com> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: > SSSD logs are empty so far. This is wrong. > Isn't sssd.conf written by ipa-client-install? Yes > If I raise the debug level after client installation, (and restart) > what activities do you suggest to attempt from the client? the ones that fail. getent call that returns nothing. Also try 'id'. http://www.freeipa.org/page/Troubleshooting#Client_Installation https://fedorahosted.org/sssd/wiki/Troubleshooting > > > On 20 March 2015 at 22:37, Dmitri Pal > wrote: > > On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >> It certainly gets there, because the client gets in fact enrolled >> as a domain host. I can see it from the UI in Identity / Hosts. >> But not in the DNS zone. >> >> *Before ipa-client-install, all these do work: * >> >> $ ssh ipa.hq.example.com >> $ ntpdate ipa.hq.example.com >> $ ldapsearch -x -h ipa.hq.example.com >> -b dc=hq,dc=example,dc=com uid=admin >> >> >> *After running ipa-client-install, all these do work:* >> >> $ kinit admin >> Password for admin at HQ.EXAMPLE.COM : >> $ ipa dnszone-show --all >> [...] >> $ ntpq -p >> remote refid st t when poll reach delay >> offset jitter >> ============================================================================== >> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 >> -0.006 0.000 >> LOCAL(0) .LOCL. 5 l - 64 0 0.000 >> 0.000 0.000 >> >> *But this does NOT work:* >> $ getent passwd admin at hq.example.com > > What do SSSD logs show on the client? > Please rise the SSSD debug_level and provide SSSD logs. > >> >> *On the server, in /var/log/krb5kdc.log, I see many of these:* >> >> Mar 20 21:53:17 ipa.hq.example.com >> krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) >> 192.168.0.207 : NEEDED_PREAUTH: >> admin at HQ.EXAMPLE.COM for >> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM , >> Additional pre-authentication required >> Mar 20 21:53:17 ipa.hq.example.com >> krb5kdc[9229](info): AS_REQ (6 etypes {18 17 16 23 25 26}) >> 192.168.0.207 : ISSUE: authtime 1426884797, >> etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM >> for >> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >> > > This is not an error. It is a normal user authentication. > OK so it is DNS that is not working. Is DNS server running on the > server? > What do Bind logs show? > > >> >> 192.168.0.207 is the IP of the client I'm trying to install. >> However, higher up in the log, I also see such errors for the ipa >> server itself. >> >> On 20 March 2015 at 20:24, Dmitri Pal > > wrote: >> >> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>> No, all real machines. >>> >>> I'm really sorry it's taking so much of your time. >>> I had tried almost everything on a VM setting first, and >>> everything was fine. >>> Everything always works fine, until you actually need it. >> >> >> We try to help as much as we can. >> Can you do LDAP lookups as a directory manager from client >> host to server? >> Can you ssh from client to server? >> >> When you try to install client is there anything in the logs >> on the server? Does it even get there? >> >> >> >> >>> >>> >>> On 20 March 2015 at 19:41, Dmitri Pal >> > wrote: >>> >>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>>> But the ipa server itself is also enrolled as a client, >>>> just after the server installation, right?. And that >>>> worked fine. >>> >>> Are these VMs? >>> There have been a similar case when the network was not >>> set properly for the virtual test environment. >>> >>> >>>> >>>> On 20 March 2015 at 18:55, Roberto Cornacchia >>>> >>> > wrote: >>>> >>>> No, sorry about the confusion, i shouldn't have >>>> posted so quickly. >>>> >>>> When I use the correct domain (hq.example.com >>>> ), then I really get all the >>>> same errors as before, also in the new client. >>>> >>>> >>>> >>>> On 20 Mar 2015 18:39, "Dmitri Pal" >>> > wrote: >>>> >>>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>>> Oops. Not true, forget last email. >>>>> >>>>> This secon client installation went different >>>>> just because it took the wrong domain. >>>>> It used *example.com >>>>> * (what was previously >>>>> set) instead of *hq.example.com >>>>> * >>>>> >>>>> Uninstalled, tried again with >>>>> --hostname=photon.hq.example.com >>>>> >>>>> And then it behaves precisely like the >>>>> previous client. >>>>> >>>>> So something seems wrong in the server. >>>>> >>>>> On 20 March 2015 at 18:18, Roberto Cornacchia >>>>> >>>> > wrote: >>>>> >>>>> Update: >>>>> I tried from another client. Also FC21, >>>>> same network, same settings from the same >>>>> DHCP. >>>>> But obviously it must have something >>>>> different because it partially succeeded. >>>>> >>>>> - I do not get errors about LDAP users. >>>>> - I do not get errors about DNS update >>>>> >>>>> However: >>>>> - I still get the initial error about NTP >>>>> - The host is enrolled, but not added to >>>>> the DNS zone >>>>> >>>>> Now, I don't care much about the previous >>>>> client. It was pretty much empty and can >>>>> re-install Fedora from scratch. >>>>> >>>>> But I'd like to understand if this is >>>>> still a problem. >>>>> It should be added to the zone, shouldn't it? >>>>> >>>>> $ ipa-client-install --mkhomedir >>>>> --ssh-trust-dns --force-ntpd >>>>> Discovery was successful! >>>>> Hostname: photon.example.com >>>>> >>>>> Realm: HQ.EXAMPLE.COM >>>>> DNS Domain: hq.example.com >>>>> >>>>> IPA Server: ipa.hq.example.com >>>>> >>>>> BaseDN: dc=hq,dc=example,dc=com >>>>> >>>>> Continue to configure the system with >>>>> these values? [no]: yes >>>>> Synchronizing time with KDC... >>>>> *Unable to sync time with IPA NTP server, >>>>> assuming the time is in sync. Please check >>>>> that 123 UDP port is opened.* >>>>> User authorized to enroll computers: admin >>>>> Password for admin at HQ.EXAMPLE.COM >>>>> : >>>>> Successfully retrieved CA cert >>>>> Subject: CN=Certificate >>>>> Authority,O=HQ.EXAMPLE.COM >>>>> >>>>> Issuer: CN=Certificate >>>>> Authority,O=HQ.EXAMPLE.COM >>>>> >>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>> >>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>> >>>>> 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 >>>>> HQ.EXAMPLE.COM >>>>> trying https://ipa.hq.example.com/ipa/json >>>>> Forwarding 'ping' to json server >>>>> 'https://ipa.hq.example.com/ipa/json' >>>>> Forwarding 'ca_is_enabled' to json server >>>>> 'https://ipa.hq.example.com/ipa/json' >>>>> Systemwide CA database updated. >>>>> Added CA certificates to the default NSS >>>>> database. >>>>> Adding SSH public key from >>>>> /etc/ssh/ssh_host_rsa_key.pub >>>>> Adding SSH public key from >>>>> /etc/ssh/ssh_host_ed25519_key.pub >>>>> Adding SSH public key from >>>>> /etc/ssh/ssh_host_dsa_key.pub >>>>> Adding SSH public key from >>>>> /etc/ssh/ssh_host_ecdsa_key.pub >>>>> Forwarding 'host_mod' to json server >>>>> 'https://ipa.hq.example.com/ipa/json' >>>>> *Could not update DNS SSHFP records.* >>>>> SSSD enabled >>>>> Configured /etc/openldap/ldap.conf >>>>> NTP enabled >>>>> Configured /etc/ssh/ssh_config >>>>> Configured /etc/ssh/sshd_config >>>>> Configuring hq.example.com >>>>> as NIS domain. >>>>> Client configuration complete. >>>>> >>>>> >>>>> >>>>> >>>> >>>> It is different. It does not have the same >>>> failure about admin as you had in the first email. >>>> So may be it is the permissions issue and a >>>> separate NTP issue? >>>> Did you play with any permissions on the server >>>> side? >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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 nathan at nathanpeters.com Fri Mar 20 22:45:19 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 20 Mar 2015 15:45:19 -0700 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <550C8FC7.3060405@redhat.com> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> <550C8FC7.3060405@redhat.com> Message-ID: <23dcce196ff00754c7f332a39eb5bec1.squirrel@webmail.nathanpeters.com> > nathan at nathanpeters.com wrote: >> I have FreeIPA installed on several types of Linux machines and they are >> all experiencing strange issues with certificates and host keys. >> Here is the setup: >> >> Server : FreeIPA 4.1.2 on Centos 7 >> Client 1&2 : FreeIPA 3.0.0-42.el6 with sssd 1.11.6-30.el6_6.4 on CentOS >> 6.5 >> Client 3&4 : FreeIPA 4.1.2-1.el7 on Centos 7 >> >> >> First the FreeIPA clients running client 3.0.0 do not seem to be >> properly >> getting their host keys from the server. Whenever I ssh from one client >> to another (or even to the IPA server itself) I am prompted to answer >> yes >> or no to the host key. The host keys are both listed in the host record >> if I login to the domain controller web interface (and match what is on >> the server), and the DNS SSHFP records exist also. >> >> # sss_ssh_authorizedkeys --debug 10 admin >> (Fri Mar 20 13:43:52:706986 2015) [sss_ssh_authorizedkeys] [main] >> (0x0020): sss_ssh_get_ent() failed (2): No such file or directory >> Error looking up public keys >> >> I've seen some bug reports that this was a problem with sssd 1.10 but >> with >> a recent (updated today) version of sssd 1.11 I would assume that is not >> the issue? > > I think you'll need to wait for one of the SSSD guys on this one. strace > might point the way if the error is happening on the user side of dbus. > >> The second issue is that whenver I join a FreeIPA 4.1.2 client, I can't >> login with FreeIPA or AD users. I believe this is due to the fact that >> when I login to the domain controller web interface and look at the >> freshly enrolled client it says "kerberos key present, host provisioned" >> but the next line is "Status No Valid Certificate". Unenrolling and >> re-enrolling the client leads to the same issue with "No Valid >> Certificate". >> >> Here is a grep of my client install log filtered for 'certificate'. I >> don't see any errors. >> 2015-03-20T20:33:28Z DEBUG args='/usr/bin/certutil' '-d' >> '/tmp/tmpuZCwlm' >> '-A' '-n' 'CA certificate 1' '-t' 'C,,' >> 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True >> is_server=False >> 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True >> is_server=False >> 2015-03-20T20:33:30Z DEBUG Adding CA certificates to the IPA NSS >> database. >> 2015-03-20T20:33:32Z DEBUG Attempting to add CA certificates to the >> default NSS database. >> 2015-03-20T20:33:32Z INFO Added CA certificates to the default NSS >> database. >> 2015-03-20T20:33:32Z DEBUG auth_certificate_callback: check_sig=True >> is_server=False > > The host certificate is not used for anything so it isn't the problem. > One is not obtained automatically in 4.1 any more. It wouldn't be used > at login in any case. > > Did you disable the HBAC allow-all rule? > > I'd bump up the sssd debug level and check the logs. > > rob > > Oh I realized that I can login to either of the 4.x clients from a windows machine, but once on the 4.x client itself if I try to ssh off the machine to either a 3.x or a 4.x client, I get : $ ssh ipaclient4-sandbox-atdev-van ssh_exchange_identification: Connection closed by remote host From roberto.cornacchia at gmail.com Fri Mar 20 23:40:35 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Sat, 21 Mar 2015 00:40:35 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550C9927.1040308@redhat.com> References: <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> Message-ID: Two log files in attachment (the other files in /var/log/sssd are all empty). I'll also go through the troubleshooting page again, thanks On 20 March 2015 at 23:03, Dmitri Pal wrote: > On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: > > SSSD logs are empty so far. > > > This is wrong. > > Isn't sssd.conf written by ipa-client-install? > > > Yes > > If I raise the debug level after client installation, > > > (and restart) > > what activities do you suggest to attempt from the client? > > the ones that fail. getent call that returns nothing. > Also try 'id'. > > http://www.freeipa.org/page/Troubleshooting#Client_Installation > https://fedorahosted.org/sssd/wiki/Troubleshooting > > > > On 20 March 2015 at 22:37, Dmitri Pal wrote: > >> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >> >> It certainly gets there, because the client gets in fact enrolled as a >> domain host. I can see it from the UI in Identity / Hosts. But not in the >> DNS zone. >> >> *Before ipa-client-install, all these do work: * >> >> $ ssh ipa.hq.example.com >> $ ntpdate ipa.hq.example.com >> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com >> uid=admin >> >> >> *After running ipa-client-install, all these do work:* >> >> $ kinit admin >> Password for admin at HQ.EXAMPLE.COM: >> $ ipa dnszone-show --all >> [...] >> $ ntpq -p >> remote refid st t when poll reach delay offset >> jitter >> >> ============================================================================== >> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 -0.006 >> 0.000 >> LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 >> 0.000 >> >> *But this does NOT work:* >> $ getent passwd admin at hq.example.com >> >> >> What do SSSD logs show on the client? >> Please rise the SSSD debug_level and provide SSSD logs. >> >> >> *On the server, in /var/log/krb5kdc.log, I see many of these:* >> >> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: >> admin at HQ.EXAMPLE.COM for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM, >> Additional pre-authentication required >> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 etypes >> {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, etypes >> {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM for krbtgt/ >> HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >> >> >> This is not an error. It is a normal user authentication. >> OK so it is DNS that is not working. Is DNS server running on the server? >> What do Bind logs show? >> >> >> >> 192.168.0.207 is the IP of the client I'm trying to install. However, >> higher up in the log, I also see such errors for the ipa server itself. >> >> On 20 March 2015 at 20:24, Dmitri Pal wrote: >> >>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>> >>> No, all real machines. >>> >>> I'm really sorry it's taking so much of your time. >>> I had tried almost everything on a VM setting first, and everything was >>> fine. >>> Everything always works fine, until you actually need it. >>> >>> >>> >>> We try to help as much as we can. >>> Can you do LDAP lookups as a directory manager from client host to >>> server? >>> Can you ssh from client to server? >>> >>> When you try to install client is there anything in the logs on the >>> server? Does it even get there? >>> >>> >>> >>> >>> >>> >>> On 20 March 2015 at 19:41, Dmitri Pal wrote: >>> >>>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>>> >>>> But the ipa server itself is also enrolled as a client, just after the >>>> server installation, right?. And that worked fine. >>>> >>>> >>>> Are these VMs? >>>> There have been a similar case when the network was not set properly >>>> for the virtual test environment. >>>> >>>> >>>> >>>> On 20 March 2015 at 18:55, Roberto Cornacchia < >>>> roberto.cornacchia at gmail.com> wrote: >>>> >>>>> No, sorry about the confusion, i shouldn't have posted so quickly. >>>>> >>>>> When I use the correct domain (hq.example.com), then I really get all >>>>> the same errors as before, also in the new client. >>>>> >>>>> >>>>> >>>>> On 20 Mar 2015 18:39, "Dmitri Pal" wrote: >>>>> >>>>>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>>>> >>>>>> Oops. Not true, forget last email. >>>>>> >>>>>> This secon client installation went different just because it took >>>>>> the wrong domain. >>>>>> It used *example.com * (what was previously set) >>>>>> instead of *hq.example.com * >>>>>> >>>>>> Uninstalled, tried again with --hostname=photon.hq.example.com >>>>>> And then it behaves precisely like the previous client. >>>>>> >>>>>> So something seems wrong in the server. >>>>>> >>>>>> On 20 March 2015 at 18:18, Roberto Cornacchia < >>>>>> roberto.cornacchia at gmail.com> wrote: >>>>>> >>>>>>> Update: >>>>>>> I tried from another client. Also FC21, same network, same settings >>>>>>> from the same DHCP. >>>>>>> But obviously it must have something different because it partially >>>>>>> succeeded. >>>>>>> >>>>>>> - I do not get errors about LDAP users. >>>>>>> - I do not get errors about DNS update >>>>>>> >>>>>>> However: >>>>>>> - I still get the initial error about NTP >>>>>>> - The host is enrolled, but not added to the DNS zone >>>>>>> >>>>>>> Now, I don't care much about the previous client. It was pretty >>>>>>> much empty and can re-install Fedora from scratch. >>>>>>> >>>>>>> But I'd like to understand if this is still a problem. >>>>>>> It should be added to the zone, shouldn't it? >>>>>>> >>>>>>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>>>>>> Discovery was successful! >>>>>>> Hostname: photon.example.com >>>>>>> Realm: HQ.EXAMPLE.COM >>>>>>> DNS Domain: hq.example.com >>>>>>> IPA Server: ipa.hq.example.com >>>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>>> >>>>>>> Continue to configure the system with these values? [no]: yes >>>>>>> Synchronizing time with KDC... >>>>>>> *Unable to sync time with IPA NTP server, assuming the time is in >>>>>>> sync. Please check that 123 UDP port is opened.* >>>>>>> User authorized to enroll computers: admin >>>>>>> Password for admin at HQ.EXAMPLE.COM: >>>>>>> Successfully retrieved CA cert >>>>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>>>> >>>>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>>>> 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 HQ.EXAMPLE.COM >>>>>>> trying https://ipa.hq.example.com/ipa/json >>>>>>> Forwarding 'ping' to json server ' >>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>> Forwarding 'ca_is_enabled' to json server ' >>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>> Systemwide CA database updated. >>>>>>> Added CA certificates to the default NSS database. >>>>>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>>>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>>>>> Forwarding 'host_mod' to json server ' >>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>> *Could not update DNS SSHFP records.* >>>>>>> SSSD enabled >>>>>>> Configured /etc/openldap/ldap.conf >>>>>>> NTP enabled >>>>>>> Configured /etc/ssh/ssh_config >>>>>>> Configured /etc/ssh/sshd_config >>>>>>> Configuring hq.example.com as NIS domain. >>>>>>> Client configuration complete. >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> It is different. It does not have the same failure about admin as you >>>>>> had in the first email. >>>>>> So may be it is the permissions issue and a separate NTP issue? >>>>>> Did you play with any permissions on the server side? >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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 -------------- A non-text attachment was scrubbed... Name: ldap_child.log Type: application/octet-stream Size: 9170 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: sssd_hq.example.com.log Type: application/octet-stream Size: 138939 bytes Desc: not available URL: From nathan at nathanpeters.com Fri Mar 20 23:41:03 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 20 Mar 2015 16:41:03 -0700 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <550C8FFC.4060102@redhat.com> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> <550C8FFC.4060102@redhat.com> Message-ID: <5fe92a2cd252072f537a863d564dc1e8.squirrel@webmail.nathanpeters.com> > On 03/20/2015 04:51 PM, nathan at nathanpeters.com wrote: >> I have FreeIPA installed on several types of Linux machines and they are >> all experiencing strange issues with certificates and host keys. >> Here is the setup: >> >> Server : FreeIPA 4.1.2 on Centos 7 >> Client 1&2 : FreeIPA 3.0.0-42.el6 with sssd 1.11.6-30.el6_6.4 on CentOS >> 6.5 >> Client 3&4 : FreeIPA 4.1.2-1.el7 on Centos 7 >> >> >> First the FreeIPA clients running client 3.0.0 do not seem to be >> properly >> getting their host keys from the server. Whenever I ssh from one client >> to another (or even to the IPA server itself) I am prompted to answer >> yes >> or no to the host key. The host keys are both listed in the host record >> if I login to the domain controller web interface (and match what is on >> the server), and the DNS SSHFP records exist also. >> >> # sss_ssh_authorizedkeys --debug 10 admin >> (Fri Mar 20 13:43:52:706986 2015) [sss_ssh_authorizedkeys] [main] >> (0x0020): sss_ssh_get_ent() failed (2): No such file or directory >> Error looking up public keys > > It seems that you might be missing the integration between sssd and ssh. > Can you please check you configuration as described here: > http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf > Actually this was the problem : I had added the following line to the [sssd] section of sssd.conf : [sssd] default_domain_suffix = addomain.net The reason I had added this is because our business asked if our active directory trusted users can be allowed to login without entering their fqdn. Setting the default_domain_suffix allows them to just login as 'aduser' instead of 'aduser at addomain.net'. However, this apparently breaks host key checking. Turning debugging on the sssd up to 9 revealed that it was appending the default_domain_suffix line to all hostnames (fully qualified and not) before asking FreeIPA for their host keys: (Fri Mar 20 23:19:55 2015) [sssd[ssh]] [ssh_host_pubkeys_search_next] (0x0400): Requesting SSH host public keys for [ipaclient1-sandbox-atdev-van.ipadomain.net at addomain.net] (Fri Mar 20 23:19:55 2015) [sssd[ssh]] [sysdb_search_ssh_hosts] (0x0400): No such host So 2 more questions: 1. Is this a bug? 2. If it is not a bug or is expected behavior, is there a way to both A) Have ad users able to login as 'aduser' instead of 'aduser at addomain.net' AND B) Still get host key checking working properly? From dpal at redhat.com Fri Mar 20 23:43:21 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 19:43:21 -0400 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <5fe92a2cd252072f537a863d564dc1e8.squirrel@webmail.nathanpeters.com> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> <550C8FFC.4060102@redhat.com> <5fe92a2cd252072f537a863d564dc1e8.squirrel@webmail.nathanpeters.com> Message-ID: <550CB099.5090105@redhat.com> On 03/20/2015 07:41 PM, nathan at nathanpeters.com wrote: >> On 03/20/2015 04:51 PM, nathan at nathanpeters.com wrote: >>> I have FreeIPA installed on several types of Linux machines and they are >>> all experiencing strange issues with certificates and host keys. >>> Here is the setup: >>> >>> Server : FreeIPA 4.1.2 on Centos 7 >>> Client 1&2 : FreeIPA 3.0.0-42.el6 with sssd 1.11.6-30.el6_6.4 on CentOS >>> 6.5 >>> Client 3&4 : FreeIPA 4.1.2-1.el7 on Centos 7 >>> >>> >>> First the FreeIPA clients running client 3.0.0 do not seem to be >>> properly >>> getting their host keys from the server. Whenever I ssh from one client >>> to another (or even to the IPA server itself) I am prompted to answer >>> yes >>> or no to the host key. The host keys are both listed in the host record >>> if I login to the domain controller web interface (and match what is on >>> the server), and the DNS SSHFP records exist also. >>> >>> # sss_ssh_authorizedkeys --debug 10 admin >>> (Fri Mar 20 13:43:52:706986 2015) [sss_ssh_authorizedkeys] [main] >>> (0x0020): sss_ssh_get_ent() failed (2): No such file or directory >>> Error looking up public keys >> It seems that you might be missing the integration between sssd and ssh. >> Can you please check you configuration as described here: >> http://www.freeipa.org/images/1/10/Freeipa30_SSSD_OpenSSH_integration.pdf >> > Actually this was the problem : > > I had added the following line to the [sssd] section of sssd.conf : > [sssd] > default_domain_suffix = addomain.net > > The reason I had added this is because our business asked if our active > directory trusted users can be allowed to login without entering their > fqdn. Setting the default_domain_suffix allows them to just login as > 'aduser' instead of 'aduser at addomain.net'. > > However, this apparently breaks host key checking. Turning debugging on > the sssd up to 9 revealed that it was appending the default_domain_suffix > line to all hostnames (fully qualified and not) before asking FreeIPA for > their host keys: > > (Fri Mar 20 23:19:55 2015) [sssd[ssh]] [ssh_host_pubkeys_search_next] > (0x0400): Requesting SSH host public keys for > [ipaclient1-sandbox-atdev-van.ipadomain.net at addomain.net] > (Fri Mar 20 23:19:55 2015) [sssd[ssh]] [sysdb_search_ssh_hosts] (0x0400): > No such host > > So 2 more questions: > 1. Is this a bug? > > 2. If it is not a bug or is expected behavior, is there a way to both > A) Have ad users able to login as 'aduser' instead of 'aduser at addomain.net' > AND > B) Still get host key checking working properly? > > Probably a bug. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From roberto.cornacchia at gmail.com Fri Mar 20 23:51:10 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Sat, 21 Mar 2015 00:51:10 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> Message-ID: Ah, I see, I had forgotten to enable debut in the nss section. Here its log. On 21 March 2015 at 00:40, Roberto Cornacchia wrote: > Two log files in attachment (the other files in /var/log/sssd are all > empty). > > I'll also go through the troubleshooting page again, thanks > > > On 20 March 2015 at 23:03, Dmitri Pal wrote: > >> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: >> >> SSSD logs are empty so far. >> >> >> This is wrong. >> >> Isn't sssd.conf written by ipa-client-install? >> >> >> Yes >> >> If I raise the debug level after client installation, >> >> >> (and restart) >> >> what activities do you suggest to attempt from the client? >> >> the ones that fail. getent call that returns nothing. >> Also try 'id'. >> >> http://www.freeipa.org/page/Troubleshooting#Client_Installation >> https://fedorahosted.org/sssd/wiki/Troubleshooting >> >> >> >> On 20 March 2015 at 22:37, Dmitri Pal wrote: >> >>> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >>> >>> It certainly gets there, because the client gets in fact enrolled as a >>> domain host. I can see it from the UI in Identity / Hosts. But not in the >>> DNS zone. >>> >>> *Before ipa-client-install, all these do work: * >>> >>> $ ssh ipa.hq.example.com >>> $ ntpdate ipa.hq.example.com >>> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com >>> uid=admin >>> >>> >>> *After running ipa-client-install, all these do work:* >>> >>> $ kinit admin >>> Password for admin at HQ.EXAMPLE.COM: >>> $ ipa dnszone-show --all >>> [...] >>> $ ntpq -p >>> remote refid st t when poll reach delay offset >>> jitter >>> >>> ============================================================================== >>> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 -0.006 >>> 0.000 >>> LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 >>> 0.000 >>> >>> *But this does NOT work:* >>> $ getent passwd admin at hq.example.com >>> >>> >>> What do SSSD logs show on the client? >>> Please rise the SSSD debug_level and provide SSSD logs. >>> >>> >>> *On the server, in /var/log/krb5kdc.log, I see many of these:* >>> >>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: >>> admin at HQ.EXAMPLE.COM for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM, >>> Additional pre-authentication required >>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, >>> etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM for krbtgt/ >>> HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>> >>> >>> This is not an error. It is a normal user authentication. >>> OK so it is DNS that is not working. Is DNS server running on the server? >>> What do Bind logs show? >>> >>> >>> >>> 192.168.0.207 is the IP of the client I'm trying to install. However, >>> higher up in the log, I also see such errors for the ipa server itself. >>> >>> On 20 March 2015 at 20:24, Dmitri Pal wrote: >>> >>>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>>> >>>> No, all real machines. >>>> >>>> I'm really sorry it's taking so much of your time. >>>> I had tried almost everything on a VM setting first, and everything was >>>> fine. >>>> Everything always works fine, until you actually need it. >>>> >>>> >>>> >>>> We try to help as much as we can. >>>> Can you do LDAP lookups as a directory manager from client host to >>>> server? >>>> Can you ssh from client to server? >>>> >>>> When you try to install client is there anything in the logs on the >>>> server? Does it even get there? >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 20 March 2015 at 19:41, Dmitri Pal wrote: >>>> >>>>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>>>> >>>>> But the ipa server itself is also enrolled as a client, just after the >>>>> server installation, right?. And that worked fine. >>>>> >>>>> >>>>> Are these VMs? >>>>> There have been a similar case when the network was not set properly >>>>> for the virtual test environment. >>>>> >>>>> >>>>> >>>>> On 20 March 2015 at 18:55, Roberto Cornacchia < >>>>> roberto.cornacchia at gmail.com> wrote: >>>>> >>>>>> No, sorry about the confusion, i shouldn't have posted so quickly. >>>>>> >>>>>> When I use the correct domain (hq.example.com), then I really get >>>>>> all the same errors as before, also in the new client. >>>>>> >>>>>> >>>>>> >>>>>> On 20 Mar 2015 18:39, "Dmitri Pal" wrote: >>>>>> >>>>>>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>>>>> >>>>>>> Oops. Not true, forget last email. >>>>>>> >>>>>>> This secon client installation went different just because it took >>>>>>> the wrong domain. >>>>>>> It used *example.com * (what was previously >>>>>>> set) instead of *hq.example.com * >>>>>>> >>>>>>> Uninstalled, tried again with --hostname=photon.hq.example.com >>>>>>> And then it behaves precisely like the previous client. >>>>>>> >>>>>>> So something seems wrong in the server. >>>>>>> >>>>>>> On 20 March 2015 at 18:18, Roberto Cornacchia < >>>>>>> roberto.cornacchia at gmail.com> wrote: >>>>>>> >>>>>>>> Update: >>>>>>>> I tried from another client. Also FC21, same network, same settings >>>>>>>> from the same DHCP. >>>>>>>> But obviously it must have something different because it partially >>>>>>>> succeeded. >>>>>>>> >>>>>>>> - I do not get errors about LDAP users. >>>>>>>> - I do not get errors about DNS update >>>>>>>> >>>>>>>> However: >>>>>>>> - I still get the initial error about NTP >>>>>>>> - The host is enrolled, but not added to the DNS zone >>>>>>>> >>>>>>>> Now, I don't care much about the previous client. It was pretty >>>>>>>> much empty and can re-install Fedora from scratch. >>>>>>>> >>>>>>>> But I'd like to understand if this is still a problem. >>>>>>>> It should be added to the zone, shouldn't it? >>>>>>>> >>>>>>>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>>>>>>> Discovery was successful! >>>>>>>> Hostname: photon.example.com >>>>>>>> Realm: HQ.EXAMPLE.COM >>>>>>>> DNS Domain: hq.example.com >>>>>>>> IPA Server: ipa.hq.example.com >>>>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>>>> >>>>>>>> Continue to configure the system with these values? [no]: yes >>>>>>>> Synchronizing time with KDC... >>>>>>>> *Unable to sync time with IPA NTP server, assuming the time is in >>>>>>>> sync. Please check that 123 UDP port is opened.* >>>>>>>> User authorized to enroll computers: admin >>>>>>>> Password for admin at HQ.EXAMPLE.COM: >>>>>>>> Successfully retrieved CA cert >>>>>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>>>>> >>>>>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>>>>> 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 HQ.EXAMPLE.COM >>>>>>>> trying https://ipa.hq.example.com/ipa/json >>>>>>>> Forwarding 'ping' to json server ' >>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>> Forwarding 'ca_is_enabled' to json server ' >>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>> Systemwide CA database updated. >>>>>>>> Added CA certificates to the default NSS database. >>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>>>>>> Forwarding 'host_mod' to json server ' >>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>> *Could not update DNS SSHFP records.* >>>>>>>> SSSD enabled >>>>>>>> Configured /etc/openldap/ldap.conf >>>>>>>> NTP enabled >>>>>>>> Configured /etc/ssh/ssh_config >>>>>>>> Configured /etc/ssh/sshd_config >>>>>>>> Configuring hq.example.com as NIS domain. >>>>>>>> Client configuration complete. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is different. It does not have the same failure about admin as >>>>>>> you had in the first email. >>>>>>> So may be it is the permissions issue and a separate NTP issue? >>>>>>> Did you play with any permissions on the server side? >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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. >> >> >> -- >> 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 -------------- A non-text attachment was scrubbed... Name: sssd_nss.log Type: application/octet-stream Size: 17858 bytes Desc: not available URL: From roberto.cornacchia at gmail.com Fri Mar 20 23:56:13 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Sat, 21 Mar 2015 00:56:13 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550B617E.8040103@redhat.com> <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> Message-ID: >From https://fedorahosted.org/sssd/wiki/Troubleshooting, I see that invoking getent should correspond to seeing command 17 invoked in the nss log: Something like: [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [admin]. I don't see any command invocation in my sss_dnss log On 21 March 2015 at 00:51, Roberto Cornacchia wrote: > Ah, I see, I had forgotten to enable debut in the nss section. Here its > log. > > On 21 March 2015 at 00:40, Roberto Cornacchia < > roberto.cornacchia at gmail.com> wrote: > >> Two log files in attachment (the other files in /var/log/sssd are all >> empty). >> >> I'll also go through the troubleshooting page again, thanks >> >> >> On 20 March 2015 at 23:03, Dmitri Pal wrote: >> >>> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: >>> >>> SSSD logs are empty so far. >>> >>> >>> This is wrong. >>> >>> Isn't sssd.conf written by ipa-client-install? >>> >>> >>> Yes >>> >>> If I raise the debug level after client installation, >>> >>> >>> (and restart) >>> >>> what activities do you suggest to attempt from the client? >>> >>> the ones that fail. getent call that returns nothing. >>> Also try 'id'. >>> >>> http://www.freeipa.org/page/Troubleshooting#Client_Installation >>> https://fedorahosted.org/sssd/wiki/Troubleshooting >>> >>> >>> >>> On 20 March 2015 at 22:37, Dmitri Pal wrote: >>> >>>> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >>>> >>>> It certainly gets there, because the client gets in fact enrolled as >>>> a domain host. I can see it from the UI in Identity / Hosts. But not in the >>>> DNS zone. >>>> >>>> *Before ipa-client-install, all these do work: * >>>> >>>> $ ssh ipa.hq.example.com >>>> $ ntpdate ipa.hq.example.com >>>> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com >>>> uid=admin >>>> >>>> >>>> *After running ipa-client-install, all these do work:* >>>> >>>> $ kinit admin >>>> Password for admin at HQ.EXAMPLE.COM: >>>> $ ipa dnszone-show --all >>>> [...] >>>> $ ntpq -p >>>> remote refid st t when poll reach delay offset >>>> jitter >>>> >>>> ============================================================================== >>>> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 -0.006 >>>> 0.000 >>>> LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 >>>> 0.000 >>>> >>>> *But this does NOT work:* >>>> $ getent passwd admin at hq.example.com >>>> >>>> >>>> What do SSSD logs show on the client? >>>> Please rise the SSSD debug_level and provide SSSD logs. >>>> >>>> >>>> *On the server, in /var/log/krb5kdc.log, I see many of these:* >>>> >>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >>>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: >>>> admin at HQ.EXAMPLE.COM for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM, >>>> Additional pre-authentication required >>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >>>> etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, >>>> etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM for krbtgt/ >>>> HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>>> >>>> >>>> This is not an error. It is a normal user authentication. >>>> OK so it is DNS that is not working. Is DNS server running on the >>>> server? >>>> What do Bind logs show? >>>> >>>> >>>> >>>> 192.168.0.207 is the IP of the client I'm trying to install. However, >>>> higher up in the log, I also see such errors for the ipa server itself. >>>> >>>> On 20 March 2015 at 20:24, Dmitri Pal wrote: >>>> >>>>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>>>> >>>>> No, all real machines. >>>>> >>>>> I'm really sorry it's taking so much of your time. >>>>> I had tried almost everything on a VM setting first, and everything >>>>> was fine. >>>>> Everything always works fine, until you actually need it. >>>>> >>>>> >>>>> >>>>> We try to help as much as we can. >>>>> Can you do LDAP lookups as a directory manager from client host to >>>>> server? >>>>> Can you ssh from client to server? >>>>> >>>>> When you try to install client is there anything in the logs on the >>>>> server? Does it even get there? >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 20 March 2015 at 19:41, Dmitri Pal wrote: >>>>> >>>>>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>>>>> >>>>>> But the ipa server itself is also enrolled as a client, just after >>>>>> the server installation, right?. And that worked fine. >>>>>> >>>>>> >>>>>> Are these VMs? >>>>>> There have been a similar case when the network was not set properly >>>>>> for the virtual test environment. >>>>>> >>>>>> >>>>>> >>>>>> On 20 March 2015 at 18:55, Roberto Cornacchia < >>>>>> roberto.cornacchia at gmail.com> wrote: >>>>>> >>>>>>> No, sorry about the confusion, i shouldn't have posted so quickly. >>>>>>> >>>>>>> When I use the correct domain (hq.example.com), then I really get >>>>>>> all the same errors as before, also in the new client. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 20 Mar 2015 18:39, "Dmitri Pal" wrote: >>>>>>> >>>>>>>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>>>>>> >>>>>>>> Oops. Not true, forget last email. >>>>>>>> >>>>>>>> This secon client installation went different just because it >>>>>>>> took the wrong domain. >>>>>>>> It used *example.com * (what was previously >>>>>>>> set) instead of *hq.example.com * >>>>>>>> >>>>>>>> Uninstalled, tried again with --hostname=photon.hq.example.com >>>>>>>> And then it behaves precisely like the previous client. >>>>>>>> >>>>>>>> So something seems wrong in the server. >>>>>>>> >>>>>>>> On 20 March 2015 at 18:18, Roberto Cornacchia < >>>>>>>> roberto.cornacchia at gmail.com> wrote: >>>>>>>> >>>>>>>>> Update: >>>>>>>>> I tried from another client. Also FC21, same network, same >>>>>>>>> settings from the same DHCP. >>>>>>>>> But obviously it must have something different because it >>>>>>>>> partially succeeded. >>>>>>>>> >>>>>>>>> - I do not get errors about LDAP users. >>>>>>>>> - I do not get errors about DNS update >>>>>>>>> >>>>>>>>> However: >>>>>>>>> - I still get the initial error about NTP >>>>>>>>> - The host is enrolled, but not added to the DNS zone >>>>>>>>> >>>>>>>>> Now, I don't care much about the previous client. It was pretty >>>>>>>>> much empty and can re-install Fedora from scratch. >>>>>>>>> >>>>>>>>> But I'd like to understand if this is still a problem. >>>>>>>>> It should be added to the zone, shouldn't it? >>>>>>>>> >>>>>>>>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>>>>>>>> Discovery was successful! >>>>>>>>> Hostname: photon.example.com >>>>>>>>> Realm: HQ.EXAMPLE.COM >>>>>>>>> DNS Domain: hq.example.com >>>>>>>>> IPA Server: ipa.hq.example.com >>>>>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>>>>> >>>>>>>>> Continue to configure the system with these values? [no]: yes >>>>>>>>> Synchronizing time with KDC... >>>>>>>>> *Unable to sync time with IPA NTP server, assuming the time is in >>>>>>>>> sync. Please check that 123 UDP port is opened.* >>>>>>>>> User authorized to enroll computers: admin >>>>>>>>> Password for admin at HQ.EXAMPLE.COM: >>>>>>>>> Successfully retrieved CA cert >>>>>>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>>>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>>>>>> >>>>>>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>>>>>> 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 HQ.EXAMPLE.COM >>>>>>>>> trying https://ipa.hq.example.com/ipa/json >>>>>>>>> Forwarding 'ping' to json server ' >>>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>>> Forwarding 'ca_is_enabled' to json server ' >>>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>>> Systemwide CA database updated. >>>>>>>>> Added CA certificates to the default NSS database. >>>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>>>>>>> Forwarding 'host_mod' to json server ' >>>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>>> *Could not update DNS SSHFP records.* >>>>>>>>> SSSD enabled >>>>>>>>> Configured /etc/openldap/ldap.conf >>>>>>>>> NTP enabled >>>>>>>>> Configured /etc/ssh/ssh_config >>>>>>>>> Configured /etc/ssh/sshd_config >>>>>>>>> Configuring hq.example.com as NIS domain. >>>>>>>>> Client configuration complete. >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> It is different. It does not have the same failure about admin as >>>>>>>> you had in the first email. >>>>>>>> So may be it is the permissions issue and a separate NTP issue? >>>>>>>> Did you play with any permissions on the server side? >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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. >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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 Sat Mar 21 00:01:25 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 20:01:25 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> Message-ID: <550CB4D5.6010303@redhat.com> On 03/20/2015 07:40 PM, Roberto Cornacchia wrote: > Two log files in attachment (the other files in /var/log/sssd are all > empty). > > I'll also go through the troubleshooting page again, thanks > Do the logs include an id call for admin? I do not see any instance of the word "admin" in the log. > > On 20 March 2015 at 23:03, Dmitri Pal > wrote: > > On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: >> SSSD logs are empty so far. > > This is wrong. > >> Isn't sssd.conf written by ipa-client-install? > > Yes > >> If I raise the debug level after client installation, > > (and restart) > >> what activities do you suggest to attempt from the client? > the ones that fail. getent call that returns nothing. > Also try 'id'. > > http://www.freeipa.org/page/Troubleshooting#Client_Installation > https://fedorahosted.org/sssd/wiki/Troubleshooting > >> >> >> On 20 March 2015 at 22:37, Dmitri Pal > > wrote: >> >> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >>> It certainly gets there, because the client gets in fact >>> enrolled as a domain host. I can see it from the UI in >>> Identity / Hosts. But not in the DNS zone. >>> >>> *Before ipa-client-install, all these do work: * >>> >>> $ ssh ipa.hq.example.com >>> $ ntpdate ipa.hq.example.com >>> $ ldapsearch -x -h ipa.hq.example.com >>> -b dc=hq,dc=example,dc=com uid=admin >>> >>> >>> *After running ipa-client-install, all these do work:* >>> >>> $ kinit admin >>> Password for admin at HQ.EXAMPLE.COM : >>> $ ipa dnszone-show --all >>> [...] >>> $ ntpq -p >>> remote refid st t when poll reach delay >>> offset jitter >>> ============================================================================== >>> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 >>> 0.415 -0.006 0.000 >>> LOCAL(0) .LOCL. 5 l - 64 0 0.000 >>> 0.000 0.000 >>> >>> *But this does NOT work:* >>> $ getent passwd admin at hq.example.com >>> >> >> What do SSSD logs show on the client? >> Please rise the SSSD debug_level and provide SSSD logs. >> >>> >>> *On the server, in /var/log/krb5kdc.log, I see many of these:* >>> >>> Mar 20 21:53:17 ipa.hq.example.com >>> krb5kdc[9229](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 192.168.0.207 >>> : NEEDED_PREAUTH: admin at HQ.EXAMPLE.COM >>> for >>> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>> , Additional pre-authentication >>> required >>> Mar 20 21:53:17 ipa.hq.example.com >>> krb5kdc[9229](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 192.168.0.207 >>> : ISSUE: authtime 1426884797, etypes >>> {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM >>> for >>> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>> >> >> This is not an error. It is a normal user authentication. >> OK so it is DNS that is not working. Is DNS server running on >> the server? >> What do Bind logs show? >> >> >>> >>> 192.168.0.207 is the IP of the client I'm trying to install. >>> However, higher up in the log, I also see such errors for >>> the ipa server itself. >>> >>> On 20 March 2015 at 20:24, Dmitri Pal >> > wrote: >>> >>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>>> No, all real machines. >>>> >>>> I'm really sorry it's taking so much of your time. >>>> I had tried almost everything on a VM setting first, >>>> and everything was fine. >>>> Everything always works fine, until you actually need it. >>> >>> >>> We try to help as much as we can. >>> Can you do LDAP lookups as a directory manager from >>> client host to server? >>> Can you ssh from client to server? >>> >>> When you try to install client is there anything in the >>> logs on the server? Does it even get there? >>> >>> >>> >>> >>>> >>>> >>>> On 20 March 2015 at 19:41, Dmitri Pal >>> > wrote: >>>> >>>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>>>> But the ipa server itself is also enrolled as a >>>>> client, just after the server installation, >>>>> right?. And that worked fine. >>>> >>>> Are these VMs? >>>> There have been a similar case when the network was >>>> not set properly for the virtual test environment. >>>> >>>> >>>>> >>>>> On 20 March 2015 at 18:55, Roberto Cornacchia >>>>> >>>> > wrote: >>>>> >>>>> No, sorry about the confusion, i shouldn't >>>>> have posted so quickly. >>>>> >>>>> When I use the correct domain (hq.example.com >>>>> ), then I really get >>>>> all the same errors as before, also in the new >>>>> client. >>>>> >>>>> >>>>> >>>>> On 20 Mar 2015 18:39, "Dmitri Pal" >>>>> > wrote: >>>>> >>>>> On 03/20/2015 01:25 PM, Roberto Cornacchia >>>>> wrote: >>>>>> Oops. Not true, forget last email. >>>>>> >>>>>> This secon client installation went >>>>>> different just because it took the wrong >>>>>> domain. >>>>>> It used *example.com >>>>>> * (what was >>>>>> previously set) instead of >>>>>> *hq.example.com * >>>>>> >>>>>> Uninstalled, tried again with >>>>>> --hostname=photon.hq.example.com >>>>>> >>>>>> And then it behaves precisely like the >>>>>> previous client. >>>>>> >>>>>> So something seems wrong in the server. >>>>>> >>>>>> On 20 March 2015 at 18:18, Roberto >>>>>> Cornacchia >>>>> > wrote: >>>>>> >>>>>> Update: >>>>>> I tried from another client. Also >>>>>> FC21, same network, same settings >>>>>> from the same DHCP. >>>>>> But obviously it must have something >>>>>> different because it partially succeeded. >>>>>> >>>>>> - I do not get errors about LDAP users. >>>>>> - I do not get errors about DNS update >>>>>> >>>>>> However: >>>>>> - I still get the initial error about NTP >>>>>> - The host is enrolled, but not added >>>>>> to the DNS zone >>>>>> >>>>>> Now, I don't care much about the >>>>>> previous client. It was pretty much >>>>>> empty and can re-install Fedora from >>>>>> scratch. >>>>>> >>>>>> But I'd like to understand if this is >>>>>> still a problem. >>>>>> It should be added to the zone, >>>>>> shouldn't it? >>>>>> >>>>>> $ ipa-client-install --mkhomedir >>>>>> --ssh-trust-dns --force-ntpd >>>>>> Discovery was successful! >>>>>> Hostname: photon.example.com >>>>>> >>>>>> Realm: HQ.EXAMPLE.COM >>>>>> >>>>>> DNS Domain: hq.example.com >>>>>> >>>>>> IPA Server: ipa.hq.example.com >>>>>> >>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>> >>>>>> Continue to configure the system with >>>>>> these values? [no]: yes >>>>>> Synchronizing time with KDC... >>>>>> *Unable to sync time with IPA NTP >>>>>> server, assuming the time is in sync. >>>>>> Please check that 123 UDP port is >>>>>> opened.* >>>>>> User authorized to enroll computers: >>>>>> admin >>>>>> Password for admin at HQ.EXAMPLE.COM >>>>>> : >>>>>> Successfully retrieved CA cert >>>>>> Subject: CN=Certificate >>>>>> Authority,O=HQ.EXAMPLE.COM >>>>>> >>>>>> Issuer: CN=Certificate >>>>>> Authority,O=HQ.EXAMPLE.COM >>>>>> >>>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>>> >>>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>>> >>>>>> 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 HQ.EXAMPLE.COM >>>>>> >>>>>> trying >>>>>> https://ipa.hq.example.com/ipa/json >>>>>> Forwarding 'ping' to json server >>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>> Forwarding 'ca_is_enabled' to json >>>>>> server >>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>> Systemwide CA database updated. >>>>>> Added CA certificates to the default >>>>>> NSS database. >>>>>> Adding SSH public key from >>>>>> /etc/ssh/ssh_host_rsa_key.pub >>>>>> Adding SSH public key from >>>>>> /etc/ssh/ssh_host_ed25519_key.pub >>>>>> Adding SSH public key from >>>>>> /etc/ssh/ssh_host_dsa_key.pub >>>>>> Adding SSH public key from >>>>>> /etc/ssh/ssh_host_ecdsa_key.pub >>>>>> Forwarding 'host_mod' to json server >>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>> *Could not update DNS SSHFP records.* >>>>>> SSSD enabled >>>>>> Configured /etc/openldap/ldap.conf >>>>>> NTP enabled >>>>>> Configured /etc/ssh/ssh_config >>>>>> Configured /etc/ssh/sshd_config >>>>>> Configuring hq.example.com >>>>>> as NIS domain. >>>>>> Client configuration complete. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> It is different. It does not have the same >>>>> failure about admin as you had in the >>>>> first email. >>>>> So may be it is the permissions issue and >>>>> a separate NTP issue? >>>>> Did you play with any permissions on the >>>>> server side? >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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 dpal at redhat.com Sat Mar 21 00:03:38 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 20:03:38 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> Message-ID: <550CB55A.2070101@redhat.com> On 03/20/2015 07:56 PM, Roberto Cornacchia wrote: > From https://fedorahosted.org/sssd/wiki/Troubleshooting, I see that > invoking getent should correspond to seeing command 17 invoked in the > nss log: > > Something like: > [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with > input [admin]. > > I don't see any command invocation in my sss_dnss log > Forgot to reply to the list... Right. So how does your nsswitch.conf looks like? > On 21 March 2015 at 00:51, Roberto Cornacchia > > > wrote: > > Ah, I see, I had forgotten to enable debut in the nss section. > Here its log. > > On 21 March 2015 at 00:40, Roberto Cornacchia > > wrote: > > Two log files in attachment (the other files in /var/log/sssd > are all empty). > > I'll also go through the troubleshooting page again, thanks > > > On 20 March 2015 at 23:03, Dmitri Pal > wrote: > > On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: >> SSSD logs are empty so far. > > This is wrong. > >> Isn't sssd.conf written by ipa-client-install? > > Yes > >> If I raise the debug level after client installation, > > (and restart) > >> what activities do you suggest to attempt from the client? > the ones that fail. getent call that returns nothing. > Also try 'id'. > > http://www.freeipa.org/page/Troubleshooting#Client_Installation > https://fedorahosted.org/sssd/wiki/Troubleshooting > >> >> >> On 20 March 2015 at 22:37, Dmitri Pal > > wrote: >> >> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >>> It certainly gets there, because the client gets in >>> fact enrolled as a domain host. I can see it from >>> the UI in Identity / Hosts. But not in the DNS zone. >>> >>> *Before ipa-client-install, all these do work: * >>> >>> $ ssh ipa.hq.example.com >>> $ ntpdate ipa.hq.example.com >>> $ ldapsearch -x -h ipa.hq.example.com >>> -b >>> dc=hq,dc=example,dc=com uid=admin >>> >>> >>> *After running ipa-client-install, all these do work:* >>> >>> $ kinit admin >>> Password for admin at HQ.EXAMPLE.COM >>> : >>> $ ipa dnszone-show --all >>> [...] >>> $ ntpq -p >>> remote refid st t when poll reach delay >>> offset jitter >>> ============================================================================== >>> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 >>> 0.415 -0.006 0.000 >>> LOCAL(0) .LOCL. 5 l - 64 0 >>> 0.000 0.000 0.000 >>> >>> *But this does NOT work:* >>> $ getent passwd admin at hq.example.com >>> >> >> What do SSSD logs show on the client? >> Please rise the SSSD debug_level and provide SSSD logs. >> >>> >>> *On the server, in /var/log/krb5kdc.log, I see many >>> of these:* >>> >>> Mar 20 21:53:17 ipa.hq.example.com >>> krb5kdc[9229](info): >>> AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207 >>> : NEEDED_PREAUTH: >>> admin at HQ.EXAMPLE.COM >>> for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>> , Additional >>> pre-authentication required >>> Mar 20 21:53:17 ipa.hq.example.com >>> krb5kdc[9229](info): >>> AS_REQ (6 etypes {18 17 16 23 25 26}) 192.168.0.207 >>> : ISSUE: authtime 1426884797, >>> etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM >>> for >>> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>> >> >> This is not an error. It is a normal user authentication. >> OK so it is DNS that is not working. Is DNS server >> running on the server? >> What do Bind logs show? >> >> >>> >>> 192.168.0.207 is the IP of the client I'm trying to >>> install. However, higher up in the log, I also see >>> such errors for the ipa server itself. >>> >>> On 20 March 2015 at 20:24, Dmitri Pal >>> > wrote: >>> >>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>>> No, all real machines. >>>> >>>> I'm really sorry it's taking so much of your time. >>>> I had tried almost everything on a VM setting >>>> first, and everything was fine. >>>> Everything always works fine, until you >>>> actually need it. >>> >>> >>> We try to help as much as we can. >>> Can you do LDAP lookups as a directory manager >>> from client host to server? >>> Can you ssh from client to server? >>> >>> When you try to install client is there anything >>> in the logs on the server? Does it even get there? >>> >>> >>> >>> >>>> >>>> >>>> On 20 March 2015 at 19:41, Dmitri Pal >>>> > wrote: >>>> >>>> On 03/20/2015 01:57 PM, Roberto Cornacchia >>>> wrote: >>>>> But the ipa server itself is also enrolled >>>>> as a client, just after the server >>>>> installation, right?. And that worked fine. >>>> >>>> Are these VMs? >>>> There have been a similar case when the >>>> network was not set properly for the >>>> virtual test environment. >>>> >>>> >>>>> >>>>> On 20 March 2015 at 18:55, Roberto >>>>> Cornacchia >>>> > wrote: >>>>> >>>>> No, sorry about the confusion, i >>>>> shouldn't have posted so quickly. >>>>> >>>>> When I use the correct domain >>>>> (hq.example.com >>>>> ), then I >>>>> really get all the same errors as >>>>> before, also in the new client. >>>>> >>>>> >>>>> >>>>> On 20 Mar 2015 18:39, "Dmitri Pal" >>>>> >>>> > wrote: >>>>> >>>>> On 03/20/2015 01:25 PM, Roberto >>>>> Cornacchia wrote: >>>>>> Oops. Not true, forget last email. >>>>>> >>>>>> This secon client installation >>>>>> went different just because it >>>>>> took the wrong domain. >>>>>> It used *example.com >>>>>> * (what was >>>>>> previously set) instead of >>>>>> *hq.example.com >>>>>> * >>>>>> >>>>>> Uninstalled, tried again with >>>>>> --hostname=photon.hq.example.com >>>>>> >>>>>> And then it behaves precisely >>>>>> like the previous client. >>>>>> >>>>>> So something seems wrong in the >>>>>> server. >>>>>> >>>>>> On 20 March 2015 at 18:18, >>>>>> Roberto Cornacchia >>>>>> >>>>> > >>>>>> wrote: >>>>>> >>>>>> Update: >>>>>> I tried from another client. >>>>>> Also FC21, same network, same >>>>>> settings from the same DHCP. >>>>>> But obviously it must have >>>>>> something different because >>>>>> it partially succeeded. >>>>>> >>>>>> - I do not get errors about >>>>>> LDAP users. >>>>>> - I do not get errors about >>>>>> DNS update >>>>>> >>>>>> However: >>>>>> - I still get the initial >>>>>> error about NTP >>>>>> - The host is enrolled, but >>>>>> not added to the DNS zone >>>>>> >>>>>> Now, I don't care much about >>>>>> the previous client. It was >>>>>> pretty much empty and can >>>>>> re-install Fedora from scratch. >>>>>> >>>>>> But I'd like to understand if >>>>>> this is still a problem. >>>>>> It should be added to the >>>>>> zone, shouldn't it? >>>>>> >>>>>> $ ipa-client-install >>>>>> --mkhomedir --ssh-trust-dns >>>>>> --force-ntpd >>>>>> Discovery was successful! >>>>>> Hostname: photon.example.com >>>>>> >>>>>> Realm: HQ.EXAMPLE.COM >>>>>> >>>>>> DNS Domain: hq.example.com >>>>>> >>>>>> IPA Server: >>>>>> ipa.hq.example.com >>>>>> >>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>> >>>>>> Continue to configure the >>>>>> system with these values? >>>>>> [no]: yes >>>>>> Synchronizing time with KDC... >>>>>> *Unable to sync time with IPA >>>>>> NTP server, assuming the time >>>>>> is in sync. Please check that >>>>>> 123 UDP port is opened.* >>>>>> User authorized to enroll >>>>>> computers: admin >>>>>> Password for >>>>>> admin at HQ.EXAMPLE.COM >>>>>> : >>>>>> Successfully retrieved CA cert >>>>>> Subject: CN=Certificate >>>>>> Authority,O=HQ.EXAMPLE.COM >>>>>> >>>>>> Issuer: CN=Certificate >>>>>> Authority,O=HQ.EXAMPLE.COM >>>>>> >>>>>> Valid From: Mon Mar 16 >>>>>> 18:44:35 2015 UTC >>>>>> Valid Until: Fri Mar 16 >>>>>> 18:44:35 2035 UTC >>>>>> >>>>>> Enrolled in IPA realm >>>>>> HQ.EXAMPLE.COM >>>>>> >>>>>> 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 HQ.EXAMPLE.COM >>>>>> >>>>>> trying >>>>>> https://ipa.hq.example.com/ipa/json >>>>>> Forwarding 'ping' to json >>>>>> server >>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>> Forwarding 'ca_is_enabled' to >>>>>> json server >>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>> Systemwide CA database updated. >>>>>> Added CA certificates to the >>>>>> default NSS database. >>>>>> Adding SSH public key from >>>>>> /etc/ssh/ssh_host_rsa_key.pub >>>>>> Adding SSH public key from >>>>>> /etc/ssh/ssh_host_ed25519_key.pub >>>>>> Adding SSH public key from >>>>>> /etc/ssh/ssh_host_dsa_key.pub >>>>>> Adding SSH public key from >>>>>> /etc/ssh/ssh_host_ecdsa_key.pub >>>>>> Forwarding 'host_mod' to json >>>>>> server >>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>> *Could not update DNS SSHFP >>>>>> records.* >>>>>> SSSD enabled >>>>>> Configured >>>>>> /etc/openldap/ldap.conf >>>>>> NTP enabled >>>>>> Configured /etc/ssh/ssh_config >>>>>> Configured /etc/ssh/sshd_config >>>>>> Configuring hq.example.com >>>>>> as >>>>>> NIS domain. >>>>>> Client configuration complete. >>>>>> >>>>>> >>>>>> >>>>>> >>>>> >>>>> It is different. It does not have >>>>> the same failure about admin as >>>>> you had in the first email. >>>>> So may be it is the permissions >>>>> issue and a separate NTP issue? >>>>> Did you play with any permissions >>>>> on the server side? >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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 nathan at nathanpeters.com Sat Mar 21 00:12:25 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 20 Mar 2015 17:12:25 -0700 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <23dcce196ff00754c7f332a39eb5bec1.squirrel@webmail.nathanpeters.com> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> <550C8FC7.3060405@redhat.com> <23dcce196ff00754c7f332a39eb5bec1.squirrel@webmail.nathanpeters.com> Message-ID: <322e88d7e0cf6572f2f92e6539bc29e1.squirrel@webmail.nathanpeters.com> >> nathan at nathanpeters.com wrote: >>> I have FreeIPA installed on several types of Linux machines and they >>> are >>> all experiencing strange issues with certificates and host keys. >>> Here is the setup: >>> >>> Server : FreeIPA 4.1.2 on Centos 7 >>> Client 1&2 : FreeIPA 3.0.0-42.el6 with sssd 1.11.6-30.el6_6.4 on CentOS >>> 6.5 >>> Client 3&4 : FreeIPA 4.1.2-1.el7 on Centos 7 >>> >>> >>> First the FreeIPA clients running client 3.0.0 do not seem to be >>> properly >>> getting their host keys from the server. Whenever I ssh from one >>> client >>> to another (or even to the IPA server itself) I am prompted to answer >>> yes >>> or no to the host key. The host keys are both listed in the host >>> record >>> if I login to the domain controller web interface (and match what is on >>> the server), and the DNS SSHFP records exist also. >>> >>> # sss_ssh_authorizedkeys --debug 10 admin >>> (Fri Mar 20 13:43:52:706986 2015) [sss_ssh_authorizedkeys] [main] >>> (0x0020): sss_ssh_get_ent() failed (2): No such file or directory >>> Error looking up public keys >>> >>> I've seen some bug reports that this was a problem with sssd 1.10 but >>> with >>> a recent (updated today) version of sssd 1.11 I would assume that is >>> not >>> the issue? >> >> I think you'll need to wait for one of the SSSD guys on this one. strace >> might point the way if the error is happening on the user side of dbus. >> >>> The second issue is that whenver I join a FreeIPA 4.1.2 client, I can't >>> login with FreeIPA or AD users. I believe this is due to the fact that >>> when I login to the domain controller web interface and look at the >>> freshly enrolled client it says "kerberos key present, host >>> provisioned" >>> but the next line is "Status No Valid Certificate". Unenrolling and >>> re-enrolling the client leads to the same issue with "No Valid >>> Certificate". >>> >>> Here is a grep of my client install log filtered for 'certificate'. I >>> don't see any errors. >>> 2015-03-20T20:33:28Z DEBUG args='/usr/bin/certutil' '-d' >>> '/tmp/tmpuZCwlm' >>> '-A' '-n' 'CA certificate 1' '-t' 'C,,' >>> 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True >>> is_server=False >>> 2015-03-20T20:33:28Z DEBUG auth_certificate_callback: check_sig=True >>> is_server=False >>> 2015-03-20T20:33:30Z DEBUG Adding CA certificates to the IPA NSS >>> database. >>> 2015-03-20T20:33:32Z DEBUG Attempting to add CA certificates to the >>> default NSS database. >>> 2015-03-20T20:33:32Z INFO Added CA certificates to the default NSS >>> database. >>> 2015-03-20T20:33:32Z DEBUG auth_certificate_callback: check_sig=True >>> is_server=False >> >> The host certificate is not used for anything so it isn't the problem. >> One is not obtained automatically in 4.1 any more. It wouldn't be used >> at login in any case. >> >> Did you disable the HBAC allow-all rule? >> >> I'd bump up the sssd debug level and check the logs. >> >> rob >> >> > > Oh I realized that I can login to either of the 4.x clients from a windows > machine, but once on the 4.x client itself if I try to ssh off the machine > to either a 3.x or a 4.x client, I get : > $ ssh ipaclient4-sandbox-atdev-van > ssh_exchange_identification: Connection closed by remote host Ok, this can be ignored. Apparently, 'Connection closed by remote host' is the message given when the actual problem is 'cannot resolve hostname in DNS'. This is really dumb because connection closed indicates that it not only found it in dns, but then managed to connect and then was closed. The real problem is that it was never opened because it could never be found. Stupidly misleading error message... From nathan at nathanpeters.com Sat Mar 21 00:18:08 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Fri, 20 Mar 2015 17:18:08 -0700 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <550CB099.5090105@redhat.com> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> <550C8FFC.4060102@redhat.com> <5fe92a2cd252072f537a863d564dc1e8.squirrel@webmail.nathanpeters.com> <550CB099.5090105@redhat.com> Message-ID: >> Actually this was the problem : >> >> I had added the following line to the [sssd] section of sssd.conf : >> [sssd] >> default_domain_suffix = addomain.net >> >> The reason I had added this is because our business asked if our active >> directory trusted users can be allowed to login without entering their >> fqdn. Setting the default_domain_suffix allows them to just login as >> 'aduser' instead of 'aduser at addomain.net'. >> >> However, this apparently breaks host key checking. Turning debugging on >> the sssd up to 9 revealed that it was appending the >> default_domain_suffix >> line to all hostnames (fully qualified and not) before asking FreeIPA >> for >> their host keys: >> >> (Fri Mar 20 23:19:55 2015) [sssd[ssh]] [ssh_host_pubkeys_search_next] >> (0x0400): Requesting SSH host public keys for >> [ipaclient1-sandbox-atdev-van.ipadomain.net at addomain.net] >> (Fri Mar 20 23:19:55 2015) [sssd[ssh]] [sysdb_search_ssh_hosts] >> (0x0400): >> No such host >> >> So 2 more questions: >> 1. Is this a bug? >> >> 2. If it is not a bug or is expected behavior, is there a way to both >> A) Have ad users able to login as 'aduser' instead of >> 'aduser at addomain.net' >> AND >> B) Still get host key checking working properly? >> >> > Probably a bug. > > -- > 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 > Hmm, if it is a bug, it still exists in the newest sssd (1.12.3-2.el7) because I just tested it on the newest CentOS 7 client and without default_domain_suffix set I get host key checking, but with it set, it is failing just like it did on CentOS 6 with the older sssd. Is there a good place to report that bug so it can hopefully get fixed? From dpal at redhat.com Sat Mar 21 00:32:14 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 20 Mar 2015 20:32:14 -0400 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> <550C8FFC.4060102@redhat.com> <5fe92a2cd252072f537a863d564dc1e8.squirrel@webmail.nathanpeters.com> <550CB099.5090105@redhat.com> Message-ID: <550CBC0E.30901@redhat.com> On 03/20/2015 08:18 PM, nathan at nathanpeters.com wrote: >>> Actually this was the problem : >>> >>> I had added the following line to the [sssd] section of sssd.conf : >>> [sssd] >>> default_domain_suffix = addomain.net >>> >>> The reason I had added this is because our business asked if our active >>> directory trusted users can be allowed to login without entering their >>> fqdn. Setting the default_domain_suffix allows them to just login as >>> 'aduser' instead of 'aduser at addomain.net'. >>> >>> However, this apparently breaks host key checking. Turning debugging on >>> the sssd up to 9 revealed that it was appending the >>> default_domain_suffix >>> line to all hostnames (fully qualified and not) before asking FreeIPA >>> for >>> their host keys: >>> >>> (Fri Mar 20 23:19:55 2015) [sssd[ssh]] [ssh_host_pubkeys_search_next] >>> (0x0400): Requesting SSH host public keys for >>> [ipaclient1-sandbox-atdev-van.ipadomain.net at addomain.net] >>> (Fri Mar 20 23:19:55 2015) [sssd[ssh]] [sysdb_search_ssh_hosts] >>> (0x0400): >>> No such host >>> >>> So 2 more questions: >>> 1. Is this a bug? >>> >>> 2. If it is not a bug or is expected behavior, is there a way to both >>> A) Have ad users able to login as 'aduser' instead of >>> 'aduser at addomain.net' >>> AND >>> B) Still get host key checking working properly? >>> >>> >> Probably a bug. >> >> -- >> 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 >> > Hmm, if it is a bug, it still exists in the newest sssd (1.12.3-2.el7) > because I just tested it on the newest CentOS 7 client and without > default_domain_suffix set I get host key checking, but with it set, it is > failing just like it did on CentOS 6 with the older sssd. > > Is there a good place to report that bug so it can hopefully get fixed? > > Let us wait till Monday. I CCed Jakub. He will be able to confirm whether this is a bug or not. If it is in fact a bug here is where to file it: https://fedorahosted.org/sssd/ you need a Fedora login to do it. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From james.mcevoy at hp.com Sat Mar 21 00:56:11 2015 From: james.mcevoy at hp.com (McEvoy, James) Date: Sat, 21 Mar 2015 00:56:11 +0000 Subject: [Freeipa-users] Password entry through Trust not correct Message-ID: <6301806E96421841896741228C6B1A2764C5B76C@G4W3216.americas.hpqcorp.net> When I look at the password entries for my rfc2307 account in Active directory I get three different answers. The only correct one is on a server where I used sssd to join AD directly ( the last one ). Do I need to configure rfc2307? When I configured the server to join AD directly I use the option --enablerfc2307bis when I run authconfig. from a freeipa client: $ getent passwd jemcevoy at ENAS.NET jemcevoy at enas.net:*:10001:10004::/home/enas.net/jemcevoy: from the ipa server: [root at ipa ~]# getent passwd jemcevoy at ENAS.NET jemcevoy at enas.net:*:10001:10004:James McEvoy:/home/enas.net/jemcevoy:/bin/bash from a server that joined AD directly using sssd: $ getent passwd jemcevoy at ENAS.NET jemcevoy:*:10001:10004:James McEvoy:/home/jemcevoy:/bin/bash -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Sat Mar 21 09:53:43 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Sat, 21 Mar 2015 05:53:43 -0400 Subject: [Freeipa-users] Automatic client enrollment Message-ID: Is it possible to completely automate the client enrollment process similar to securenets in NIS? I'm trying to migrate NIS to IDM, and hoping that it runs largely in auto-pilot mode. The kickstarter method suggests adding host entries with a one time kerberos password to launch unattended client installs. That, however, needs the admin's involvement every time a new host has to be added. Securenets works pretty well in our case since we can authenticate based on the IP address. User addition is still manual, but that's all right since that is infrequent. Is it possible to do something similar using IP masks or fqdn regex in ipa ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Sat Mar 21 11:33:12 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Sat, 21 Mar 2015 12:33:12 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550CB55A.2070101@redhat.com> References: <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB55A.2070101@redhat.com> Message-ID: /etc/nsswitch.conf: passwd: files shadow: files group: files hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files netgroup: files publickey: nisplus automount: files aliases: files nisplus sudoers: files sss On 21 Mar 2015 01:06, "Dmitri Pal" wrote: > On 03/20/2015 07:56 PM, Roberto Cornacchia wrote: > > From https://fedorahosted.org/sssd/wiki/Troubleshooting, I see that > invoking getent should correspond to seeing command 17 invoked in the nss > log: > > Something like: > [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input > [admin]. > > I don't see any command invocation in my sss_dnss log > > > Forgot to reply to the list... > > Right. > So how does your nsswitch.conf looks like? > > > On 21 March 2015 at 00:51, Roberto Cornacchia < > roberto.cornacchia at gmail.com> wrote: > >> Ah, I see, I had forgotten to enable debut in the nss section. Here its >> log. >> >> On 21 March 2015 at 00:40, Roberto Cornacchia < >> roberto.cornacchia at gmail.com> wrote: >> >>> Two log files in attachment (the other files in /var/log/sssd are all >>> empty). >>> >>> I'll also go through the troubleshooting page again, thanks >>> >>> >>> On 20 March 2015 at 23:03, Dmitri Pal wrote: >>> >>>> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: >>>> >>>> SSSD logs are empty so far. >>>> >>>> >>>> This is wrong. >>>> >>>> Isn't sssd.conf written by ipa-client-install? >>>> >>>> >>>> Yes >>>> >>>> If I raise the debug level after client installation, >>>> >>>> >>>> (and restart) >>>> >>>> what activities do you suggest to attempt from the client? >>>> >>>> the ones that fail. getent call that returns nothing. >>>> Also try 'id'. >>>> >>>> http://www.freeipa.org/page/Troubleshooting#Client_Installation >>>> https://fedorahosted.org/sssd/wiki/Troubleshooting >>>> >>>> >>>> >>>> On 20 March 2015 at 22:37, Dmitri Pal wrote: >>>> >>>>> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >>>>> >>>>> It certainly gets there, because the client gets in fact enrolled as >>>>> a domain host. I can see it from the UI in Identity / Hosts. But not in the >>>>> DNS zone. >>>>> >>>>> *Before ipa-client-install, all these do work: * >>>>> >>>>> $ ssh ipa.hq.example.com >>>>> $ ntpdate ipa.hq.example.com >>>>> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com >>>>> uid=admin >>>>> >>>>> >>>>> *After running ipa-client-install, all these do work:* >>>>> >>>>> $ kinit admin >>>>> Password for admin at HQ.EXAMPLE.COM: >>>>> $ ipa dnszone-show --all >>>>> [...] >>>>> $ ntpq -p >>>>> remote refid st t when poll reach delay offset >>>>> jitter >>>>> >>>>> ============================================================================== >>>>> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 -0.006 >>>>> 0.000 >>>>> LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 >>>>> 0.000 >>>>> >>>>> *But this does NOT work:* >>>>> $ getent passwd admin at hq.example.com >>>>> >>>>> >>>>> What do SSSD logs show on the client? >>>>> Please rise the SSSD debug_level and provide SSSD logs. >>>>> >>>>> >>>>> *On the server, in /var/log/krb5kdc.log, I see many of these:* >>>>> >>>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >>>>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: >>>>> admin at HQ.EXAMPLE.COM for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM, >>>>> Additional pre-authentication required >>>>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >>>>> etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime >>>>> 1426884797, etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM for >>>>> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>>>> >>>>> >>>>> This is not an error. It is a normal user authentication. >>>>> OK so it is DNS that is not working. Is DNS server running on the >>>>> server? >>>>> What do Bind logs show? >>>>> >>>>> >>>>> >>>>> 192.168.0.207 is the IP of the client I'm trying to install. >>>>> However, higher up in the log, I also see such errors for the ipa server >>>>> itself. >>>>> >>>>> On 20 March 2015 at 20:24, Dmitri Pal wrote: >>>>> >>>>>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>>>>> >>>>>> No, all real machines. >>>>>> >>>>>> I'm really sorry it's taking so much of your time. >>>>>> I had tried almost everything on a VM setting first, and everything >>>>>> was fine. >>>>>> Everything always works fine, until you actually need it. >>>>>> >>>>>> >>>>>> >>>>>> We try to help as much as we can. >>>>>> Can you do LDAP lookups as a directory manager from client host to >>>>>> server? >>>>>> Can you ssh from client to server? >>>>>> >>>>>> When you try to install client is there anything in the logs on the >>>>>> server? Does it even get there? >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 20 March 2015 at 19:41, Dmitri Pal wrote: >>>>>> >>>>>>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>>>>>> >>>>>>> But the ipa server itself is also enrolled as a client, just after >>>>>>> the server installation, right?. And that worked fine. >>>>>>> >>>>>>> >>>>>>> Are these VMs? >>>>>>> There have been a similar case when the network was not set properly >>>>>>> for the virtual test environment. >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 20 March 2015 at 18:55, Roberto Cornacchia < >>>>>>> roberto.cornacchia at gmail.com> wrote: >>>>>>> >>>>>>>> No, sorry about the confusion, i shouldn't have posted so quickly. >>>>>>>> >>>>>>>> When I use the correct domain (hq.example.com), then I really get >>>>>>>> all the same errors as before, also in the new client. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 20 Mar 2015 18:39, "Dmitri Pal" wrote: >>>>>>>> >>>>>>>>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>>>>>>> >>>>>>>>> Oops. Not true, forget last email. >>>>>>>>> >>>>>>>>> This secon client installation went different just because it >>>>>>>>> took the wrong domain. >>>>>>>>> It used *example.com * (what was previously >>>>>>>>> set) instead of *hq.example.com * >>>>>>>>> >>>>>>>>> Uninstalled, tried again with --hostname=photon.hq.example.com >>>>>>>>> And then it behaves precisely like the previous client. >>>>>>>>> >>>>>>>>> So something seems wrong in the server. >>>>>>>>> >>>>>>>>> On 20 March 2015 at 18:18, Roberto Cornacchia < >>>>>>>>> roberto.cornacchia at gmail.com> wrote: >>>>>>>>> >>>>>>>>>> Update: >>>>>>>>>> I tried from another client. Also FC21, same network, same >>>>>>>>>> settings from the same DHCP. >>>>>>>>>> But obviously it must have something different because it >>>>>>>>>> partially succeeded. >>>>>>>>>> >>>>>>>>>> - I do not get errors about LDAP users. >>>>>>>>>> - I do not get errors about DNS update >>>>>>>>>> >>>>>>>>>> However: >>>>>>>>>> - I still get the initial error about NTP >>>>>>>>>> - The host is enrolled, but not added to the DNS zone >>>>>>>>>> >>>>>>>>>> Now, I don't care much about the previous client. It was pretty >>>>>>>>>> much empty and can re-install Fedora from scratch. >>>>>>>>>> >>>>>>>>>> But I'd like to understand if this is still a problem. >>>>>>>>>> It should be added to the zone, shouldn't it? >>>>>>>>>> >>>>>>>>>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>>>>>>>>> Discovery was successful! >>>>>>>>>> Hostname: photon.example.com >>>>>>>>>> Realm: HQ.EXAMPLE.COM >>>>>>>>>> DNS Domain: hq.example.com >>>>>>>>>> IPA Server: ipa.hq.example.com >>>>>>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>>>>>> >>>>>>>>>> Continue to configure the system with these values? [no]: yes >>>>>>>>>> Synchronizing time with KDC... >>>>>>>>>> *Unable to sync time with IPA NTP server, assuming the time is in >>>>>>>>>> sync. Please check that 123 UDP port is opened.* >>>>>>>>>> User authorized to enroll computers: admin >>>>>>>>>> Password for admin at HQ.EXAMPLE.COM: >>>>>>>>>> Successfully retrieved CA cert >>>>>>>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>>>>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>>>>>>> >>>>>>>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>>>>>>> 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 HQ.EXAMPLE.COM >>>>>>>>>> trying https://ipa.hq.example.com/ipa/json >>>>>>>>>> Forwarding 'ping' to json server ' >>>>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>>>> Forwarding 'ca_is_enabled' to json server ' >>>>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>>>> Systemwide CA database updated. >>>>>>>>>> Added CA certificates to the default NSS database. >>>>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>>>>>>>> Forwarding 'host_mod' to json server ' >>>>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>>>> *Could not update DNS SSHFP records.* >>>>>>>>>> SSSD enabled >>>>>>>>>> Configured /etc/openldap/ldap.conf >>>>>>>>>> NTP enabled >>>>>>>>>> Configured /etc/ssh/ssh_config >>>>>>>>>> Configured /etc/ssh/sshd_config >>>>>>>>>> Configuring hq.example.com as NIS domain. >>>>>>>>>> Client configuration complete. >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> It is different. It does not have the same failure about admin as >>>>>>>>> you had in the first email. >>>>>>>>> So may be it is the permissions issue and a separate NTP issue? >>>>>>>>> Did you play with any permissions on the server side? >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> 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. >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>>> -- >>>> 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. > > > -- > 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 roberto.cornacchia at gmail.com Sat Mar 21 15:56:40 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Sat, 21 Mar 2015 16:56:40 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550CB4D5.6010303@redhat.com> References: <550C0519.1040609@redhat.com> <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> Message-ID: Indeed, id admin does not work and there is no sign of it in the log. >From the client (with admin-tools installed): $ kinit admin Password for admin at HQ.EXAMPLE.COM: $ ipa user-show admin User login: admin Last name: Administrator Home directory: /home/admin Login shell: /bin/bash UID: 1172000000 GID: 1172000000 Account disabled: False Password: True Member of groups: trust admins, admins Kerberos keys available: True $ id admin id: admin: no such user $ getent passwd admin at hq.spinque.com $ grep admin /var/log/sssd/* $ On 21 March 2015 at 01:01, Dmitri Pal wrote: > On 03/20/2015 07:40 PM, Roberto Cornacchia wrote: > > Two log files in attachment (the other files in /var/log/sssd are all > empty). > > I'll also go through the troubleshooting page again, thanks > > > Do the logs include an id call for admin? > I do not see any instance of the word "admin" in the log. > > > > On 20 March 2015 at 23:03, Dmitri Pal wrote: > >> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: >> >> SSSD logs are empty so far. >> >> >> This is wrong. >> >> Isn't sssd.conf written by ipa-client-install? >> >> >> Yes >> >> If I raise the debug level after client installation, >> >> >> (and restart) >> >> what activities do you suggest to attempt from the client? >> >> the ones that fail. getent call that returns nothing. >> Also try 'id'. >> >> http://www.freeipa.org/page/Troubleshooting#Client_Installation >> https://fedorahosted.org/sssd/wiki/Troubleshooting >> >> >> >> On 20 March 2015 at 22:37, Dmitri Pal wrote: >> >>> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >>> >>> It certainly gets there, because the client gets in fact enrolled as a >>> domain host. I can see it from the UI in Identity / Hosts. But not in the >>> DNS zone. >>> >>> *Before ipa-client-install, all these do work: * >>> >>> $ ssh ipa.hq.example.com >>> $ ntpdate ipa.hq.example.com >>> $ ldapsearch -x -h ipa.hq.example.com -b dc=hq,dc=example,dc=com >>> uid=admin >>> >>> >>> *After running ipa-client-install, all these do work:* >>> >>> $ kinit admin >>> Password for admin at HQ.EXAMPLE.COM: >>> $ ipa dnszone-show --all >>> [...] >>> $ ntpq -p >>> remote refid st t when poll reach delay offset >>> jitter >>> >>> ============================================================================== >>> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 0.415 -0.006 >>> 0.000 >>> LOCAL(0) .LOCL. 5 l - 64 0 0.000 0.000 >>> 0.000 >>> >>> *But this does NOT work:* >>> $ getent passwd admin at hq.example.com >>> >>> >>> What do SSSD logs show on the client? >>> Please rise the SSSD debug_level and provide SSSD logs. >>> >>> >>> *On the server, in /var/log/krb5kdc.log, I see many of these:* >>> >>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 192.168.0.207: NEEDED_PREAUTH: >>> admin at HQ.EXAMPLE.COM for krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM, >>> Additional pre-authentication required >>> Mar 20 21:53:17 ipa.hq.example.com krb5kdc[9229](info): AS_REQ (6 >>> etypes {18 17 16 23 25 26}) 192.168.0.207: ISSUE: authtime 1426884797, >>> etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM for krbtgt/ >>> HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>> >>> >>> This is not an error. It is a normal user authentication. >>> OK so it is DNS that is not working. Is DNS server running on the server? >>> What do Bind logs show? >>> >>> >>> >>> 192.168.0.207 is the IP of the client I'm trying to install. However, >>> higher up in the log, I also see such errors for the ipa server itself. >>> >>> On 20 March 2015 at 20:24, Dmitri Pal wrote: >>> >>>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>>> >>>> No, all real machines. >>>> >>>> I'm really sorry it's taking so much of your time. >>>> I had tried almost everything on a VM setting first, and everything was >>>> fine. >>>> Everything always works fine, until you actually need it. >>>> >>>> >>>> >>>> We try to help as much as we can. >>>> Can you do LDAP lookups as a directory manager from client host to >>>> server? >>>> Can you ssh from client to server? >>>> >>>> When you try to install client is there anything in the logs on the >>>> server? Does it even get there? >>>> >>>> >>>> >>>> >>>> >>>> >>>> On 20 March 2015 at 19:41, Dmitri Pal wrote: >>>> >>>>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>>>> >>>>> But the ipa server itself is also enrolled as a client, just after the >>>>> server installation, right?. And that worked fine. >>>>> >>>>> >>>>> Are these VMs? >>>>> There have been a similar case when the network was not set properly >>>>> for the virtual test environment. >>>>> >>>>> >>>>> >>>>> On 20 March 2015 at 18:55, Roberto Cornacchia < >>>>> roberto.cornacchia at gmail.com> wrote: >>>>> >>>>>> No, sorry about the confusion, i shouldn't have posted so quickly. >>>>>> >>>>>> When I use the correct domain (hq.example.com), then I really get >>>>>> all the same errors as before, also in the new client. >>>>>> >>>>>> >>>>>> >>>>>> On 20 Mar 2015 18:39, "Dmitri Pal" wrote: >>>>>> >>>>>>> On 03/20/2015 01:25 PM, Roberto Cornacchia wrote: >>>>>>> >>>>>>> Oops. Not true, forget last email. >>>>>>> >>>>>>> This secon client installation went different just because it took >>>>>>> the wrong domain. >>>>>>> It used *example.com * (what was previously >>>>>>> set) instead of *hq.example.com * >>>>>>> >>>>>>> Uninstalled, tried again with --hostname=photon.hq.example.com >>>>>>> And then it behaves precisely like the previous client. >>>>>>> >>>>>>> So something seems wrong in the server. >>>>>>> >>>>>>> On 20 March 2015 at 18:18, Roberto Cornacchia < >>>>>>> roberto.cornacchia at gmail.com> wrote: >>>>>>> >>>>>>>> Update: >>>>>>>> I tried from another client. Also FC21, same network, same settings >>>>>>>> from the same DHCP. >>>>>>>> But obviously it must have something different because it partially >>>>>>>> succeeded. >>>>>>>> >>>>>>>> - I do not get errors about LDAP users. >>>>>>>> - I do not get errors about DNS update >>>>>>>> >>>>>>>> However: >>>>>>>> - I still get the initial error about NTP >>>>>>>> - The host is enrolled, but not added to the DNS zone >>>>>>>> >>>>>>>> Now, I don't care much about the previous client. It was pretty >>>>>>>> much empty and can re-install Fedora from scratch. >>>>>>>> >>>>>>>> But I'd like to understand if this is still a problem. >>>>>>>> It should be added to the zone, shouldn't it? >>>>>>>> >>>>>>>> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >>>>>>>> Discovery was successful! >>>>>>>> Hostname: photon.example.com >>>>>>>> Realm: HQ.EXAMPLE.COM >>>>>>>> DNS Domain: hq.example.com >>>>>>>> IPA Server: ipa.hq.example.com >>>>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>>>> >>>>>>>> Continue to configure the system with these values? [no]: yes >>>>>>>> Synchronizing time with KDC... >>>>>>>> *Unable to sync time with IPA NTP server, assuming the time is in >>>>>>>> sync. Please check that 123 UDP port is opened.* >>>>>>>> User authorized to enroll computers: admin >>>>>>>> Password for admin at HQ.EXAMPLE.COM: >>>>>>>> Successfully retrieved CA cert >>>>>>>> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >>>>>>>> Valid From: Mon Mar 16 18:44:35 2015 UTC >>>>>>>> Valid Until: Fri Mar 16 18:44:35 2035 UTC >>>>>>>> >>>>>>>> Enrolled in IPA realm HQ.EXAMPLE.COM >>>>>>>> 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 HQ.EXAMPLE.COM >>>>>>>> trying https://ipa.hq.example.com/ipa/json >>>>>>>> Forwarding 'ping' to json server ' >>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>> Forwarding 'ca_is_enabled' to json server ' >>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>> Systemwide CA database updated. >>>>>>>> Added CA certificates to the default NSS database. >>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_dsa_key.pub >>>>>>>> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >>>>>>>> Forwarding 'host_mod' to json server ' >>>>>>>> https://ipa.hq.example.com/ipa/json' >>>>>>>> *Could not update DNS SSHFP records.* >>>>>>>> SSSD enabled >>>>>>>> Configured /etc/openldap/ldap.conf >>>>>>>> NTP enabled >>>>>>>> Configured /etc/ssh/ssh_config >>>>>>>> Configured /etc/ssh/sshd_config >>>>>>>> Configuring hq.example.com as NIS domain. >>>>>>>> Client configuration complete. >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> It is different. It does not have the same failure about admin as >>>>>>> you had in the first email. >>>>>>> So may be it is the permissions issue and a separate NTP issue? >>>>>>> Did you play with any permissions on the server side? >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> 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. >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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 Sat Mar 21 16:05:00 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 21 Mar 2015 12:05:00 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> Message-ID: <550D96AC.2070308@redhat.com> Roberto Cornacchia wrote: > Indeed, id admin does not work and there is no sign of it in the log. > > From the client (with admin-tools installed): > > $ kinit admin > Password for admin at HQ.EXAMPLE.COM : > $ ipa user-show admin > User login: admin > Last name: Administrator > Home directory: /home/admin > Login shell: /bin/bash > UID: 1172000000 > GID: 1172000000 > Account disabled: False > Password: True > Member of groups: trust admins, admins > Kerberos keys available: True > $ id admin > id: admin: no such user > $ getent passwd admin at hq.spinque.com > $ grep admin /var/log/sssd/* > $ This is because sssd is not configured in nsswitch.conf to serve anything other than sudo. I see in the client install log you posted in the first message of the thread that there was no pre-existing sssd.conf so it created a new one, but that shouldn't be an issue. What does sssd.conf look like and is sssd running? rob > > > On 21 March 2015 at 01:01, Dmitri Pal > wrote: > > On 03/20/2015 07:40 PM, Roberto Cornacchia wrote: >> Two log files in attachment (the other files in /var/log/sssd are >> all empty). >> >> I'll also go through the troubleshooting page again, thanks >> > > Do the logs include an id call for admin? > I do not see any instance of the word "admin" in the log. > > >> >> On 20 March 2015 at 23:03, Dmitri Pal > > wrote: >> >> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: >>> SSSD logs are empty so far. >> >> This is wrong. >> >>> Isn't sssd.conf written by ipa-client-install? >> >> Yes >> >>> If I raise the debug level after client installation, >> >> (and restart) >> >>> what activities do you suggest to attempt from the client? >> the ones that fail. getent call that returns nothing. >> Also try 'id'. >> >> http://www.freeipa.org/page/Troubleshooting#Client_Installation >> https://fedorahosted.org/sssd/wiki/Troubleshooting >> >>> >>> >>> On 20 March 2015 at 22:37, Dmitri Pal >> > wrote: >>> >>> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: >>>> It certainly gets there, because the client gets in fact >>>> enrolled as a domain host. I can see it from the UI in >>>> Identity / Hosts. But not in the DNS zone. >>>> >>>> *Before ipa-client-install, all these do work: * >>>> >>>> $ ssh ipa.hq.example.com >>>> $ ntpdate ipa.hq.example.com >>>> $ ldapsearch -x -h ipa.hq.example.com >>>> -b dc=hq,dc=example,dc=com >>>> uid=admin >>>> >>>> >>>> *After running ipa-client-install, all these do work:* >>>> >>>> $ kinit admin >>>> Password for admin at HQ.EXAMPLE.COM >>>> : >>>> $ ipa dnszone-show --all >>>> [...] >>>> $ ntpq -p >>>> remote refid st t when poll reach >>>> delay offset jitter >>>> ============================================================================== >>>> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 >>>> 0.415 -0.006 0.000 >>>> LOCAL(0) .LOCL. 5 l - 64 0 >>>> 0.000 0.000 0.000 >>>> >>>> *But this does NOT work:* >>>> $ getent passwd admin at hq.example.com >>>> >>> >>> What do SSSD logs show on the client? >>> Please rise the SSSD debug_level and provide SSSD logs. >>> >>>> >>>> *On the server, in /var/log/krb5kdc.log, I see many of >>>> these:* >>>> >>>> Mar 20 21:53:17 ipa.hq.example.com >>>> krb5kdc[9229](info): AS_REQ >>>> (6 etypes {18 17 16 23 25 26}) 192.168.0.207 >>>> : NEEDED_PREAUTH: >>>> admin at HQ.EXAMPLE.COM for >>>> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>>> , Additional >>>> pre-authentication required >>>> Mar 20 21:53:17 ipa.hq.example.com >>>> krb5kdc[9229](info): AS_REQ >>>> (6 etypes {18 17 16 23 25 26}) 192.168.0.207 >>>> : ISSUE: authtime 1426884797, >>>> etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM >>>> for >>>> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM >>>> >>> >>> This is not an error. It is a normal user authentication. >>> OK so it is DNS that is not working. Is DNS server >>> running on the server? >>> What do Bind logs show? >>> >>> >>>> >>>> 192.168.0.207 is the IP of the client I'm trying to >>>> install. However, higher up in the log, I also see such >>>> errors for the ipa server itself. >>>> >>>> On 20 March 2015 at 20:24, Dmitri Pal >>> > wrote: >>>> >>>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: >>>>> No, all real machines. >>>>> >>>>> I'm really sorry it's taking so much of your time. >>>>> I had tried almost everything on a VM setting >>>>> first, and everything was fine. >>>>> Everything always works fine, until you actually >>>>> need it. >>>> >>>> >>>> We try to help as much as we can. >>>> Can you do LDAP lookups as a directory manager from >>>> client host to server? >>>> Can you ssh from client to server? >>>> >>>> When you try to install client is there anything in >>>> the logs on the server? Does it even get there? >>>> >>>> >>>> >>>> >>>>> >>>>> >>>>> On 20 March 2015 at 19:41, Dmitri Pal >>>>> > wrote: >>>>> >>>>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: >>>>>> But the ipa server itself is also enrolled as >>>>>> a client, just after the server installation, >>>>>> right?. And that worked fine. >>>>> >>>>> Are these VMs? >>>>> There have been a similar case when the network >>>>> was not set properly for the virtual test >>>>> environment. >>>>> >>>>> >>>>>> >>>>>> On 20 March 2015 at 18:55, Roberto Cornacchia >>>>>> >>>>> > wrote: >>>>>> >>>>>> No, sorry about the confusion, i shouldn't >>>>>> have posted so quickly. >>>>>> >>>>>> When I use the correct domain >>>>>> (hq.example.com ), >>>>>> then I really get all the same errors as >>>>>> before, also in the new client. >>>>>> >>>>>> >>>>>> >>>>>> On 20 Mar 2015 18:39, "Dmitri Pal" >>>>>> > >>>>>> wrote: >>>>>> >>>>>> On 03/20/2015 01:25 PM, Roberto >>>>>> Cornacchia wrote: >>>>>>> Oops. Not true, forget last email. >>>>>>> >>>>>>> This secon client installation went >>>>>>> different just because it took the >>>>>>> wrong domain. >>>>>>> It used *example.com >>>>>>> * (what was >>>>>>> previously set) instead of >>>>>>> *hq.example.com * >>>>>>> >>>>>>> Uninstalled, tried again with >>>>>>> --hostname=photon.hq.example.com >>>>>>> >>>>>>> And then it behaves precisely like >>>>>>> the previous client. >>>>>>> >>>>>>> So something seems wrong in the server. >>>>>>> >>>>>>> On 20 March 2015 at 18:18, Roberto >>>>>>> Cornacchia >>>>>>> >>>>>> > wrote: >>>>>>> >>>>>>> Update: >>>>>>> I tried from another client. Also >>>>>>> FC21, same network, same settings >>>>>>> from the same DHCP. >>>>>>> But obviously it must have >>>>>>> something different because it >>>>>>> partially succeeded. >>>>>>> >>>>>>> - I do not get errors about LDAP >>>>>>> users. >>>>>>> - I do not get errors about DNS >>>>>>> update >>>>>>> >>>>>>> However: >>>>>>> - I still get the initial error >>>>>>> about NTP >>>>>>> - The host is enrolled, but not >>>>>>> added to the DNS zone >>>>>>> >>>>>>> Now, I don't care much about the >>>>>>> previous client. It was pretty >>>>>>> much empty and can re-install >>>>>>> Fedora from scratch. >>>>>>> >>>>>>> But I'd like to understand if >>>>>>> this is still a problem. >>>>>>> It should be added to the zone, >>>>>>> shouldn't it? >>>>>>> >>>>>>> $ ipa-client-install --mkhomedir >>>>>>> --ssh-trust-dns --force-ntpd >>>>>>> Discovery was successful! >>>>>>> Hostname: photon.example.com >>>>>>> >>>>>>> Realm: HQ.EXAMPLE.COM >>>>>>> >>>>>>> DNS Domain: hq.example.com >>>>>>> >>>>>>> IPA Server: ipa.hq.example.com >>>>>>> >>>>>>> BaseDN: dc=hq,dc=example,dc=com >>>>>>> >>>>>>> Continue to configure the system >>>>>>> with these values? [no]: yes >>>>>>> Synchronizing time with KDC... >>>>>>> *Unable to sync time with IPA NTP >>>>>>> server, assuming the time is in >>>>>>> sync. Please check that 123 UDP >>>>>>> port is opened.* >>>>>>> User authorized to enroll >>>>>>> computers: admin >>>>>>> Password for admin at HQ.EXAMPLE.COM >>>>>>> : >>>>>>> Successfully retrieved CA cert >>>>>>> Subject: CN=Certificate >>>>>>> Authority,O=HQ.EXAMPLE.COM >>>>>>> >>>>>>> Issuer: CN=Certificate >>>>>>> Authority,O=HQ.EXAMPLE.COM >>>>>>> >>>>>>> Valid From: Mon Mar 16 >>>>>>> 18:44:35 2015 UTC >>>>>>> Valid Until: Fri Mar 16 >>>>>>> 18:44:35 2035 UTC >>>>>>> >>>>>>> Enrolled in IPA realm >>>>>>> HQ.EXAMPLE.COM >>>>>>> >>>>>>> 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 HQ.EXAMPLE.COM >>>>>>> >>>>>>> trying >>>>>>> https://ipa.hq.example.com/ipa/json >>>>>>> Forwarding 'ping' to json server >>>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>>> Forwarding 'ca_is_enabled' to >>>>>>> json server >>>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>>> Systemwide CA database updated. >>>>>>> Added CA certificates to the >>>>>>> default NSS database. >>>>>>> Adding SSH public key from >>>>>>> /etc/ssh/ssh_host_rsa_key.pub >>>>>>> Adding SSH public key from >>>>>>> /etc/ssh/ssh_host_ed25519_key.pub >>>>>>> Adding SSH public key from >>>>>>> /etc/ssh/ssh_host_dsa_key.pub >>>>>>> Adding SSH public key from >>>>>>> /etc/ssh/ssh_host_ecdsa_key.pub >>>>>>> Forwarding 'host_mod' to json >>>>>>> server >>>>>>> 'https://ipa.hq.example.com/ipa/json' >>>>>>> *Could not update DNS SSHFP records.* >>>>>>> SSSD enabled >>>>>>> Configured /etc/openldap/ldap.conf >>>>>>> NTP enabled >>>>>>> Configured /etc/ssh/ssh_config >>>>>>> Configured /etc/ssh/sshd_config >>>>>>> Configuring hq.example.com >>>>>>> as NIS >>>>>>> domain. >>>>>>> Client configuration complete. >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>>> It is different. It does not have the >>>>>> same failure about admin as you had in >>>>>> the first email. >>>>>> So may be it is the permissions issue >>>>>> and a separate NTP issue? >>>>>> Did you play with any permissions on >>>>>> the server side? >>>>>> >>>>>> >>>>>> -- >>>>>> 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. >>>>> >>>>> >>>>> -- >>>>> 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. >>>> >>>> >>>> -- >>>> 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. >>> >>> >>> -- >>> 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. >> >> >> -- >> 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. > > > -- > 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 roberto.cornacchia at gmail.com Sat Mar 21 16:16:00 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Sat, 21 Mar 2015 17:16:00 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550D96AC.2070308@redhat.com> References: <550C4599.7040806@redhat.com> <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> Message-ID: Hi Rob, Yes, sssd is running and this is sssd.conf: [domain/hq.example.com] debug_level=9 cache_credentials = True krb5_store_password_if_offline = True ipa_domain = hq.example.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = meson.hq.example.com chpass_provider = ipa ipa_server = _srv_, ipa.hq.example.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, sudo, pam, ssh config_file_version = 2 domains = hq.example.com [nss] homedir_substring = /home debug_level=9 [pam] [sudo] [autofs] [ssh] [pac] [ifp] On 21 March 2015 at 17:05, Rob Crittenden wrote: > Roberto Cornacchia wrote: > > Indeed, id admin does not work and there is no sign of it in the log. > > > > From the client (with admin-tools installed): > > > > $ kinit admin > > Password for admin at HQ.EXAMPLE.COM : > > $ ipa user-show admin > > User login: admin > > Last name: Administrator > > Home directory: /home/admin > > Login shell: /bin/bash > > UID: 1172000000 > > GID: 1172000000 > > Account disabled: False > > Password: True > > Member of groups: trust admins, admins > > Kerberos keys available: True > > $ id admin > > id: admin: no such user > > $ getent passwd admin at hq.spinque.com > > $ grep admin /var/log/sssd/* > > $ > > This is because sssd is not configured in nsswitch.conf to serve > anything other than sudo. > > I see in the client install log you posted in the first message of the > thread that there was no pre-existing sssd.conf so it created a new one, > but that shouldn't be an issue. > > What does sssd.conf look like and is sssd running? > > rob > > > > > > > On 21 March 2015 at 01:01, Dmitri Pal > > wrote: > > > > On 03/20/2015 07:40 PM, Roberto Cornacchia wrote: > >> Two log files in attachment (the other files in /var/log/sssd are > >> all empty). > >> > >> I'll also go through the troubleshooting page again, thanks > >> > > > > Do the logs include an id call for admin? > > I do not see any instance of the word "admin" in the log. > > > > > >> > >> On 20 March 2015 at 23:03, Dmitri Pal >> > wrote: > >> > >> On 03/20/2015 05:59 PM, Roberto Cornacchia wrote: > >>> SSSD logs are empty so far. > >> > >> This is wrong. > >> > >>> Isn't sssd.conf written by ipa-client-install? > >> > >> Yes > >> > >>> If I raise the debug level after client installation, > >> > >> (and restart) > >> > >>> what activities do you suggest to attempt from the client? > >> the ones that fail. getent call that returns nothing. > >> Also try 'id'. > >> > >> http://www.freeipa.org/page/Troubleshooting#Client_Installation > >> https://fedorahosted.org/sssd/wiki/Troubleshooting > >> > >>> > >>> > >>> On 20 March 2015 at 22:37, Dmitri Pal >>> > wrote: > >>> > >>> On 03/20/2015 05:28 PM, Roberto Cornacchia wrote: > >>>> It certainly gets there, because the client gets in fact > >>>> enrolled as a domain host. I can see it from the UI in > >>>> Identity / Hosts. But not in the DNS zone. > >>>> > >>>> *Before ipa-client-install, all these do work: * > >>>> > >>>> $ ssh ipa.hq.example.com > >>>> $ ntpdate ipa.hq.example.com > >>>> $ ldapsearch -x -h ipa.hq.example.com > >>>> -b dc=hq,dc=example,dc=com > >>>> uid=admin > >>>> > >>>> > >>>> *After running ipa-client-install, all these do work:* > >>>> > >>>> $ kinit admin > >>>> Password for admin at HQ.EXAMPLE.COM > >>>> : > >>>> $ ipa dnszone-show --all > >>>> [...] > >>>> $ ntpq -p > >>>> remote refid st t when poll reach > >>>> delay offset jitter > >>>> > ============================================================================== > >>>> *ipa.hq.example. 131.155.140.130 3 u 19 64 1 > >>>> 0.415 -0.006 0.000 > >>>> LOCAL(0) .LOCL. 5 l - 64 0 > >>>> 0.000 0.000 0.000 > >>>> > >>>> *But this does NOT work:* > >>>> $ getent passwd admin at hq.example.com > >>>> > >>> > >>> What do SSSD logs show on the client? > >>> Please rise the SSSD debug_level and provide SSSD logs. > >>> > >>>> > >>>> *On the server, in /var/log/krb5kdc.log, I see many of > >>>> these:* > >>>> > >>>> Mar 20 21:53:17 ipa.hq.example.com > >>>> krb5kdc[9229](info): AS_REQ > >>>> (6 etypes {18 17 16 23 25 26}) 192.168.0.207 > >>>> : NEEDED_PREAUTH: > >>>> admin at HQ.EXAMPLE.COM for > >>>> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM > >>>> , Additional > >>>> pre-authentication required > >>>> Mar 20 21:53:17 ipa.hq.example.com > >>>> krb5kdc[9229](info): AS_REQ > >>>> (6 etypes {18 17 16 23 25 26}) 192.168.0.207 > >>>> : ISSUE: authtime 1426884797, > >>>> etypes {rep=18 tkt=18 ses=18}, admin at HQ.EXAMPLE.COM > >>>> for > >>>> krbtgt/HQ.EXAMPLE.COM at HQ.EXAMPLE.COM > >>>> > >>> > >>> This is not an error. It is a normal user authentication. > >>> OK so it is DNS that is not working. Is DNS server > >>> running on the server? > >>> What do Bind logs show? > >>> > >>> > >>>> > >>>> 192.168.0.207 is the IP of the client I'm trying to > >>>> install. However, higher up in the log, I also see such > >>>> errors for the ipa server itself. > >>>> > >>>> On 20 March 2015 at 20:24, Dmitri Pal >>>> > wrote: > >>>> > >>>> On 03/20/2015 02:48 PM, Roberto Cornacchia wrote: > >>>>> No, all real machines. > >>>>> > >>>>> I'm really sorry it's taking so much of your time. > >>>>> I had tried almost everything on a VM setting > >>>>> first, and everything was fine. > >>>>> Everything always works fine, until you actually > >>>>> need it. > >>>> > >>>> > >>>> We try to help as much as we can. > >>>> Can you do LDAP lookups as a directory manager from > >>>> client host to server? > >>>> Can you ssh from client to server? > >>>> > >>>> When you try to install client is there anything in > >>>> the logs on the server? Does it even get there? > >>>> > >>>> > >>>> > >>>> > >>>>> > >>>>> > >>>>> On 20 March 2015 at 19:41, Dmitri Pal > >>>>> > wrote: > >>>>> > >>>>> On 03/20/2015 01:57 PM, Roberto Cornacchia wrote: > >>>>>> But the ipa server itself is also enrolled as > >>>>>> a client, just after the server installation, > >>>>>> right?. And that worked fine. > >>>>> > >>>>> Are these VMs? > >>>>> There have been a similar case when the network > >>>>> was not set properly for the virtual test > >>>>> environment. > >>>>> > >>>>> > >>>>>> > >>>>>> On 20 March 2015 at 18:55, Roberto Cornacchia > >>>>>> >>>>>> > wrote: > >>>>>> > >>>>>> No, sorry about the confusion, i shouldn't > >>>>>> have posted so quickly. > >>>>>> > >>>>>> When I use the correct domain > >>>>>> (hq.example.com ), > >>>>>> then I really get all the same errors as > >>>>>> before, also in the new client. > >>>>>> > >>>>>> > >>>>>> > >>>>>> On 20 Mar 2015 18:39, "Dmitri Pal" > >>>>>> > > >>>>>> wrote: > >>>>>> > >>>>>> On 03/20/2015 01:25 PM, Roberto > >>>>>> Cornacchia wrote: > >>>>>>> Oops. Not true, forget last email. > >>>>>>> > >>>>>>> This secon client installation went > >>>>>>> different just because it took the > >>>>>>> wrong domain. > >>>>>>> It used *example.com > >>>>>>> * (what was > >>>>>>> previously set) instead of > >>>>>>> *hq.example.com >* > >>>>>>> > >>>>>>> Uninstalled, tried again with > >>>>>>> --hostname=photon.hq.example.com > >>>>>>> > >>>>>>> And then it behaves precisely like > >>>>>>> the previous client. > >>>>>>> > >>>>>>> So something seems wrong in the server. > >>>>>>> > >>>>>>> On 20 March 2015 at 18:18, Roberto > >>>>>>> Cornacchia > >>>>>>> >>>>>>> > > wrote: > >>>>>>> > >>>>>>> Update: > >>>>>>> I tried from another client. Also > >>>>>>> FC21, same network, same settings > >>>>>>> from the same DHCP. > >>>>>>> But obviously it must have > >>>>>>> something different because it > >>>>>>> partially succeeded. > >>>>>>> > >>>>>>> - I do not get errors about LDAP > >>>>>>> users. > >>>>>>> - I do not get errors about DNS > >>>>>>> update > >>>>>>> > >>>>>>> However: > >>>>>>> - I still get the initial error > >>>>>>> about NTP > >>>>>>> - The host is enrolled, but not > >>>>>>> added to the DNS zone > >>>>>>> > >>>>>>> Now, I don't care much about the > >>>>>>> previous client. It was pretty > >>>>>>> much empty and can re-install > >>>>>>> Fedora from scratch. > >>>>>>> > >>>>>>> But I'd like to understand if > >>>>>>> this is still a problem. > >>>>>>> It should be added to the zone, > >>>>>>> shouldn't it? > >>>>>>> > >>>>>>> $ ipa-client-install --mkhomedir > >>>>>>> --ssh-trust-dns --force-ntpd > >>>>>>> Discovery was successful! > >>>>>>> Hostname: photon.example.com > >>>>>>> > >>>>>>> Realm: HQ.EXAMPLE.COM > >>>>>>> > >>>>>>> DNS Domain: hq.example.com > >>>>>>> > >>>>>>> IPA Server: ipa.hq.example.com > >>>>>>> > >>>>>>> BaseDN: dc=hq,dc=example,dc=com > >>>>>>> > >>>>>>> Continue to configure the system > >>>>>>> with these values? [no]: yes > >>>>>>> Synchronizing time with KDC... > >>>>>>> *Unable to sync time with IPA NTP > >>>>>>> server, assuming the time is in > >>>>>>> sync. Please check that 123 UDP > >>>>>>> port is opened.* > >>>>>>> User authorized to enroll > >>>>>>> computers: admin > >>>>>>> Password for admin at HQ.EXAMPLE.COM > >>>>>>> : > >>>>>>> Successfully retrieved CA cert > >>>>>>> Subject: CN=Certificate > >>>>>>> Authority,O=HQ.EXAMPLE.COM > >>>>>>> > >>>>>>> Issuer: CN=Certificate > >>>>>>> Authority,O=HQ.EXAMPLE.COM > >>>>>>> > >>>>>>> Valid From: Mon Mar 16 > >>>>>>> 18:44:35 2015 UTC > >>>>>>> Valid Until: Fri Mar 16 > >>>>>>> 18:44:35 2035 UTC > >>>>>>> > >>>>>>> Enrolled in IPA realm > >>>>>>> HQ.EXAMPLE.COM > >>>>>>> > >>>>>>> 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 HQ.EXAMPLE.COM > >>>>>>> > >>>>>>> trying > >>>>>>> > https://ipa.hq.example.com/ipa/json > >>>>>>> Forwarding 'ping' to json server > >>>>>>> ' > https://ipa.hq.example.com/ipa/json' > >>>>>>> Forwarding 'ca_is_enabled' to > >>>>>>> json server > >>>>>>> ' > https://ipa.hq.example.com/ipa/json' > >>>>>>> Systemwide CA database updated. > >>>>>>> Added CA certificates to the > >>>>>>> default NSS database. > >>>>>>> Adding SSH public key from > >>>>>>> /etc/ssh/ssh_host_rsa_key.pub > >>>>>>> Adding SSH public key from > >>>>>>> /etc/ssh/ssh_host_ed25519_key.pub > >>>>>>> Adding SSH public key from > >>>>>>> /etc/ssh/ssh_host_dsa_key.pub > >>>>>>> Adding SSH public key from > >>>>>>> /etc/ssh/ssh_host_ecdsa_key.pub > >>>>>>> Forwarding 'host_mod' to json > >>>>>>> server > >>>>>>> ' > https://ipa.hq.example.com/ipa/json' > >>>>>>> *Could not update DNS SSHFP > records.* > >>>>>>> SSSD enabled > >>>>>>> Configured /etc/openldap/ldap.conf > >>>>>>> NTP enabled > >>>>>>> Configured /etc/ssh/ssh_config > >>>>>>> Configured /etc/ssh/sshd_config > >>>>>>> Configuring hq.example.com > >>>>>>> as NIS > >>>>>>> domain. > >>>>>>> Client configuration complete. > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>> > >>>>>> It is different. It does not have the > >>>>>> same failure about admin as you had in > >>>>>> the first email. > >>>>>> So may be it is the permissions issue > >>>>>> and a separate NTP issue? > >>>>>> Did you play with any permissions on > >>>>>> the server side? > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> 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. > >>>>> > >>>>> > >>>>> -- > >>>>> 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. > >>>> > >>>> > >>>> -- > >>>> 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. > >>> > >>> > >>> -- > >>> 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. > >> > >> > >> -- > >> 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. > > > > > > -- > > 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 Sat Mar 21 16:26:42 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 21 Mar 2015 12:26:42 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> Message-ID: <550D9BC2.5010604@redhat.com> Roberto Cornacchia wrote: > Hi Rob, > > Yes, sssd is running and this is sssd.conf: > > [domain/hq.example.com ] > debug_level=9 > cache_credentials = True > krb5_store_password_if_offline = True > ipa_domain = hq.example.com > id_provider = ipa > auth_provider = ipa > access_provider = ipa > ipa_hostname = meson.hq.example.com > chpass_provider = ipa > ipa_server = _srv_, ipa.hq.example.com > ldap_tls_cacert = /etc/ipa/ca.crt > [sssd] > services = nss, sudo, pam, ssh > config_file_version = 2 > > domains = hq.example.com > [nss] > homedir_substring = /home > debug_level=9 > > [pam] > > [sudo] > > [autofs] > > [ssh] > > [pac] > > [ifp] Ok, that's good. Maybe authconfig didn't do the right thing. I'd add sss to these values in /etc/nsswitch.conf, grepp'd from mine: passwd: files sss shadow: files sss group: files sss services: files sss netgroup: files sss automount: files sss sudoers: sss You've got quite a mix of odd things happening during install. It seems like DNS and firewall can be ruled out given that lots of other operations are working fine, and you've confirmed that NTP works pre-install. I guess working on a cleanish system, the things I'd look for on both client and server are the system logs to see if any errors are being thrown to syslog or service-specific logs. And I'd check for SELinux errors on the client if you're in enforcing mode. rob From dpal at redhat.com Sat Mar 21 17:42:06 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 21 Mar 2015 13:42:06 -0400 Subject: [Freeipa-users] Password entry through Trust not correct In-Reply-To: <6301806E96421841896741228C6B1A2764C5B76C@G4W3216.americas.hpqcorp.net> References: <6301806E96421841896741228C6B1A2764C5B76C@G4W3216.americas.hpqcorp.net> Message-ID: <550DAD6E.5060900@redhat.com> On 03/20/2015 08:56 PM, McEvoy, James wrote: > > When I look at the password entries for my rfc2307 account in Active > directory I get three different answers. > > The only correct one is on a server where I used sssd to join AD > directly ( the last one ). Do I need to configure > > rfc2307? When I configured the server to join AD directly I use the > option --enablerfc2307bis when I run authconfig. > > from a freeipa client: > > $ getent passwd jemcevoy at ENAS.NET > > jemcevoy at enas.net:*:10001:10004::/home/enas.net/jemcevoy: > > from the ipa server: > > [root at ipa ~]# getent passwd jemcevoy at ENAS.NET > > jemcevoy at enas.net:*:10001:10004:James > McEvoy:/home/enas.net/jemcevoy:/bin/bash > > from a server that joined AD directly using sssd: > > $ getent passwd jemcevoy at ENAS.NET > > jemcevoy:*:10001:10004:James McEvoy:/home/jemcevoy:/bin/bash > > > Hi, Let us step back. What versions of the server and of the client and on what platforms? When you set trust, how did you set it? It might be that IPA server did not detect that you have Posix extensions in AD. There is some heuristics involved so probably you should use explicit parameters to tell IPA whether you have posix in AD or not. -- 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 Mar 21 17:50:49 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sat, 21 Mar 2015 13:50:49 -0400 Subject: [Freeipa-users] Automatic client enrollment In-Reply-To: References: Message-ID: <550DAF79.8060503@redhat.com> On 03/21/2015 05:53 AM, Prasun Gera wrote: > Is it possible to completely automate the client enrollment process > similar to securenets in NIS? I'm trying to migrate NIS to IDM, and > hoping that it runs largely in auto-pilot mode. The kickstarter method > suggests adding host entries with a one time kerberos password to > launch unattended client installs. That, however, needs the admin's > involvement every time a new host has to be added. Securenets works > pretty well in our case since we can authenticate based on the IP > address. User addition is still manual, but that's all right since > that is infrequent. Is it possible to do something similar using IP > masks or fqdn regex in ipa ? > > No but if you trust your network you can create a host admin that would have the host add privilege and host enroll privilege and nothing else and use this admin. IMO it would be a nice enhancement to have a way to restrict such enrollments to specific subnets. The logic on the server would be something like this: Enrollment request comes in If host entry there? Yes - follow the current logic Check user privileges <-new Enroll Would you mind filing an RFE if this approach would work for you? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Sun Mar 22 00:57:59 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Sat, 21 Mar 2015 20:57:59 -0400 Subject: [Freeipa-users] Automatic client enrollment In-Reply-To: <550DAF79.8060503@redhat.com> References: <550DAF79.8060503@redhat.com> Message-ID: Yes, this approach would work, and it would be a good enhancement. It would make migration from NIS easier with very little impact to users. Are you saying that something like this can be implemented right now? Or do you mean that this is how it could be done in future ? How does a host submit a request to the host admin? Is there a host admin daemon that listens for these requests ? On Sat, Mar 21, 2015 at 1:50 PM, Dmitri Pal wrote: > On 03/21/2015 05:53 AM, Prasun Gera wrote: > > Is it possible to completely automate the client enrollment process > similar to securenets in NIS? I'm trying to migrate NIS to IDM, and hoping > that it runs largely in auto-pilot mode. The kickstarter method suggests > adding host entries with a one time kerberos password to launch unattended > client installs. That, however, needs the admin's involvement every time a > new host has to be added. Securenets works pretty well in our case since we > can authenticate based on the IP address. User addition is still manual, > but that's all right since that is infrequent. Is it possible to do > something similar using IP masks or fqdn regex in ipa ? > > > No but if you trust your network you can create a host admin that would > have the host add privilege and host enroll privilege and nothing else and > use this admin. > > IMO it would be a nice enhancement to have a way to restrict such > enrollments to specific subnets. The logic on the server would be something > like this: > > Enrollment request comes in > If host entry there? > Yes - follow the current logic > Check user privileges > <-new > Enroll > > Would you mind filing an RFE if this approach would work for you? > > -- > 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 janellenicole80 at gmail.com Sun Mar 22 05:10:20 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sat, 21 Mar 2015 22:10:20 -0700 Subject: [Freeipa-users] multiple ssh keys? Message-ID: <550E4EBC.5020104@gmail.com> Hello, I was wondering, I don't seem to be able to put multiple SSH keys into IPA? Am I missing something? it seems to replace the one that was there instead of adding an additional. ~J From mike at colovore.com Sun Mar 22 07:05:17 2015 From: mike at colovore.com (Michael Pawlak) Date: Sun, 22 Mar 2015 00:05:17 -0700 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting Message-ID: I am not able to setup a replica using the 'ipa-replica-prepare' command. After some debugging this appears related to the certmonger/dogtag system that is incorporated with FreeIPA. I am including the output below of any relevant logs / commands. ----- ipa-replica-prepare ----- ipa-replica-prepare newipa.example.com --ca=/etc/ipa/ca.crt --password 'somepassword' Preparing replica for newipa.example.com from ipa.example.com Creating SSL certificate for the Directory Server Certificate operation cannot be completed: Unable to communicate with CMS (Not Found) ----- ipa-getcert list ----- Number of certificates and requests being tracked: 8. Request ID '20140811232518': status: CA_UNREACHABLE ca-error: Server at https://ipa.example.com/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)). 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 subject: CN=ipa.example.com,O=EXAMPLE expires: 2016-08-11 23:24:36 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 '20140811232742': status: CA_UNREACHABLE ca-error: Server at https://ipa.example.com/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)). stuck: no key pair storage: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS Certificate DB',pinfile='/etc/dirsrv/slapd-COLOVORE/pwdfile.txt' certificate: type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS Certificate DB' CA: IPA issuer: CN=Certificate Authority,O=EXAMPLE subject: CN=ipa.example.com,O=EXAMPLE expires: 2016-08-11 23:24:34 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 '20140811232843': status: CA_UNREACHABLE ca-error: Server at https://ipa.example.com/ipa/xml failed request, will retry: 4301 (RPC failed at server. Certificate operation cannot be completed: Unable to communicate with CMS (Not Found)). 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 subject: CN=ipa.example.com,O=EXAMPLE expires: 2016-08-11 23:24:37 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 ----- /etc/pki-ca/password.conf ----- internal=829325937546 internaldb=somepassword replicationdb=1270571739 ----- /var/log/pki-ca/debug ----- [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem id=selftests [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init id=selftests [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): ENTERING . . . [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): loading self test logger parameters [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException The self test plugin named selftests.container.logger.class contains a value com.netscape.cms.logging.RollingLogFile which is invalid. at com.netscape.cmscore.selftests.SelfTestSubsystem.init(SelfTestSubsystem.java:1422) at com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:866) at com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:795) at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:316) at com.netscape.certsrv.apps.CMS.init(CMS.java:153) at com.netscape.certsrv.apps.CMS.start(CMS.java:1530) at com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:85) at org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) at org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) at org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4425) at org.apache.catalina.core.StandardContext.start(StandardContext.java:4738) at org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) at org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) at org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) at org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) at org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) at org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) at org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) at org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) at org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) at org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) at org.apache.catalina.core.StandardService.start(StandardService.java:516) at org.apache.catalina.core.StandardServer.start(StandardServer.java:710) at org.apache.catalina.startup.Catalina.start(Catalina.java:593) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) [22/Mar/2015:06:45:10][main]: CMSEngine.shutdown() [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use default authz mgr: {2}. [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use default authz mgr: {2}. [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password store initialized before. [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password store initialized. [22/Mar/2015:06:55:10][CertStatusUpdateThread]: About to start updateCertStatus [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting updateCertStatus (entered lock) [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In updateCertStatus() [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In LdapBoundConnFactory::getConn() [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getInvalidCertificatesByNotBeforeDate filter (certStatus=INVALID) [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getInvalidCertificatesByNotBeforeDate: about to call findCertRecordsInList [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In LdapBoundConnFactory::getConn() [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In findCertRecordsInListRawJumpto with Jumpto 20150322065510Z [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter attrs startFrom sortKey pageSize filter: (certStatus=INVALID) attrs: [objectclass, certRecordId, x509cert] pageSize -200 startFrom 20150322065510Z [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In getInvalidCertsByNotBeforeDate finally. [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: index may be empty [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In LdapBoundConnFactory::getConn() [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getValidCertsByNotAfterDate filter (certStatus=VALID) [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In LdapBoundConnFactory::getConn() [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In findCertRecordsInListRawJumpto with Jumpto 20150322065510Z [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter attrs startFrom sortKey pageSize filter: (certStatus=VALID) attrs: [objectclass, certRecordId, x509cert] pageSize -200 startFrom 20150322065510Z [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: 69 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transidValidCertificates: list size: 69 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitValidCertificates: ltSize 1 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction getting index 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not qualify,notAfter Sat Jul 09 05:12:31 UTC 2016 date Sun Mar 22 06:55:10 UTC 2015 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList EXPIRED [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In LdapBoundConnFactory::getConn() [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getRevokedCertificatesByNotAfterDate filter (certStatus=REVOKED) [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getRevokedCertificatesByNotAfterDate: about to call findCertRecordsInList [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In LdapBoundConnFactory::getConn() [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected true [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In findCertRecordsInListRawJumpto with Jumpto 20150322065510Z [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter attrs startFrom sortKey pageSize filter: (certStatus=REVOKED) attrs: [objectclass, certRevokedOn, certRecordId, certRevoInfo, notAfter, x509cert] pageSize -200 startFrom 20150322065510Z [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: 5 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitRevokedExpiredCertificates: list size: 5 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitRevokedExpiredCertificates: ltSize 1 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction getting index 0 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitRevokedExpired: curRec: 0 CertRecord: 268369925 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not qualify,notAfter Wed Jul 20 06:25:57 UTC 2016 date Sun Mar 22 06:55:10 UTC 2015 [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList REVOKED_EXPIRED [22/Mar/2015:06:55:10][CertStatusUpdateThread]: updateCertStatus done [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting cert checkRanges [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely started. Returning .. [22/Mar/2015:06:55:10][CertStatusUpdateThread]: cert checkRanges done [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting request checkRanges [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely started. Returning .. [22/Mar/2015:06:55:10][CertStatusUpdateThread]: request checkRanges done -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Sun Mar 22 15:24:49 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Sun, 22 Mar 2015 16:24:49 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550D9BC2.5010604@redhat.com> References: <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> Message-ID: Thanks Rob. Knowing that /etc/nsswitch.conf is created wrongly is a step forward, although we don't know why that happens yet. I'm not very keen on fixing it post-installation (except if this is just to learn more about the issue), even if this seems to solve problems. I'm not going to deploy freeIPA for real before I can at least run successfully a plain installation. It seems SELinux can be ruled out as well. I switched to permissive mode and tried again, no difference. And so far I haven't been able to find anything useful in the logs. What strikes me is that these are really a plain and up to date FC21 machines, and my deployment was as from the book. The last of the settings you'd expect issues from. Can anyone (user or developer) confirm successful deployment of both server and client on up-to-date (updated this week) FC21 systems? I know it's maybe a bit far-fetched, but could any of the latest FC updates have created the issue? Roberto On 21 March 2015 at 17:26, Rob Crittenden wrote: > Roberto Cornacchia wrote: > > Hi Rob, > > > > Yes, sssd is running and this is sssd.conf: > > > > [domain/hq.example.com ] > > debug_level=9 > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = hq.example.com > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = meson.hq.example.com > > chpass_provider = ipa > > ipa_server = _srv_, ipa.hq.example.com > > ldap_tls_cacert = /etc/ipa/ca.crt > > [sssd] > > services = nss, sudo, pam, ssh > > config_file_version = 2 > > > > domains = hq.example.com > > [nss] > > homedir_substring = /home > > debug_level=9 > > > > [pam] > > > > [sudo] > > > > [autofs] > > > > [ssh] > > > > [pac] > > > > [ifp] > > Ok, that's good. Maybe authconfig didn't do the right thing. I'd add sss > to these values in /etc/nsswitch.conf, grepp'd from mine: > > passwd: files sss > shadow: files sss > group: files sss > services: files sss > netgroup: files sss > automount: files sss > sudoers: sss > > You've got quite a mix of odd things happening during install. It seems > like DNS and firewall can be ruled out given that lots of other > operations are working fine, and you've confirmed that NTP works > pre-install. > > I guess working on a cleanish system, the things I'd look for on both > client and server are the system logs to see if any errors are being > thrown to syslog or service-specific logs. > > And I'd check for SELinux errors on the client if you're in enforcing mode. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From coy.hile at coyhile.com Sun Mar 22 15:56:51 2015 From: coy.hile at coyhile.com (Coy Hile) Date: Sun, 22 Mar 2015 11:56:51 -0400 Subject: [Freeipa-users] FreeIPA interoperability with an existing kerberos realm? Message-ID: <2BF95FA9-83F2-43BD-9879-393C9685E93B@coyhile.com> Hi all, I?ve got an existing (Heimdal) kerberos realm that I am potentially interested in replacing with FreeIPA. I know that recent MIT krb5 can read a Heimdal dump. Is there a supported (or even unsupported but it works is fine) way to pre-seed the kerb realm before running the IPA setup in the quick start? I?ve got a handful of services (most notably OpenAFS and a trust to an existing Windows Domain) that I should prefer not to have to rekey if I can avoid it. If I can simply load the existing dump, then let FreeIPA create what it needs, that should make my life easier. Thanks, -- Coy Hile coy.hile at coyhile.com From james.mcevoy at hp.com Sun Mar 22 16:44:42 2015 From: james.mcevoy at hp.com (McEvoy, James) Date: Sun, 22 Mar 2015 16:44:42 +0000 Subject: [Freeipa-users] Password entry through Trust not correct In-Reply-To: <550DAD6E.5060900@redhat.com> References: <6301806E96421841896741228C6B1A2764C5B76C@G4W3216.americas.hpqcorp.net>, <550DAD6E.5060900@redhat.com> Message-ID: <6301806E96421841896741228C6B1A2764C5D977@G4W3216.americas.hpqcorp.net> From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] Sent: Saturday, March 21, 2015 10:42 AM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] Password entry through Trust not correct On 03/20/2015 08:56 PM, McEvoy, James wrote: When I look at the password entries for my rfc2307 account in Active directory I get three different answers. The only correct one is on a server where I used sssd to join AD directly ( the last one ). Do I need to configure rfc2307? When I configured the server to join AD directly I use the option --enablerfc2307bis when I run authconfig. from a freeipa client: $ getent passwd jemcevoy at ENAS.NET jemcevoy at enas.net:*:10001:10004::/home/enas.net/jemcevoy: from the ipa server: [root at ipa ~]# getent passwd jemcevoy at ENAS.NET jemcevoy at enas.net:*:10001:10004:James McEvoy:/home/enas.net/jemcevoy:/bin/bash from a server that joined AD directly using sssd: $ getent passwd jemcevoy at ENAS.NET jemcevoy:*:10001:10004:James McEvoy:/home/jemcevoy:/bin/bash Hi, Let us step back. What versions of the server and of the client and on what platforms? When you set trust, how did you set it? It might be that IPA server did not detect that you have Posix extensions in AD. There is some heuristics involved so probably you should use explicit parameters to tell IPA whether you have posix in AD or not. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. Hi Dmitri, My IPA Server is running Fedora 21 directly on an HP DL360-G7 server. The Version of the freeipa is: freeipa-server-4.1.3-2.fc21.x86_64 The freeipa server has a trust with a Windows 2008R2 Active Directory domain named ENAS.Net. The client is in an LXC container with both the hosting server and the LXC guest running Fedora 20. The client is running freeipa-client-3.3.5-1.fc20.x86_64. This is at the top of the file /var/log/ipaclient-install.log in the client: 2015-03-19T19:20:38Z DEBUG /usr/sbin/ipa-client-install was invoked with options : {'domain': 'lnx.lab', 'force': False, 'krb5_offline_passwords': True, 'primary ': False, 'realm_name': 'LNX.LAB', 'force_ntpd': False, 'create_sshfp': True, 'c onf_sshd': True, 'conf_ntp': False, 'on_master': False, 'ntp_server': None, 'ca_ cert_file': None, 'principal': 'admin at LNX.LAB', 'keytab': None, 'hostname': 'ctn 017-135.lnx.lab', 'no_ac': False, 'unattended': None, 'sssd': True, 'trust_sshfp ': False, 'dns_updates': True, 'mkhomedir': True, 'conf_ssh': True, 'force_join' : False, 'server': ['ipa.lnx.lab'], 'prompt_password': False, 'permit': False, ' debug': False, 'preserve_sssd': False, 'uninstall': False} The client is getting the correct POSIX uid/gid from Active Directory, it is the home directory which looks samba style to me and the shell is completely missing. Monday morning (PDT) I will kickstart another server with Fedora 21 to see the results when it joins freeipa and uses the trust. I will try both directly and from an LXC guest to see if the correct POSIX attributes get passed through from the Active Directory Identity Management for Unix plugin. -- jim From dpal at redhat.com Sun Mar 22 19:21:14 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 22 Mar 2015 15:21:14 -0400 Subject: [Freeipa-users] Automatic client enrollment In-Reply-To: References: <550DAF79.8060503@redhat.com> Message-ID: <550F162A.1020007@redhat.com> On 03/21/2015 08:57 PM, Prasun Gera wrote: > Yes, this approach would work, and it would be a good enhancement. It > would make migration from NIS easier with very little impact to users. > Are you saying that something like this can be implemented right now? > Or do you mean that this is how it could be done in future ? In future. I suggested opnenning and RFE. > How does a host submit a request to the host admin? Is there a host > admin daemon that listens for these requests ? No. And I am not sure it is needed. To be fair what you are looking for can be accomplished using Foreman or Satellite 6 right now. This is why the RFE would probably be a low priority. Integrating with Foreman/Satellite a person provisioning a system (or systems) will just click a button to provision a system and it will be enrolled automatically. The RFE will be useful when you try to use kickstart in a manual fashion. In this case you will use a special admin account as I suggested with password baked into the kickstart (not ideal). But IP range checking will reduce the risk of adding a rogue system if the kiskstart is stolen. But IMO it is better to go the Foreman path right away. http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm > > > > On Sat, Mar 21, 2015 at 1:50 PM, Dmitri Pal > wrote: > > On 03/21/2015 05:53 AM, Prasun Gera wrote: >> Is it possible to completely automate the client enrollment >> process similar to securenets in NIS? I'm trying to migrate NIS >> to IDM, and hoping that it runs largely in auto-pilot mode. The >> kickstarter method suggests adding host entries with a one time >> kerberos password to launch unattended client installs. That, >> however, needs the admin's involvement every time a new host has >> to be added. Securenets works pretty well in our case since we >> can authenticate based on the IP address. User addition is still >> manual, but that's all right since that is infrequent. Is it >> possible to do something similar using IP masks or fqdn regex in >> ipa ? >> >> > No but if you trust your network you can create a host admin that > would have the host add privilege and host enroll privilege and > nothing else and use this admin. > > IMO it would be a nice enhancement to have a way to restrict such > enrollments to specific subnets. The logic on the server would be > something like this: > > Enrollment request comes in > If host entry there? > Yes - follow the current logic > Check user privileges > > <-new > Enroll > > Would you mind filing an RFE if this approach would work for you? > > -- > 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 dpal at redhat.com Sun Mar 22 19:23:09 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 22 Mar 2015 15:23:09 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C5ACD.6070904@redhat.com> <550C69F6.7040508@redhat.com> <550C73D7.7060007@redhat.com> <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> Message-ID: <550F169D.6090403@redhat.com> On 03/22/2015 11:24 AM, Roberto Cornacchia wrote: > Thanks Rob. > > Knowing that /etc/nsswitch.conf is created wrongly is a step forward, > although we don't know why that happens yet. > I'm not very keen on fixing it post-installation (except if this is > just to learn more about the issue), even if this seems to solve > problems. I'm not going to deploy freeIPA for real before I can at > least run successfully a plain installation. > > It seems SELinux can be ruled out as well. > I switched to permissive mode and tried again, no difference. > > And so far I haven't been able to find anything useful in the logs. > > What strikes me is that these are really a plain and up to date FC21 > machines, and my deployment was as from the book. The last of the > settings you'd expect issues from. > > Can anyone (user or developer) confirm successful deployment of both > server and client on up-to-date (updated this week) FC21 systems? I > know it's maybe a bit far-fetched, but could any of the latest FC > updates have created the issue? May be. To config nsswitch we call authconfig so may be there is something weird with it, can you check? > > Roberto > > > On 21 March 2015 at 17:26, Rob Crittenden > wrote: > > Roberto Cornacchia wrote: > > Hi Rob, > > > > Yes, sssd is running and this is sssd.conf: > > > > [domain/hq.example.com > ] > > debug_level=9 > > cache_credentials = True > > krb5_store_password_if_offline = True > > ipa_domain = hq.example.com > > > id_provider = ipa > > auth_provider = ipa > > access_provider = ipa > > ipa_hostname = meson.hq.example.com > > chpass_provider = ipa > > ipa_server = _srv_, ipa.hq.example.com > > ldap_tls_cacert = /etc/ipa/ca.crt > > [sssd] > > services = nss, sudo, pam, ssh > > config_file_version = 2 > > > > domains = hq.example.com > > [nss] > > homedir_substring = /home > > debug_level=9 > > > > [pam] > > > > [sudo] > > > > [autofs] > > > > [ssh] > > > > [pac] > > > > [ifp] > > Ok, that's good. Maybe authconfig didn't do the right thing. I'd > add sss > to these values in /etc/nsswitch.conf, grepp'd from mine: > > passwd: files sss > shadow: files sss > group: files sss > services: files sss > netgroup: files sss > automount: files sss > sudoers: sss > > You've got quite a mix of odd things happening during install. It > seems > like DNS and firewall can be ruled out given that lots of other > operations are working fine, and you've confirmed that NTP works > pre-install. > > I guess working on a cleanish system, the things I'd look for on both > client and server are the system logs to see if any errors are being > thrown to syslog or service-specific logs. > > And I'd check for SELinux errors on the client if you're in > enforcing mode. > > rob > > > > -- 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 Mar 22 19:26:57 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 22 Mar 2015 15:26:57 -0400 Subject: [Freeipa-users] multiple ssh keys? In-Reply-To: <550E4EBC.5020104@gmail.com> References: <550E4EBC.5020104@gmail.com> Message-ID: <550F1781.30309@redhat.com> On 03/22/2015 01:10 AM, Janelle wrote: > Hello, > > I was wondering, I don't seem to be able to put multiple SSH keys into > IPA? Am I missing something? it seems to replace the one that was > there instead of adding an additional. > > ~J > If you need different SSH keys for different systems you need to use views and put alternative SSH keys there. http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#ID_Views It is available in IPA 4.1.x -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Sun Mar 22 19:31:17 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 22 Mar 2015 15:31:17 -0400 Subject: [Freeipa-users] FreeIPA interoperability with an existing kerberos realm? In-Reply-To: <2BF95FA9-83F2-43BD-9879-393C9685E93B@coyhile.com> References: <2BF95FA9-83F2-43BD-9879-393C9685E93B@coyhile.com> Message-ID: <550F1885.3090105@redhat.com> On 03/22/2015 11:56 AM, Coy Hile wrote: > Hi all, > > I?ve got an existing (Heimdal) kerberos realm that I am potentially interested in replacing with FreeIPA. I know that recent MIT krb5 can read a Heimdal dump. Is there a supported (or even unsupported but it works is fine) way to pre-seed the kerb realm before running the IPA setup in the quick start? I?ve got a handful of services (most notably OpenAFS and a trust to an existing Windows Domain) that I should prefer not to have to rekey if I can avoid it. If I can simply load the existing dump, then let FreeIPA create what it needs, that should make my life easier. > > Thanks, > > -- > Coy Hile > coy.hile at coyhile.com > > I think there have been some attempts to move from MIT Kerberos to IPA with manual migration. Please search archives. I remember Simo Sorce was providing some guidance. Last time it was more than a year ago AFAIR. I do not think the loop was ever closed to know whether the migration was actually conducted or complete. I am not aware of any Heimdal migration like this. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jhrozek at redhat.com Sun Mar 22 19:44:23 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 22 Mar 2015 20:44:23 +0100 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <550CBC0E.30901@redhat.com> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> <550C8FFC.4060102@redhat.com> <5fe92a2cd252072f537a863d564dc1e8.squirrel@webmail.nathanpeters.com> <550CB099.5090105@redhat.com> <550CBC0E.30901@redhat.com> Message-ID: <20150322194423.GB9374@Jakubs-MacBook-Pro.local> On Fri, Mar 20, 2015 at 08:32:14PM -0400, Dmitri Pal wrote: > On 03/20/2015 08:18 PM, nathan at nathanpeters.com wrote: > >>>Actually this was the problem : > >>> > >>>I had added the following line to the [sssd] section of sssd.conf : > >>>[sssd] > >>>default_domain_suffix = addomain.net > >>> > >>>The reason I had added this is because our business asked if our active > >>>directory trusted users can be allowed to login without entering their > >>>fqdn. Setting the default_domain_suffix allows them to just login as > >>>'aduser' instead of 'aduser at addomain.net'. > >>> > >>>However, this apparently breaks host key checking. Turning debugging on > >>>the sssd up to 9 revealed that it was appending the > >>>default_domain_suffix > >>>line to all hostnames (fully qualified and not) before asking FreeIPA > >>>for > >>>their host keys: > >>> > >>>(Fri Mar 20 23:19:55 2015) [sssd[ssh]] [ssh_host_pubkeys_search_next] > >>>(0x0400): Requesting SSH host public keys for > >>>[ipaclient1-sandbox-atdev-van.ipadomain.net at addomain.net] > >>>(Fri Mar 20 23:19:55 2015) [sssd[ssh]] [sysdb_search_ssh_hosts] > >>>(0x0400): > >>>No such host > >>> > >>>So 2 more questions: > >>>1. Is this a bug? > >>> > >>>2. If it is not a bug or is expected behavior, is there a way to both > >>>A) Have ad users able to login as 'aduser' instead of > >>>'aduser at addomain.net' > >>>AND > >>>B) Still get host key checking working properly? > >>> > >>> > >>Probably a bug. > >> > >>-- > >>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 > >> > >Hmm, if it is a bug, it still exists in the newest sssd (1.12.3-2.el7) > >because I just tested it on the newest CentOS 7 client and without > >default_domain_suffix set I get host key checking, but with it set, it is > >failing just like it did on CentOS 6 with the older sssd. > > > >Is there a good place to report that bug so it can hopefully get fixed? > > > > > Let us wait till Monday. > I CCed Jakub. He will be able to confirm whether this is a bug or not. > If it is in fact a bug here is where to file it: > https://fedorahosted.org/sssd/ you need a Fedora login to do it. Thanks for CC-ing me Dmitri, I only monitor freeipa-users based on subjects and didn't realize this thread was about SSSD. I didn't reproduce the problem myself yet, but I checked the sources and I think it's a bug, much like one in the autofs responder we've had some time ago. Please open a bug upstream or in RHBZ, we need to track this problem. Thanks! From jhrozek at redhat.com Sun Mar 22 19:56:52 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 22 Mar 2015 20:56:52 +0100 Subject: [Freeipa-users] Password entry through Trust not correct In-Reply-To: <6301806E96421841896741228C6B1A2764C5D977@G4W3216.americas.hpqcorp.net> References: <6301806E96421841896741228C6B1A2764C5B76C@G4W3216.americas.hpqcorp.net> <550DAD6E.5060900@redhat.com> <6301806E96421841896741228C6B1A2764C5D977@G4W3216.americas.hpqcorp.net> Message-ID: <20150322195652.GD9374@Jakubs-MacBook-Pro.local> On Sun, Mar 22, 2015 at 04:44:42PM +0000, McEvoy, James wrote: > > From: freeipa-users-bounces at redhat.com [freeipa-users-bounces at redhat.com] on behalf of Dmitri Pal [dpal at redhat.com] > Sent: Saturday, March 21, 2015 10:42 AM > To: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Password entry through Trust not correct > > On 03/20/2015 08:56 PM, McEvoy, James wrote: > When I look at the password entries for my rfc2307 account in Active directory I get three different answers. > The only correct one is on a server where I used sssd to join AD directly ( the last one ). Do I need to configure > rfc2307? When I configured the server to join AD directly I use the option --enablerfc2307bis when I run authconfig. > > from a freeipa client: > $ getent passwd jemcevoy at ENAS.NET > jemcevoy at enas.net:*:10001:10004::/home/enas.net/jemcevoy: > > from the ipa server: > [root at ipa ~]# getent passwd jemcevoy at ENAS.NET > jemcevoy at enas.net:*:10001:10004:James McEvoy:/home/enas.net/jemcevoy:/bin/bash > > from a server that joined AD directly using sssd: > $ getent passwd jemcevoy at ENAS.NET > jemcevoy:*:10001:10004:James McEvoy:/home/jemcevoy:/bin/bash > > > Hi, > > Let us step back. > What versions of the server and of the client and on what platforms? > > When you set trust, how did you set it? > It might be that IPA server did not detect that you have Posix extensions in AD. > There is some heuristics involved so probably you should use explicit parameters to tell IPA whether you have posix in AD or not. > > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > > > Hi Dmitri, > > My IPA Server is running Fedora 21 directly on an HP DL360-G7 server. > The Version of the freeipa is: freeipa-server-4.1.3-2.fc21.x86_64 > > The freeipa server has a trust with a Windows 2008R2 Active Directory > domain named ENAS.Net. > > The client is in an LXC container with both the hosting server and the > LXC guest running Fedora 20. > The client is running freeipa-client-3.3.5-1.fc20.x86_64. > > This is at the top of the file /var/log/ipaclient-install.log in the client: > > 2015-03-19T19:20:38Z DEBUG /usr/sbin/ipa-client-install was invoked with options > : {'domain': 'lnx.lab', 'force': False, 'krb5_offline_passwords': True, 'primary > ': False, 'realm_name': 'LNX.LAB', 'force_ntpd': False, 'create_sshfp': True, 'c > onf_sshd': True, 'conf_ntp': False, 'on_master': False, 'ntp_server': None, 'ca_ > cert_file': None, 'principal': 'admin at LNX.LAB', 'keytab': None, 'hostname': 'ctn > 017-135.lnx.lab', 'no_ac': False, 'unattended': None, 'sssd': True, 'trust_sshfp > ': False, 'dns_updates': True, 'mkhomedir': True, 'conf_ssh': True, 'force_join' > : False, 'server': ['ipa.lnx.lab'], 'prompt_password': False, 'permit': False, ' > debug': False, 'preserve_sssd': False, 'uninstall': False} > > > The client is getting the correct POSIX uid/gid from Active Directory, it is the > home directory which looks samba style to me and the shell is completely missing. > > Monday morning (PDT) I will kickstart another server with Fedora 21 to see the > results when it joins freeipa and uses the trust. I will try both directly and > from an LXC guest to see if the correct POSIX attributes get passed through from > the Active Directory Identity Management for Unix plugin. With FreeIPA server 3.x what you are seeing is actually expected. The ability to transfer additional POSIX attributes from the server to the client was only added in 4.x, sorry. In the meantime, I wonder if the various subdomain_homedir/override_homedir/override_shell etc attributes would be helpful on the clients? Finally, please note that the most important part are the UID and GID attributes so that you can access your files. From prasun.gera at gmail.com Sun Mar 22 20:02:51 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Sun, 22 Mar 2015 16:02:51 -0400 Subject: [Freeipa-users] Automatic client enrollment In-Reply-To: <550F162A.1020007@redhat.com> References: <550DAF79.8060503@redhat.com> <550F162A.1020007@redhat.com> Message-ID: Thanks for clarifying that. Satellite would be restricted to RHEL clients I think. Foreman would be a good solution, but could be an overkill for accomplishing just this. I'll have a look and decide. I'll open the RFE too. On Sun, Mar 22, 2015 at 3:21 PM, Dmitri Pal wrote: > On 03/21/2015 08:57 PM, Prasun Gera wrote: > > Yes, this approach would work, and it would be a good enhancement. It > would make migration from NIS easier with very little impact to users. Are > you saying that something like this can be implemented right now? Or do you > mean that this is how it could be done in future ? > > > In future. I suggested opnenning and RFE. > > How does a host submit a request to the host admin? Is there a host > admin daemon that listens for these requests ? > > > No. And I am not sure it is needed. > To be fair what you are looking for can be accomplished using Foreman or > Satellite 6 right now. > This is why the RFE would probably be a low priority. > > Integrating with Foreman/Satellite a person provisioning a system (or > systems) will just click a button to provision a system and it will be > enrolled automatically. > The RFE will be useful when you try to use kickstart in a manual fashion. > In this case you will use a special admin account as I suggested with > password baked into the kickstart (not ideal). But IP range checking will > reduce the risk of adding a rogue system if the kiskstart is stolen. > > But IMO it is better to go the Foreman path right away. > http://theforeman.org/manuals/1.5/index.html#4.3.11FreeIPARealm > > > > > > On Sat, Mar 21, 2015 at 1:50 PM, Dmitri Pal wrote: > >> On 03/21/2015 05:53 AM, Prasun Gera wrote: >> >> Is it possible to completely automate the client enrollment process >> similar to securenets in NIS? I'm trying to migrate NIS to IDM, and hoping >> that it runs largely in auto-pilot mode. The kickstarter method suggests >> adding host entries with a one time kerberos password to launch unattended >> client installs. That, however, needs the admin's involvement every time a >> new host has to be added. Securenets works pretty well in our case since we >> can authenticate based on the IP address. User addition is still manual, >> but that's all right since that is infrequent. Is it possible to do >> something similar using IP masks or fqdn regex in ipa ? >> >> >> No but if you trust your network you can create a host admin that would >> have the host add privilege and host enroll privilege and nothing else and >> use this admin. >> >> IMO it would be a nice enhancement to have a way to restrict such >> enrollments to specific subnets. The logic on the server would be something >> like this: >> >> Enrollment request comes in >> If host entry there? >> Yes - follow the current logic >> Check user privileges >> <-new >> Enroll >> >> Would you mind filing an RFE if this approach would work for you? >> >> -- >> 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 jhrozek at redhat.com Sun Mar 22 20:04:40 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Sun, 22 Mar 2015 21:04:40 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> Message-ID: <20150322200440.GE9374@Jakubs-MacBook-Pro.local> On Sun, Mar 22, 2015 at 04:24:49PM +0100, Roberto Cornacchia wrote: > Thanks Rob. > > Knowing that /etc/nsswitch.conf is created wrongly is a step forward, > although we don't know why that happens yet. > I'm not very keen on fixing it post-installation (except if this is just to > learn more about the issue), even if this seems to solve problems. I'm not > going to deploy freeIPA for real before I can at least run successfully a > plain installation. Hi, I find it a bit unexpected that the client system didn't have nsswitch.conf configured..I've never seen the client installation fail in this particular way. For debugging SSSD issues, we've created a new troubleshooting page upstream that should walk you through the config: https://fedorahosted.org/sssd/wiki/Troubleshooting maybe this article would also help: https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ But most improtantly, I wouldn't expect to see any issues as long as you use ipa-client-install. I guess re-enrolling the client would be the fastest way forward? From janellenicole80 at gmail.com Mon Mar 23 03:07:27 2015 From: janellenicole80 at gmail.com (Janelle) Date: Sun, 22 Mar 2015 20:07:27 -0700 Subject: [Freeipa-users] What am I missing? ipaca? Message-ID: <550F836F.7090201@gmail.com> Hello Starting to see a lot of these and wondering what I am dealign with? attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. ~J From mike at colovore.com Mon Mar 23 03:52:47 2015 From: mike at colovore.com (Michael Pawlak) Date: Sun, 22 Mar 2015 20:52:47 -0700 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: References: Message-ID: Does anybody have any thoughts on this? *Michael Pawlak* Web Systems Administrator | Colovore LLC E: mike at colovore.com C: 408.316.2154 On Sun, Mar 22, 2015 at 12:05 AM, Michael Pawlak wrote: > I am not able to setup a replica using the 'ipa-replica-prepare' command. > After some debugging this appears related to the certmonger/dogtag system > that is incorporated with FreeIPA. I am including the output below of any > relevant logs / commands. > > ----- ipa-replica-prepare ----- > > ipa-replica-prepare newipa.example.com --ca=/etc/ipa/ca.crt --password > 'somepassword' > Preparing replica for newipa.example.com from ipa.example.com > Creating SSL certificate for the Directory Server > Certificate operation cannot be completed: Unable to communicate with CMS > (Not Found) > > ----- ipa-getcert list ----- > > Number of certificates and requests being tracked: 8. > Request ID '20140811232518': > status: CA_UNREACHABLE > ca-error: Server at https://ipa.example.com/ipa/xml failed request, > will retry: 4301 (RPC failed at server. Certificate operation cannot be > completed: Unable to communicate with CMS (Not Found)). > 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 > subject: CN=ipa.example.com,O=EXAMPLE > expires: 2016-08-11 23:24:36 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 '20140811232742': > status: CA_UNREACHABLE > ca-error: Server at https://ipa.example.com/ipa/xml failed request, > will retry: 4301 (RPC failed at server. Certificate operation cannot be > completed: Unable to communicate with CMS (Not Found)). > stuck: no > key pair storage: > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS > Certificate DB',pinfile='/etc/dirsrv/slapd-COLOVORE/pwdfile.txt' > certificate: > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS > Certificate DB' > CA: IPA > issuer: CN=Certificate Authority,O=EXAMPLE > subject: CN=ipa.example.com,O=EXAMPLE > expires: 2016-08-11 23:24:34 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 '20140811232843': > status: CA_UNREACHABLE > ca-error: Server at https://ipa.example.com/ipa/xml failed request, > will retry: 4301 (RPC failed at server. Certificate operation cannot be > completed: Unable to communicate with CMS (Not Found)). > 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 > subject: CN=ipa.example.com,O=EXAMPLE > expires: 2016-08-11 23:24:37 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 > > ----- /etc/pki-ca/password.conf ----- > > internal=829325937546 > internaldb=somepassword > replicationdb=1270571739 > > ----- /var/log/pki-ca/debug ----- > > [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile > [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile > [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem id=selftests > [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init id=selftests > [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): ENTERING . . . > [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): loading self > test logger parameters > [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException > The self test plugin named selftests.container.logger.class contains a > value com.netscape.cms.logging.RollingLogFile which is invalid. > at > com.netscape.cmscore.selftests.SelfTestSubsystem.init(SelfTestSubsystem.java:1422) > at > com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:866) > at > com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:795) > at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:316) > at com.netscape.certsrv.apps.CMS.init(CMS.java:153) > at com.netscape.certsrv.apps.CMS.start(CMS.java:1530) > at > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:85) > at > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) > at > org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) > at > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4425) > at > org.apache.catalina.core.StandardContext.start(StandardContext.java:4738) > at > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) > at > org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) > at > org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) > at > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) > at > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) > at > org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) > at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) > at > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) > at > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) > at > org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) > at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) > at > org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) > at > org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) > at > org.apache.catalina.core.StandardService.start(StandardService.java:516) > at > org.apache.catalina.core.StandardServer.start(StandardServer.java:710) > at org.apache.catalina.startup.Catalina.start(Catalina.java:593) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > at > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:606) > at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) > at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) > [22/Mar/2015:06:45:10][main]: CMSEngine.shutdown() > [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization > for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use > default authz mgr: {2}. > [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization > for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use > default authz mgr: {2}. > [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password > store initialized before. > [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password > store initialized. > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: About to start > updateCertStatus > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting updateCertStatus > (entered lock) > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In updateCertStatus() > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > LdapBoundConnFactory::getConn() > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > getInvalidCertificatesByNotBeforeDate filter (certStatus=INVALID) > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > getInvalidCertificatesByNotBeforeDate: about to call findCertRecordsInList > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > LdapBoundConnFactory::getConn() > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > attrs startFrom sortKey pageSize filter: (certStatus=INVALID) attrs: > [objectclass, certRecordId, x509cert] pageSize -200 startFrom > 20150322065510Z > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > getInvalidCertsByNotBeforeDate finally. > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: > 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: index may be empty > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > LdapBoundConnFactory::getConn() > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > getValidCertsByNotAfterDate filter (certStatus=VALID) > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > LdapBoundConnFactory::getConn() > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > attrs startFrom sortKey pageSize filter: (certStatus=VALID) attrs: > [objectclass, certRecordId, x509cert] pageSize -200 startFrom > 20150322065510Z > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: > 69 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transidValidCertificates: > list size: 69 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitValidCertificates: > ltSize 1 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction getting > index 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not > qualify,notAfter Sat Jul 09 05:12:31 UTC 2016 date Sun Mar 22 06:55:10 UTC > 2015 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList EXPIRED > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > LdapBoundConnFactory::getConn() > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > getRevokedCertificatesByNotAfterDate filter (certStatus=REVOKED) > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > getRevokedCertificatesByNotAfterDate: about to call findCertRecordsInList > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > LdapBoundConnFactory::getConn() > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected > true > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > attrs startFrom sortKey pageSize filter: (certStatus=REVOKED) attrs: > [objectclass, certRevokedOn, certRecordId, certRevoInfo, notAfter, > x509cert] pageSize -200 startFrom 20150322065510Z > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: > 5 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > transitRevokedExpiredCertificates: list size: 5 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > transitRevokedExpiredCertificates: ltSize 1 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction getting > index 0 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitRevokedExpired: > curRec: 0 CertRecord: 268369925 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not > qualify,notAfter Wed Jul 20 06:25:57 UTC 2016 date Sun Mar 22 06:55:10 UTC > 2015 > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList > REVOKED_EXPIRED > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: updateCertStatus done > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting cert checkRanges > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely > started. Returning .. > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: cert checkRanges done > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting request > checkRanges > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely > started. Returning .. > [22/Mar/2015:06:55:10][CertStatusUpdateThread]: request checkRanges done > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Mon Mar 23 06:35:05 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 23 Mar 2015 12:05:05 +0530 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working Message-ID: Hello Team, We are doing POC to use IPA server in our Env. When we try to add individual host and user in Sudo Rule it work fine whereas we need use HostGroup and Usergroup it is not working. We have been restricted to use NIS due to others issue with NIS. Please suggest a way to fix this. *Best Regards,__________________________________________* *Yogesh Sharma* -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Mar 23 06:41:15 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Mar 2015 07:41:15 +0100 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: References: Message-ID: <20150323064115.GZ8409@hendrix.redhat.com> On Mon, Mar 23, 2015 at 12:05:05PM +0530, Yogesh Sharma wrote: > Hello Team, > > We are doing POC to use IPA server in our Env. When we try to add > individual host and user in Sudo Rule it work fine whereas we need use > HostGroup and Usergroup it is not working. > > We have been restricted to use NIS due to others issue with NIS. Please > suggest a way to fix this. The first thing I'd look at is whether nisdomainname is correct. The next thing would be whether 'getent netgroup $hostgroup' reports the host as a member of that hostgroup. From jhrozek at redhat.com Mon Mar 23 07:51:31 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Mar 2015 08:51:31 +0100 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: References: <20150323064115.GZ8409@hendrix.redhat.com> Message-ID: <20150323075131.GA4110@hendrix.arn.redhat.com> On Mon, Mar 23, 2015 at 12:29:03PM +0530, Yogesh Sharma wrote: > Thanks Jakub for the reply. Please find the details: Please keep the replies on the list, if possible. Other users might run into the same problem and then the archives become really useful. > > It shows nisdomain but not netgroup: > > [root at cipa ~]# nisdomainname > $NISDOMAINNAME_VALUE > [root at cipa ~]# getent netgroup cipa-servers > [root at cipa ~]# > > > However , From IPA Server, I am able to query host under netgroup Can you query the netgroup on the IPA server using getent netgroup? Can you query users on the IPA client? (getent passwd admin) From bentech4you at gmail.com Mon Mar 23 08:03:51 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Mon, 23 Mar 2015 11:03:51 +0300 Subject: [Freeipa-users] FreeIPA 3.3 AD<-> Solaris is working but solaris local users cannot able to login Message-ID: HI List finally after soo much struggling now i can able to login solaris box as AD user. but auto home directory creation still have issue. for that i need to compile some modules. The issue i am facing is i cannot able to login to solaris box after editing pam.conf file.here is the conf file bash-3.2# cat /etc/pam.conf # #ident "@(#)pam.conf 1.32 11/04/08 SMI" # # login auth requisite pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth sufficient pam_ldap.so.1 debug login auth sufficient pam_krb5.so.1 login auth required pam_unix_cred.so.1 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 sufficient pam_rhosts_auth.so.1 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 sufficient pam_rhosts_auth.so.1 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 other auth required pam_dhkeys.so.1 other auth sufficient pam_krb5.so.1 other auth sufficient pam_ldap.so.1 other auth required pam_unix_cred.so.1 other auth required pam_unix_auth.so.1 # # 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 other account required pam_unix_account.so.1 other account sufficient pam_krb5.so.1 other account sufficient pam_ldap.so.1 # # 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 # Password construction requirements apply to all users. # Remove force_check to have the traditional authorized administrator # bypass of construction requirements. other password requisite pam_authtok_check.so.1 force_check other password required pam_authtok_store.so.1 # # Support for Kerberos V5 authentication and example configurations can # be found in the pam_krb5(5) man page under the "EXAMPLES" section. # please anyone help me to fix this issue. Thanks & Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Mon Mar 23 08:53:52 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 23 Mar 2015 14:23:52 +0530 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: <20150323075131.GA4110@hendrix.arn.redhat.com> References: <20150323064115.GZ8409@hendrix.redhat.com> <20150323075131.GA4110@hendrix.arn.redhat.com> Message-ID: Sure Jakub. ++FreeIPA-Users "getent netgroup" not working on IPA Server [root at mipa ~]# getent netgroup stg.initd.com [root at mipa ~]# [root at mipa ~]# ipa hostgroup-show cipa-servers Host-group: cipa-servers Description: cipa Member hosts: cipa.stg.initd.com Member of netgroups: stg.initd.com [root at mipa ~]# ipa netgroup-show stg.initd.com Netgroup name: stg.initd.com Description: ss NIS domain name: stg.initd.com Member Group: admins, ipausers, masteruser, trust admins, webuser Member Hostgroup: sipa-servers, cipa-servers However, I re-register the IPA Client and I am able to query netgroup, Though it does not shows cipa.stg.initd.com whereas IPA Server query "ipa netgroup-show stg.initd.com" has it in list. [root at cipa ~]# getent passwd admin admin:*:1170400000:1170400000:Administrator:/home/admin:/bin/bash [root at cipa ~]# getent netgroup stg.initd.com stg.initd.com (sipa.stg.initd.com,-,stg.initd.com) [root at cipa ~]# *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Mon, Mar 23, 2015 at 1:21 PM, Jakub Hrozek wrote: > On Mon, Mar 23, 2015 at 12:29:03PM +0530, Yogesh Sharma wrote: > > Thanks Jakub for the reply. Please find the details: > > Please keep the replies on the list, if possible. Other users might run > into the same problem and then the archives become really useful. > > > > > It shows nisdomain but not netgroup: > > > > [root at cipa ~]# nisdomainname > > $NISDOMAINNAME_VALUE > > [root at cipa ~]# getent netgroup cipa-servers > > [root at cipa ~]# > > > > > > However , From IPA Server, I am able to query host under netgroup > > Can you query the netgroup on the IPA server using getent netgroup? > > Can you query users on the IPA client? (getent passwd admin) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Mon Mar 23 09:07:31 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Mon, 23 Mar 2015 10:07:31 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <20150322200440.GE9374@Jakubs-MacBook-Pro.local> References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> Message-ID: Dmitri, Rob, Jakub, I found at least one of the major problems: chronyd. This is what I get when I use ipa-client-install on a plain FC21 machine, *without* using --force-ntpd WARNING: ntpd time&date synchronization service will not be configured as conflicting service (chronyd) is enabled Use --force-ntpd option to disable it and force configuration of ntpd Good, then I abort and run it again with --force-ntpd: Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it would take care of stopping and disabling chronyd. But it doesn't. That's why I get the error above. If I first stop chronyd manually and run the installation again, then it does synchronise with NTP. This was apparently the cause of "id admin" not working (kerberos failing without proper NTP sync?) Now the basic functionalities are all OK. Also, chronyd is disabled and ntpd is enabled after installation - good. My nsswitch.conf now looks like this: passwd: files sss shadow: files sss group: files sss hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname bootparams: nisplus [NOTFOUND=return] files ethers: files netmasks: files networks: files protocols: files rpc: files services: files sss netgroup: files sss publickey: nisplus automount: files sss aliases: files nisplus sudoers: files sss I am left with 2 issues: 1) Is the above expected? Do I have to stop chronyd manually? Or is it a bug? 2) DNS update still does not work The latest installation log: $ systemctl stop chronyd $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd Discovery was successful! Hostname: meson.hq.example.com Realm: HQ.EXAMPLE.COM DNS Domain: hq.example.com IPA Server: ipa.hq.example.com BaseDN: dc=hq,dc=example,dc=com Continue to configure the system with these values? [no]: yes Synchronizing time with KDC... User authorized to enroll computers: User authorized to enroll computers: admin Password for admin at HQ.EXAMPLE.COM: Successfully retrieved CA cert Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM Valid From: Mon Mar 16 18:44:35 2015 UTC Valid Until: Fri Mar 16 18:44:35 2035 UTC Enrolled in IPA realm HQ.EXAMPLE.COM 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 HQ.EXAMPLE.COM trying https://ipa.hq.example.com/ipa/json Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' Forwarding 'ca_is_enabled' to json server 'https://ipa.hq.example.com /ipa/json' Systemwide CA database updated. Added CA certificates to the default NSS database. Hostname (meson.hq.example.com) not found in DNS *Failed to update DNS records.* Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json' *Could not update DNS SSHFP records.* SSSD enabled Configured /etc/openldap/ldap.conf NTP enabled Configured /etc/ssh/ssh_config Configured /etc/ssh/sshd_config Configuring hq.example.com as NIS domain. Client configuration complete. $ id admin uid=1172000000(admin) gid=1172000000(admins) groups=1172000000(admins) On 22 March 2015 at 21:04, Jakub Hrozek wrote: > On Sun, Mar 22, 2015 at 04:24:49PM +0100, Roberto Cornacchia wrote: > > Thanks Rob. > > > > Knowing that /etc/nsswitch.conf is created wrongly is a step forward, > > although we don't know why that happens yet. > > I'm not very keen on fixing it post-installation (except if this is just > to > > learn more about the issue), even if this seems to solve problems. I'm > not > > going to deploy freeIPA for real before I can at least run successfully a > > plain installation. > > Hi, > > I find it a bit unexpected that the client system didn't have > nsswitch.conf configured..I've never seen the client installation fail > in this particular way. > > For debugging SSSD issues, we've created a new troubleshooting page > upstream that should walk you through the config: > https://fedorahosted.org/sssd/wiki/Troubleshooting > maybe this article would also help: > https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ > > But most improtantly, I wouldn't expect to see any issues as long as > you use ipa-client-install. I guess re-enrolling the client would be the > fastest way forward? > > -- > 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 prashant at apigee.com Mon Mar 23 09:19:15 2015 From: prashant at apigee.com (Prashant Bapat) Date: Mon, 23 Mar 2015 14:49:15 +0530 Subject: [Freeipa-users] Adding a custom attribute to user object Message-ID: Hi, I'm trying to add a custom attribute to user object. Below is the ldif i'm using. dn: cn=schema changetype: modify add: attributeTypes attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME 'ipaSshSigTimestamp' DESC 'SSH public key signature and timestamp' EQUALITY octetStringMatch SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM FREEIPA EXTENTION' ) - add: objectclasses objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME 'ApigeeUserAttr' SUP top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY ipaSshSigTimestamp ) This gets added successfully using the ldapmodify command as directory manager. But both the UI and the ipa config-mod commands refuse to add the new attribute to ipaUserObjectClasses with error objectclass not found. What I'm I doing wrong ? Thanks. --Prashant -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Mon Mar 23 09:21:45 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Mon, 23 Mar 2015 10:21:45 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> Message-ID: About the DNS update, this is what the debug log has to say: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *Reply from SOA query:* ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4923 ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 ;; QUESTION SECTION: ;1835417091.sig-ipa.hq.example.com. ANY TKEY response to SOA query was unsuccessful Notice that is is *different* from what I got before the chronyd change. Before, there was not even a reply: Found zone name: hq.example.com The master is: ipa.hq.example.com start_gssrequest Found realm from ticket: HQ.EXAMPLE.COM send_gssrequest *; Communication with 192.168.0.72#53 failed: operation canceled* *could not reach any name server* On 23 March 2015 at 10:07, Roberto Cornacchia wrote: > Dmitri, Rob, Jakub, > > I found at least one of the major problems: chronyd. > > This is what I get when I use ipa-client-install on a plain FC21 machine, > *without* using --force-ntpd > > WARNING: ntpd time&date synchronization service will not be configured as > conflicting service (chronyd) is enabled > Use --force-ntpd option to disable it and force configuration of ntpd > > > Good, then I abort and run it again with --force-ntpd: > > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened. > > > Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it > would take care of stopping and disabling chronyd. But it doesn't. That's > why I get the error above. > > If I first stop chronyd manually and run the installation again, then it > does synchronise with NTP. > This was apparently the cause of "id admin" not working (kerberos failing > without proper NTP sync?) > Now the basic functionalities are all OK. > Also, chronyd is disabled and ntpd is enabled after installation - good. > > My nsswitch.conf now looks like this: > > passwd: files sss > shadow: files sss > group: files sss > hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname > bootparams: nisplus [NOTFOUND=return] files > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > services: files sss > netgroup: files sss > publickey: nisplus > automount: files sss > aliases: files nisplus > sudoers: files sss > > > > I am left with 2 issues: > > 1) Is the above expected? Do I have to stop chronyd manually? Or is it a > bug? > 2) DNS update still does not work > > > The latest installation log: > > > $ systemctl stop chronyd > $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd > Discovery was successful! > Hostname: meson.hq.example.com > Realm: HQ.EXAMPLE.COM > DNS Domain: hq.example.com > IPA Server: ipa.hq.example.com > BaseDN: dc=hq,dc=example,dc=com > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > User authorized to enroll computers: User authorized to enroll computers: > admin > Password for admin at HQ.EXAMPLE.COM: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Valid From: Mon Mar 16 18:44:35 2015 UTC > Valid Until: Fri Mar 16 18:44:35 2035 UTC > > Enrolled in IPA realm HQ.EXAMPLE.COM > 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 HQ.EXAMPLE.COM > trying https://ipa.hq.example.com/ipa/json > Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' > Forwarding 'ca_is_enabled' to json server 'https://ipa.hq.example.com > /ipa/json' > Systemwide CA database updated. > Added CA certificates to the default NSS database. > Hostname (meson.hq.example.com) not found in DNS > *Failed to update DNS records.* > Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json' > *Could not update DNS SSHFP records.* > SSSD enabled > Configured /etc/openldap/ldap.conf > NTP enabled > Configured /etc/ssh/ssh_config > Configured /etc/ssh/sshd_config > Configuring hq.example.com as NIS domain. > Client configuration complete. > > $ id admin > uid=1172000000(admin) gid=1172000000(admins) groups=1172000000(admins) > > > > > On 22 March 2015 at 21:04, Jakub Hrozek wrote: > >> On Sun, Mar 22, 2015 at 04:24:49PM +0100, Roberto Cornacchia wrote: >> > Thanks Rob. >> > >> > Knowing that /etc/nsswitch.conf is created wrongly is a step forward, >> > although we don't know why that happens yet. >> > I'm not very keen on fixing it post-installation (except if this is >> just to >> > learn more about the issue), even if this seems to solve problems. I'm >> not >> > going to deploy freeIPA for real before I can at least run successfully >> a >> > plain installation. >> >> Hi, >> >> I find it a bit unexpected that the client system didn't have >> nsswitch.conf configured..I've never seen the client installation fail >> in this particular way. >> >> For debugging SSSD issues, we've created a new troubleshooting page >> upstream that should walk you through the config: >> https://fedorahosted.org/sssd/wiki/Troubleshooting >> maybe this article would also help: >> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ >> >> But most improtantly, I wouldn't expect to see any issues as long as >> you use ipa-client-install. I guess re-enrolling the client would be the >> fastest way forward? >> >> -- >> 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 jhrozek at redhat.com Mon Mar 23 09:29:12 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Mar 2015 10:29:12 +0100 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: References: <20150323064115.GZ8409@hendrix.redhat.com> <20150323075131.GA4110@hendrix.arn.redhat.com> Message-ID: <20150323092912.GH4110@hendrix.arn.redhat.com> On Mon, Mar 23, 2015 at 02:23:52PM +0530, Yogesh Sharma wrote: > Sure Jakub. ++FreeIPA-Users > > "getent netgroup" not working on IPA Server > > [root at mipa ~]# getent netgroup stg.initd.com > [root at mipa ~]# > > > > [root at mipa ~]# ipa hostgroup-show cipa-servers > Host-group: cipa-servers > Description: cipa > Member hosts: cipa.stg.initd.com > Member of netgroups: stg.initd.com > > [root at mipa ~]# ipa netgroup-show stg.initd.com > Netgroup name: stg.initd.com > Description: ss > NIS domain name: stg.initd.com > Member Group: admins, ipausers, masteruser, trust admins, webuser > Member Hostgroup: sipa-servers, cipa-servers > > However, I re-register the IPA Client and I am able to query netgroup, > Though it does not shows cipa.stg.initd.com whereas IPA Server query "ipa > netgroup-show stg.initd.com" has it in list. > > [root at cipa ~]# getent passwd admin > admin:*:1170400000:1170400000:Administrator:/home/admin:/bin/bash > [root at cipa ~]# getent netgroup stg.initd.com > stg.initd.com (sipa.stg.initd.com,-,stg.initd.com) > [root at cipa ~]# OK, then we need to see the SSSD logs, but if the client suddently started working, then I suspect some networking issues. From pspacek at redhat.com Mon Mar 23 09:35:26 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Mar 2015 10:35:26 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> Message-ID: <550FDE5E.7000501@redhat.com> On 23.3.2015 10:21, Roberto Cornacchia wrote: > About the DNS update, this is what the debug log has to say: > > Found zone name: hq.example.com > The master is: ipa.hq.example.com > start_gssrequest > Found realm from ticket: HQ.EXAMPLE.COM > send_gssrequest > *; Communication with 192.168.0.72#53 failed: operation canceled* > *Reply from SOA query:* > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4923 > ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > ;; QUESTION SECTION: > ;1835417091.sig-ipa.hq.example.com. ANY TKEY > > response to SOA query was unsuccessful - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA server. - Please check named.logs on the server side to see if there are any complains about unsuccessful key negotiation with client. > Notice that is is *different* from what I got before the chronyd change. > Before, there was not even a reply: > > Found zone name: hq.example.com > The master is: ipa.hq.example.com > start_gssrequest > Found realm from ticket: HQ.EXAMPLE.COM > send_gssrequest > *; Communication with 192.168.0.72#53 failed: operation canceled* > *could not reach any name server* Interesting, this should not be related to time synchronization in any way. DNS server simply did not return any answer. -- Petr^2 Spacek From yks0000 at gmail.com Mon Mar 23 10:48:56 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 23 Mar 2015 16:18:56 +0530 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: <20150323092912.GH4110@hendrix.arn.redhat.com> References: <20150323064115.GZ8409@hendrix.redhat.com> <20150323075131.GA4110@hendrix.arn.redhat.com> <20150323092912.GH4110@hendrix.arn.redhat.com> Message-ID: Seeing a strange behavior. I deleted all Host Members from NetGroup and it was reflected in Client: [root at cipa ~]# getent netgroup stg.initd.com stg.initd.com then I added one hostgroup *"cipa" * and it was successfully quried in getent on IPA Server [root at mipa ~]# getent netgroup stg.initd.com stg.initd.com (cipa.stg.initd.com,-,stg.initd.com) However, when adding another hostgroup in Netgroup , I am not able to see that in getent though ipa command list it. [root at mipa ~]# ipa netgroup-show stg.initd.com Netgroup name: stg.initd.com Description: sssss NIS domain name: stg.initd.com Member Group: admins, ipausers, masteruser, trust admins, webuser Member Hostgroup: cipa-servers, sipa-servers [root at mipa ~]# My Client is also unaware of changes. [root at cipa ~]# getent netgroup stg.initd.com stg.initd.com [root at cipa ~]# Is it network issue or sssd caching problem. Restart of SSSD also does not fix the problem. Should I share my SSSD logs of IPA server or Client or Both. Please suggest. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Mon, Mar 23, 2015 at 2:59 PM, Jakub Hrozek wrote: > On Mon, Mar 23, 2015 at 02:23:52PM +0530, Yogesh Sharma wrote: > > Sure Jakub. ++FreeIPA-Users > > > > "getent netgroup" not working on IPA Server > > > > [root at mipa ~]# getent netgroup stg.initd.com > > [root at mipa ~]# > > > > > > > > [root at mipa ~]# ipa hostgroup-show cipa-servers > > Host-group: cipa-servers > > Description: cipa > > Member hosts: cipa.stg.initd.com > > Member of netgroups: stg.initd.com > > > > [root at mipa ~]# ipa netgroup-show stg.initd.com > > Netgroup name: stg.initd.com > > Description: ss > > NIS domain name: stg.initd.com > > Member Group: admins, ipausers, masteruser, trust admins, webuser > > Member Hostgroup: sipa-servers, cipa-servers > > > > However, I re-register the IPA Client and I am able to query netgroup, > > Though it does not shows cipa.stg.initd.com whereas IPA Server query > "ipa > > netgroup-show stg.initd.com" has it in list. > > > > [root at cipa ~]# getent passwd admin > > admin:*:1170400000:1170400000:Administrator:/home/admin:/bin/bash > > [root at cipa ~]# getent netgroup stg.initd.com > > stg.initd.com (sipa.stg.initd.com,-,stg.initd.com) > > [root at cipa ~]# > > OK, then we need to see the SSSD logs, but if the client suddently > started working, then I suspect some networking issues. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Mon Mar 23 10:57:14 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 23 Mar 2015 16:27:14 +0530 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: References: <20150323064115.GZ8409@hendrix.redhat.com> <20150323075131.GA4110@hendrix.arn.redhat.com> <20150323092912.GH4110@hendrix.arn.redhat.com> Message-ID: I just deleted the netgroup, even though getent is resolving. [root at mipa ~]# getent netgroup stg.initd.com stg.initd.com (cipa.stg.initd.com,-,stg.initd.com) [root at mipa ~]# ipa netgroup-show stg.initd.com ipa: ERROR: stg.initd.com: netgroup not found Sent IPA Server Logs to you individually. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Mon, Mar 23, 2015 at 4:18 PM, Yogesh Sharma wrote: > Seeing a strange behavior. > > I deleted all Host Members from NetGroup and it was reflected in Client: > > [root at cipa ~]# getent netgroup stg.initd.com > stg.initd.com > > then I added one hostgroup *"cipa" * and it was successfully quried in > getent on IPA Server > > [root at mipa ~]# getent netgroup stg.initd.com > stg.initd.com (cipa.stg.initd.com,-,stg.initd.com) > > However, when adding another hostgroup in Netgroup , I am not able to see > that in getent though ipa command list it. > > > > [root at mipa ~]# ipa netgroup-show stg.initd.com > Netgroup name: stg.initd.com > Description: sssss > NIS domain name: stg.initd.com > Member Group: admins, ipausers, masteruser, trust admins, webuser > Member Hostgroup: cipa-servers, sipa-servers > [root at mipa ~]# > > > My Client is also unaware of changes. > > [root at cipa ~]# getent netgroup stg.initd.com > stg.initd.com > [root at cipa ~]# > > > Is it network issue or sssd caching problem. Restart of SSSD also does not > fix the problem. > > Should I share my SSSD logs of IPA server or Client or Both. Please > suggest. > > > > > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Mon, Mar 23, 2015 at 2:59 PM, Jakub Hrozek wrote: > >> On Mon, Mar 23, 2015 at 02:23:52PM +0530, Yogesh Sharma wrote: >> > Sure Jakub. ++FreeIPA-Users >> > >> > "getent netgroup" not working on IPA Server >> > >> > [root at mipa ~]# getent netgroup stg.initd.com >> > [root at mipa ~]# >> > >> > >> > >> > [root at mipa ~]# ipa hostgroup-show cipa-servers >> > Host-group: cipa-servers >> > Description: cipa >> > Member hosts: cipa.stg.initd.com >> > Member of netgroups: stg.initd.com >> > >> > [root at mipa ~]# ipa netgroup-show stg.initd.com >> > Netgroup name: stg.initd.com >> > Description: ss >> > NIS domain name: stg.initd.com >> > Member Group: admins, ipausers, masteruser, trust admins, webuser >> > Member Hostgroup: sipa-servers, cipa-servers >> > >> > However, I re-register the IPA Client and I am able to query netgroup, >> > Though it does not shows cipa.stg.initd.com whereas IPA Server query >> "ipa >> > netgroup-show stg.initd.com" has it in list. >> > >> > [root at cipa ~]# getent passwd admin >> > admin:*:1170400000:1170400000:Administrator:/home/admin:/bin/bash >> > [root at cipa ~]# getent netgroup stg.initd.com >> > stg.initd.com (sipa.stg.initd.com,-,stg.initd.com) >> > [root at cipa ~]# >> >> OK, then we need to see the SSSD logs, but if the client suddently >> started working, then I suspect some networking issues. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Mar 23 10:59:34 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Mar 2015 11:59:34 +0100 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: References: <20150323064115.GZ8409@hendrix.redhat.com> <20150323075131.GA4110@hendrix.arn.redhat.com> <20150323092912.GH4110@hendrix.arn.redhat.com> Message-ID: <20150323105934.GK4110@hendrix.arn.redhat.com> On Mon, Mar 23, 2015 at 04:18:56PM +0530, Yogesh Sharma wrote: > Seeing a strange behavior. > > I deleted all Host Members from NetGroup and it was reflected in Client: > > [root at cipa ~]# getent netgroup stg.initd.com > stg.initd.com > > then I added one hostgroup *"cipa" * and it was successfully quried in > getent on IPA Server > > [root at mipa ~]# getent netgroup stg.initd.com > stg.initd.com (cipa.stg.initd.com,-,stg.initd.com) > > However, when adding another hostgroup in Netgroup , I am not able to see > that in getent though ipa command list it. > > > > [root at mipa ~]# ipa netgroup-show stg.initd.com > Netgroup name: stg.initd.com > Description: sssss > NIS domain name: stg.initd.com > Member Group: admins, ipausers, masteruser, trust admins, webuser > Member Hostgroup: cipa-servers, sipa-servers > [root at mipa ~]# > > > My Client is also unaware of changes. > > [root at cipa ~]# getent netgroup stg.initd.com > stg.initd.com > [root at cipa ~]# > > > Is it network issue or sssd caching problem. Restart of SSSD also does not > fix the problem. That's normal, SSSD caches the information. See man sssd.conf for the timeout settings. Please note that as the timeouts are stored in the cache, you'd need to remove the cache as well if you machine the timeouts. > > Should I share my SSSD logs of IPA server or Client or Both. Please suggest. >From the machine that is having problems resolving the netgroup. From jhrozek at redhat.com Mon Mar 23 11:00:46 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Mar 2015 12:00:46 +0100 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: References: <20150323064115.GZ8409@hendrix.redhat.com> <20150323075131.GA4110@hendrix.arn.redhat.com> <20150323092912.GH4110@hendrix.arn.redhat.com> Message-ID: <20150323110046.GL4110@hendrix.arn.redhat.com> On Mon, Mar 23, 2015 at 04:27:14PM +0530, Yogesh Sharma wrote: > I just deleted the netgroup, even though getent is resolving. > > [root at mipa ~]# getent netgroup stg.initd.com > stg.initd.com (cipa.stg.initd.com,-,stg.initd.com) > [root at mipa ~]# ipa netgroup-show stg.initd.com > ipa: ERROR: stg.initd.com: netgroup not found > > Sent IPA Server Logs to you individually. You only sent the sssd section, that's not useful. Please read: https://fedorahosted.org/sssd/wiki/Troubleshooting There is a section about generating SSSD logs. Also anything that applies to resolving users applies to resolving netgroups as well. From mkosek at redhat.com Mon Mar 23 11:04:35 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Mar 2015 12:04:35 +0100 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <550F836F.7090201@gmail.com> References: <550F836F.7090201@gmail.com> Message-ID: <550FF343.3030105@redhat.com> On 03/23/2015 04:07 AM, Janelle wrote: > Hello > > Starting to see a lot of these and wondering what I am dealign with? > > attrlist_replace - attr_replace (nsslapd-referral, > ldap://ipa1.example.com:389/o%3Dipaca) failed. Hm, I do not met this error yet. This looks like error from 389-ds-base, it has functions like attrlist_replace. If this is the case, can you please share a bigger section of the errors log, ideally for the whole day (if not too big)? There might be some other related error messages. CCing Ludwig and Thierry for reference. Also, what environment are we talking about, is this still FreeIPA 4.1.3 at CentOS-7? Maybe the server also has a replication agreement also with CentOS-6? We need to know this also. Thanks, Martin From mkosek at redhat.com Mon Mar 23 11:07:19 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Mar 2015 12:07:19 +0100 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: References: Message-ID: <550FF3E7.2090106@redhat.com> This may mean that Dogtag is not up. Can you please check with "ipactl status" that it (pki-ca) is up and running and that there are no related SELinux AVCs? On 03/23/2015 04:52 AM, Michael Pawlak wrote: > Does anybody have any thoughts on this? > > *Michael Pawlak* > Web Systems Administrator | Colovore LLC > E: mike at colovore.com > C: 408.316.2154 > > > On Sun, Mar 22, 2015 at 12:05 AM, Michael Pawlak wrote: > >> I am not able to setup a replica using the 'ipa-replica-prepare' command. >> After some debugging this appears related to the certmonger/dogtag system >> that is incorporated with FreeIPA. I am including the output below of any >> relevant logs / commands. >> >> ----- ipa-replica-prepare ----- >> >> ipa-replica-prepare newipa.example.com --ca=/etc/ipa/ca.crt --password >> 'somepassword' >> Preparing replica for newipa.example.com from ipa.example.com >> Creating SSL certificate for the Directory Server >> Certificate operation cannot be completed: Unable to communicate with CMS >> (Not Found) >> >> ----- ipa-getcert list ----- >> >> Number of certificates and requests being tracked: 8. >> Request ID '20140811232518': >> status: CA_UNREACHABLE >> ca-error: Server at https://ipa.example.com/ipa/xml failed request, >> will retry: 4301 (RPC failed at server. Certificate operation cannot be >> completed: Unable to communicate with CMS (Not Found)). >> 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 >> subject: CN=ipa.example.com,O=EXAMPLE >> expires: 2016-08-11 23:24:36 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 '20140811232742': >> status: CA_UNREACHABLE >> ca-error: Server at https://ipa.example.com/ipa/xml failed request, >> will retry: 4301 (RPC failed at server. Certificate operation cannot be >> completed: Unable to communicate with CMS (Not Found)). >> stuck: no >> key pair storage: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS >> Certificate DB',pinfile='/etc/dirsrv/slapd-COLOVORE/pwdfile.txt' >> certificate: >> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS >> Certificate DB' >> CA: IPA >> issuer: CN=Certificate Authority,O=EXAMPLE >> subject: CN=ipa.example.com,O=EXAMPLE >> expires: 2016-08-11 23:24:34 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 '20140811232843': >> status: CA_UNREACHABLE >> ca-error: Server at https://ipa.example.com/ipa/xml failed request, >> will retry: 4301 (RPC failed at server. Certificate operation cannot be >> completed: Unable to communicate with CMS (Not Found)). >> 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 >> subject: CN=ipa.example.com,O=EXAMPLE >> expires: 2016-08-11 23:24:37 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 >> >> ----- /etc/pki-ca/password.conf ----- >> >> internal=829325937546 >> internaldb=somepassword >> replicationdb=1270571739 >> >> ----- /var/log/pki-ca/debug ----- >> >> [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile >> [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile >> [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem id=selftests >> [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init id=selftests >> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): ENTERING . . . >> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): loading self >> test logger parameters >> [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException >> The self test plugin named selftests.container.logger.class contains a >> value com.netscape.cms.logging.RollingLogFile which is invalid. >> at >> com.netscape.cmscore.selftests.SelfTestSubsystem.init(SelfTestSubsystem.java:1422) >> at >> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:866) >> at >> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:795) >> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:316) >> at com.netscape.certsrv.apps.CMS.init(CMS.java:153) >> at com.netscape.certsrv.apps.CMS.start(CMS.java:1530) >> at >> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:85) >> at >> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) >> at >> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) >> at >> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4425) >> at >> org.apache.catalina.core.StandardContext.start(StandardContext.java:4738) >> at >> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) >> at >> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) >> at >> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) >> at >> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) >> at >> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) >> at >> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) >> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) >> at >> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) >> at >> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) >> at >> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) >> at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) >> at >> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) >> at >> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) >> at >> org.apache.catalina.core.StandardService.start(StandardService.java:516) >> at >> org.apache.catalina.core.StandardServer.start(StandardServer.java:710) >> at org.apache.catalina.startup.Catalina.start(Catalina.java:593) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at >> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >> at >> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:606) >> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) >> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) >> [22/Mar/2015:06:45:10][main]: CMSEngine.shutdown() >> [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization >> for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use >> default authz mgr: {2}. >> [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization >> for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use >> default authz mgr: {2}. >> [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password >> store initialized before. >> [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password >> store initialized. >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: About to start >> updateCertStatus >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting updateCertStatus >> (entered lock) >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In updateCertStatus() >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> LdapBoundConnFactory::getConn() >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >> getInvalidCertificatesByNotBeforeDate filter (certStatus=INVALID) >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >> getInvalidCertificatesByNotBeforeDate: about to call findCertRecordsInList >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> LdapBoundConnFactory::getConn() >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter >> attrs startFrom sortKey pageSize filter: (certStatus=INVALID) attrs: >> [objectclass, certRecordId, x509cert] pageSize -200 startFrom >> 20150322065510Z >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> getInvalidCertsByNotBeforeDate finally. >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: >> 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: index may be empty >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> LdapBoundConnFactory::getConn() >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >> getValidCertsByNotAfterDate filter (certStatus=VALID) >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> LdapBoundConnFactory::getConn() >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter >> attrs startFrom sortKey pageSize filter: (certStatus=VALID) attrs: >> [objectclass, certRecordId, x509cert] pageSize -200 startFrom >> 20150322065510Z >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: >> 69 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transidValidCertificates: >> list size: 69 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitValidCertificates: >> ltSize 1 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction getting >> index 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not >> qualify,notAfter Sat Jul 09 05:12:31 UTC 2016 date Sun Mar 22 06:55:10 UTC >> 2015 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList EXPIRED >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> LdapBoundConnFactory::getConn() >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >> getRevokedCertificatesByNotAfterDate filter (certStatus=REVOKED) >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >> getRevokedCertificatesByNotAfterDate: about to call findCertRecordsInList >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> LdapBoundConnFactory::getConn() >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >> true >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter >> attrs startFrom sortKey pageSize filter: (certStatus=REVOKED) attrs: >> [objectclass, certRevokedOn, certRecordId, certRevoInfo, notAfter, >> x509cert] pageSize -200 startFrom 20150322065510Z >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: >> 5 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >> transitRevokedExpiredCertificates: list size: 5 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >> transitRevokedExpiredCertificates: ltSize 1 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction getting >> index 0 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitRevokedExpired: >> curRec: 0 CertRecord: 268369925 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not >> qualify,notAfter Wed Jul 20 06:25:57 UTC 2016 date Sun Mar 22 06:55:10 UTC >> 2015 >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList >> REVOKED_EXPIRED >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: updateCertStatus done >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting cert checkRanges >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely >> started. Returning .. >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: cert checkRanges done >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting request >> checkRanges >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely >> started. Returning .. >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: request checkRanges done >> >> > > > From roberto.cornacchia at gmail.com Mon Mar 23 11:16:53 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Mon, 23 Mar 2015 12:16:53 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550FDE5E.7000501@redhat.com> References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> <550FDE5E.7000501@redhat.com> Message-ID: On 23 March 2015 at 10:35, Petr Spacek wrote: > On 23.3.2015 10:21, Roberto Cornacchia wrote: > > About the DNS update, this is what the debug log has to say: > > > > Found zone name: hq.example.com > > The master is: ipa.hq.example.com > > start_gssrequest > > Found realm from ticket: HQ.EXAMPLE.COM > > send_gssrequest > > *; Communication with 192.168.0.72#53 failed: operation canceled* > > *Reply from SOA query:* > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4923 > > ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > > ;; QUESTION SECTION: > > ;1835417091.sig-ipa.hq.example.com. ANY TKEY > > > > response to SOA query was unsuccessful > > - Please verify that 192.168.0.72 is the correct IP address of the FreeIPA > server. > Positive > - Please check named.logs on the server side to see if there are any > complains > about unsuccessful key negotiation with client. > > I raised named's log level to debug 10 and restarted Ran ipa-client-install again. The log shows many queries from the client, for A/AAA/SOA record types, both about the server and the client. All approved, no problem. The log does not seem to contain a single failure / rejection. However: 1) The client reports that response to SOA query was unsuccessful. The server log does not say anything about this. 2) The server log does not contain any update request > > Notice that is is *different* from what I got before the chronyd change. > > Before, there was not even a reply: > > > > Found zone name: hq.example.com > > The master is: ipa.hq.example.com > > start_gssrequest > > Found realm from ticket: HQ.EXAMPLE.COM > > send_gssrequest > > *; Communication with 192.168.0.72#53 failed: operation canceled* > > *could not reach any name server* > > Interesting, this should not be related to time synchronization in any way. > DNS server simply did not return any answer. > > -- > Petr^2 Spacek > > -- > 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 roberto.cornacchia at gmail.com Mon Mar 23 11:19:27 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Mon, 23 Mar 2015 12:19:27 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> <550FDE5E.7000501@redhat.com> Message-ID: BTW, shouldn't named.conf contain an "allow-update" statement? Mine doesn't. Or is this managed differently? On 23 March 2015 at 12:16, Roberto Cornacchia wrote: > > > On 23 March 2015 at 10:35, Petr Spacek wrote: > >> On 23.3.2015 10:21, Roberto Cornacchia wrote: >> > About the DNS update, this is what the debug log has to say: >> > >> > Found zone name: hq.example.com >> > The master is: ipa.hq.example.com >> > start_gssrequest >> > Found realm from ticket: HQ.EXAMPLE.COM >> > send_gssrequest >> > *; Communication with 192.168.0.72#53 failed: operation canceled* >> > *Reply from SOA query:* >> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4923 >> > ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >> > ;; QUESTION SECTION: >> > ;1835417091.sig-ipa.hq.example.com. ANY TKEY >> > >> > response to SOA query was unsuccessful >> >> - Please verify that 192.168.0.72 is the correct IP address of the >> FreeIPA server. >> > > Positive > > >> - Please check named.logs on the server side to see if there are any >> complains >> about unsuccessful key negotiation with client. >> >> > I raised named's log level to debug 10 and restarted > Ran ipa-client-install again. > The log shows many queries from the client, for A/AAA/SOA record types, > both about the server and the client. All approved, no problem. > The log does not seem to contain a single failure / rejection. > > However: > 1) The client reports that response to SOA query was unsuccessful. The > server log does not say anything about this. > 2) The server log does not contain any update request > > >> > Notice that is is *different* from what I got before the chronyd change. >> > Before, there was not even a reply: >> > >> > Found zone name: hq.example.com >> > The master is: ipa.hq.example.com >> > start_gssrequest >> > Found realm from ticket: HQ.EXAMPLE.COM >> > send_gssrequest >> > *; Communication with 192.168.0.72#53 failed: operation canceled* >> > *could not reach any name server* >> >> Interesting, this should not be related to time synchronization in any >> way. >> DNS server simply did not return any answer. >> >> -- >> Petr^2 Spacek >> >> -- >> 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 Mar 23 11:19:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Mar 2015 12:19:31 +0100 Subject: [Freeipa-users] Adding a custom attribute to user object In-Reply-To: References: Message-ID: <550FF6C3.1000400@redhat.com> On 03/23/2015 10:19 AM, Prashant Bapat wrote: > Hi, > > I'm trying to add a custom attribute to user object. Below is the ldif i'm > using. > > dn: cn=schema > changetype: modify > add: attributeTypes > attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME 'ipaSshSigTimestamp' > DESC 'SSH public key signature and timestamp' EQUALITY octetStringMatch > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM FREEIPA EXTENTION' ) > - > add: objectclasses > objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME 'ApigeeUserAttr' SUP > top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY ipaSshSigTimestamp ) > > This gets added successfully using the ldapmodify command as directory > manager. But both the UI and the ipa config-mod commands refuse to add the > new attribute to ipaUserObjectClasses with error objectclass not found. > > What I'm I doing wrong ? Not sure yet, the schema above looks OK (except some typos). I tried it on my VM, and it just worked: # ldapmodify -D "cn=Directory Manager" -x -w Secret123 ... modifying entry "cn=schema" # ipa config-mod --userobjectclasses={ipaobject,person,top,ipasshuser,inetorgperson,organizationalperson,krbticketpolicyaux,krbprincipalaux,inetuser,posixaccount,ApigeeUserAttr} ... Default user objectclasses: ipaobject, person, top, ipasshuser, inetorgperson, organizationalperson, krbticketpolicyaux, krbprincipalaux, ApigeeUserAttr, inetuser, posixaccount # ipa user-add apigee --first Foo --last Bar --setattr ipaSshSigTimestamp=barbar ------------------- Added user "apigee" ------------------- User login: apigee First name: Foo Last name: Bar Full name: Foo Bar Display name: Foo Bar Initials: FB Home directory: /home/apigee GECOS: Foo Bar Login shell: /bin/sh Kerberos principal: apigee at F21 Email address: apigee at f21.test UID: 1889400080 GID: 1889400080 Password: False Member of groups: ipausers Kerberos keys available: False # ldapsearch -Y GSSAPI -b 'uid=apigee,cn=users,cn=accounts,dc=f21' uid ipaSshSigTimestamp SASL/GSSAPI authentication started SASL username: admin at F21 SASL SSF: 56 SASL data security layer installed. # extended LDIF # # LDAPv3 # base with scope subtree # filter: (objectclass=*) # requesting: uid ipaSshSigTimestamp # # apigee, users, accounts, f21 dn: uid=apigee,cn=users,cn=accounts,dc=f21 uid: apigee ipaSshSigTimestamp: barbar # search result search: 4 result: 0 Success # numResponses: 2 # numEntries: 1 BTW, did you read one of the very relevant upstream guides how to add custom attributes to LDAP? It pretty much covers the procedure you are working on: http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf Martin From mkosek at redhat.com Mon Mar 23 11:22:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Mar 2015 12:22:31 +0100 Subject: [Freeipa-users] Firewalld rules to allow AD Join In-Reply-To: <6301806E96421841896741228C6B1A2764C5A1AE@G4W3216.americas.hpqcorp.net> References: <6301806E96421841896741228C6B1A2764C5A1AE@G4W3216.americas.hpqcorp.net> Message-ID: <550FF777.70701@redhat.com> On 03/20/2015 09:59 PM, McEvoy, James wrote: > Hi FreeIPA Users: > > I can only get my new Fedora 21 freeipa to server to setup a trust with Active Directory if I turn off the firewall on the ipa server. I have looked through all the doc on which ports to open but have had no luck getting the join to work with firewalld running... Can someone tell me what firewalld is blocking on me? > > --jim > > These are my open services: > > # firewall-cmd --zone=public --list-all > public (default) > interfaces: > sources: > services: dhcpv6-client dns freeipa-ldap freeipa-ldaps http https kerberos kpasswd ldap ldaps mdns ntp samba ssh > ports: > masquerade: no > forward-ports: > icmp-blocks: > > [root at ipa ~]# ipa trust-add ENAS.NET --type=ad --admin=Administrator --password > Active Directory domain administrator's password: > ipa: ERROR: AD DC was unable to reach any IPA domain controller. Most likely it is a DNS or firewall issue > > As soon as I turn off the firewall it works: > > [root at ipa ~]# systemctl stop firewalld > [root at ipa ~]# ipa trust-add ENAS.NET --type=ad --admin=Administrator --password > Active Directory domain administrator's password: > ----------------------------------------- > Re-established trust to domain "enas.net" > ----------------------------------------- > Realm name: enas.net > Domain NetBIOS name: ENAS > Domain Security Identifier: S-1-5-21-1497210546-3194758708-3931123408 > SID blacklist incoming: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, > S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, > S-1-1, S-1-0, S-1-5-19, S-1-5-18 > SID blacklist outgoing: S-1-5-20, S-1-5-3, S-1-5-2, S-1-5-1, S-1-5-7, S-1-5-6, S-1-5-5, S-1-5-4, S-1-5-9, S-1-5-8, > S-1-5-17, S-1-5-16, S-1-5-15, S-1-5-14, S-1-5-13, S-1-5-12, S-1-5-11, S-1-5-10, S-1-3, S-1-2, > S-1-1, S-1-0, S-1-5-19, S-1-5-18 > Trust direction: Two-way trust > Trust type: Active Directory domain > Trust status: Established and verified > > > The only error the I have found is in the samba logs where lsasd has the following: > > [2015/03/19 18:19:22.792043, 1] ipa_sam.c:1671(search_krb_princ) > get_trusted_domain_int: no object found with filter 'krbPrincipalName=krbtgt/ENAS.NET at LNX.LAB'. > [2015/03/19 18:19:23.080328, 1] ipa_sam.c:1671(search_krb_princ) > get_trusted_domain_int: no object found with filter 'krbPrincipalName=krbtgt/LNX.LAB at ENAS.NET'. > > > and winbindd-imap has this in it: > > [2015/03/20 14:21:14.966125, 1] ../source3/winbindd/idmap.c:202(idmap_init_domain) > idmap range not specified for domain * > [2015/03/20 14:21:14.968671, 1] ../source3/winbindd/idmap.c:202(idmap_init_domain) > idmap range not specified for domain * > > > This is the list You must make sure these network ports are open: TCP Ports: * 138: netbios-dgm * 139: netbios-ssn * 445: microsoft-ds UDP Ports: * 138: netbios-dgm * 139: netbios-ssn * 389: (C)LDAP * 445: microsoft-ds Additionally you have to make sure the FreeIPA LDAP server is not reachable by any domain controller in the Active Directory domain by closing down the following ports for these servers: TCP Ports: * 389, 636: LDAP/LDAPS I do not think you have configured all of those. You can find more info on our wiki: http://www.freeipa.org/page/Active_Directory_trust_setup#Firewall_configuration Martin From mbasti at redhat.com Mon Mar 23 11:27:13 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 23 Mar 2015 12:27:13 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> <550FDE5E.7000501@redhat.com> Message-ID: <550FF891.60002@redhat.com> On 23/03/15 12:19, Roberto Cornacchia wrote: > BTW, shouldn't named.conf contain an "allow-update" statement? Mine > doesn't. Or is this managed differently? It is not needed. bind-dyndb-ldap plugin overrides this configuration, you just need to enable updates in IPA zone setting. Martin > > > On 23 March 2015 at 12:16, Roberto Cornacchia > > > wrote: > > > > On 23 March 2015 at 10:35, Petr Spacek > wrote: > > On 23.3.2015 10:21, Roberto Cornacchia wrote: > > About the DNS update, this is what the debug log has to say: > > > > Found zone name: hq.example.com > > The master is: ipa.hq.example.com > > start_gssrequest > > Found realm from ticket: HQ.EXAMPLE.COM > > send_gssrequest > > *; Communication with 192.168.0.72#53 failed: operation canceled* > > *Reply from SOA query:* > > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4923 > > ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, > ADDITIONAL: 0 > > ;; QUESTION SECTION: > > ;1835417091.sig-ipa.hq.example.com > . ANY TKEY > > > > response to SOA query was unsuccessful > > - Please verify that 192.168.0.72 is the correct IP address of > the FreeIPA server. > > > Positive > > - Please check named.logs on the server side to see if there > are any complains > about unsuccessful key negotiation with client. > > > I raised named's log level to debug 10 and restarted > Ran ipa-client-install again. > The log shows many queries from the client, for A/AAA/SOA record > types, both about the server and the client. All approved, no problem. > The log does not seem to contain a single failure / rejection. > > However: > 1) The client reports that response to SOA query was unsuccessful. > The server log does not say anything about this. > 2) The server log does not contain any update request > > > > Notice that is is *different* from what I got before the > chronyd change. > > Before, there was not even a reply: > > > > Found zone name: hq.example.com > > The master is: ipa.hq.example.com > > start_gssrequest > > Found realm from ticket: HQ.EXAMPLE.COM > > send_gssrequest > > *; Communication with 192.168.0.72#53 failed: operation canceled* > > *could not reach any name server* > > Interesting, this should not be related to time > synchronization in any way. > DNS server simply did not return any answer. > > -- > Petr^2 Spacek > > -- > 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 > > > > > -- Martin Basti -------------- next part -------------- An HTML attachment was scrubbed... URL: From bentech4you at gmail.com Mon Mar 23 11:29:30 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Mon, 23 Mar 2015 14:29:30 +0300 Subject: [Freeipa-users] FreeIPA 3.3 AD<-> Solaris is working but solaris local users cannot able to login In-Reply-To: References: Message-ID: HI i created the home directory manually and copied the profile. i tried to access the solaris box from putty and still it's not accepting password. On Mon, Mar 23, 2015 at 11:03 AM, Ben .T.George wrote: > HI List > > finally after soo much struggling now i can able to login solaris box as > AD user. > > but auto home directory creation still have issue. for that i need to > compile some modules. > > > The issue i am facing is i cannot able to login to solaris box after > editing pam.conf file.here is the conf file > > bash-3.2# cat /etc/pam.conf > # > #ident "@(#)pam.conf 1.32 11/04/08 SMI" > # > # > login auth requisite pam_authtok_get.so.1 > login auth required pam_dhkeys.so.1 > login auth sufficient pam_ldap.so.1 debug > login auth sufficient pam_krb5.so.1 > login auth required pam_unix_cred.so.1 > 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 sufficient pam_rhosts_auth.so.1 > 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 sufficient pam_rhosts_auth.so.1 > 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 > other auth required pam_dhkeys.so.1 > other auth sufficient pam_krb5.so.1 > other auth sufficient pam_ldap.so.1 > other auth required pam_unix_cred.so.1 > other auth required pam_unix_auth.so.1 > # > # 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 > other account required pam_unix_account.so.1 > other account sufficient pam_krb5.so.1 > other account sufficient pam_ldap.so.1 > # > # 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 > # Password construction requirements apply to all users. > # Remove force_check to have the traditional authorized administrator > # bypass of construction requirements. > other password requisite pam_authtok_check.so.1 force_check > other password required pam_authtok_store.so.1 > # > # Support for Kerberos V5 authentication and example configurations can > # be found in the pam_krb5(5) man page under the "EXAMPLES" section. > # > > > please anyone help me to fix this issue. > > > Thanks & Regards, > Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Mon Mar 23 11:33:28 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Mon, 23 Mar 2015 12:33:28 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <550FF891.60002@redhat.com> References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> <550FDE5E.7000501@redhat.com> <550FF891.60002@redhat.com> Message-ID: OK, thanks. That would be "Dynamic updates", right? Then it is enabled. $ ipa dnszone-show --all Zone name: hq.example.com dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com Zone name: hq.example.com. Active zone: TRUE Authoritative nameserver: ipa.hq.example.com. Administrator e-mail address: hostmaster.hq.example.com. SOA serial: 1427108043 SOA refresh: 3600 SOA retry: 900 SOA expire: 1209600 SOA minimum: 3600 BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM krb5-self * AAAA; grant HQ.EXAMPLE.COM krb5-self * SSHFP; Dynamic update: TRUE Allow query: any; Allow transfer: none; Allow PTR sync: FALSE nsrecord: ipa.hq.example.com. objectclass: idnszone, top, idnsrecord On 23 March 2015 at 12:27, Martin Basti wrote: > On 23/03/15 12:19, Roberto Cornacchia wrote: > > BTW, shouldn't named.conf contain an "allow-update" statement? Mine > doesn't. Or is this managed differently? > > It is not needed. > bind-dyndb-ldap plugin overrides this configuration, you just need to > enable updates in IPA zone setting. > > Martin > > > > On 23 March 2015 at 12:16, Roberto Cornacchia < > roberto.cornacchia at gmail.com> wrote: > >> >> >> On 23 March 2015 at 10:35, Petr Spacek wrote: >> >>> On 23.3.2015 10:21, Roberto Cornacchia wrote: >>> > About the DNS update, this is what the debug log has to say: >>> > >>> > Found zone name: hq.example.com >>> > The master is: ipa.hq.example.com >>> > start_gssrequest >>> > Found realm from ticket: HQ.EXAMPLE.COM >>> > send_gssrequest >>> > *; Communication with 192.168.0.72#53 failed: operation canceled* >>> > *Reply from SOA query:* >>> > ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4923 >>> > ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >>> > ;; QUESTION SECTION: >>> > ;1835417091.sig-ipa.hq.example.com. ANY TKEY >>> > >>> > response to SOA query was unsuccessful >>> >>> - Please verify that 192.168.0.72 is the correct IP address of the >>> FreeIPA server. >>> >> >> Positive >> >> >>> - Please check named.logs on the server side to see if there are any >>> complains >>> about unsuccessful key negotiation with client. >>> >>> >> I raised named's log level to debug 10 and restarted >> Ran ipa-client-install again. >> The log shows many queries from the client, for A/AAA/SOA record types, >> both about the server and the client. All approved, no problem. >> The log does not seem to contain a single failure / rejection. >> >> However: >> 1) The client reports that response to SOA query was unsuccessful. The >> server log does not say anything about this. >> 2) The server log does not contain any update request >> >> >>> > Notice that is is *different* from what I got before the chronyd >>> change. >>> > Before, there was not even a reply: >>> > >>> > Found zone name: hq.example.com >>> > The master is: ipa.hq.example.com >>> > start_gssrequest >>> > Found realm from ticket: HQ.EXAMPLE.COM >>> > send_gssrequest >>> > *; Communication with 192.168.0.72#53 failed: operation canceled* >>> > *could not reach any name server* >>> >>> Interesting, this should not be related to time synchronization in any >>> way. >>> DNS server simply did not return any answer. >>> >>> -- >>> Petr^2 Spacek >>> >>> -- >>> 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 >>> >> >> > > > > > -- > Martin Basti > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prashant at apigee.com Mon Mar 23 12:07:39 2015 From: prashant at apigee.com (Prashant Bapat) Date: Mon, 23 Mar 2015 17:37:39 +0530 Subject: [Freeipa-users] Adding a custom attribute to user object In-Reply-To: <550FF6C3.1000400@redhat.com> References: <550FF6C3.1000400@redhat.com> Message-ID: Martin, Thanks! Let me double check. Yes I was referring to the exact same pdf. Regards. --Prashant On 23 March 2015 at 16:49, Martin Kosek wrote: > On 03/23/2015 10:19 AM, Prashant Bapat wrote: > > Hi, > > > > I'm trying to add a custom attribute to user object. Below is the ldif > i'm > > using. > > > > dn: cn=schema > > changetype: modify > > add: attributeTypes > > attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME 'ipaSshSigTimestamp' > > DESC 'SSH public key signature and timestamp' EQUALITY octetStringMatch > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM FREEIPA EXTENTION' > ) > > - > > add: objectclasses > > objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME 'ApigeeUserAttr' SUP > > top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY ipaSshSigTimestamp ) > > > > This gets added successfully using the ldapmodify command as directory > > manager. But both the UI and the ipa config-mod commands refuse to add > the > > new attribute to ipaUserObjectClasses with error objectclass not found. > > > > What I'm I doing wrong ? > > Not sure yet, the schema above looks OK (except some typos). I tried it on > my > VM, and it just worked: > > # ldapmodify -D "cn=Directory Manager" -x -w Secret123 > ... > modifying entry "cn=schema" > > # ipa config-mod > > --userobjectclasses={ipaobject,person,top,ipasshuser,inetorgperson,organizationalperson,krbticketpolicyaux,krbprincipalaux,inetuser,posixaccount,ApigeeUserAttr} > ... > Default user objectclasses: ipaobject, person, top, ipasshuser, > inetorgperson, organizationalperson, > krbticketpolicyaux, krbprincipalaux, > ApigeeUserAttr, inetuser, > posixaccount > > > # ipa user-add apigee --first Foo --last Bar --setattr > ipaSshSigTimestamp=barbar > ------------------- > Added user "apigee" > ------------------- > User login: apigee > First name: Foo > Last name: Bar > Full name: Foo Bar > Display name: Foo Bar > Initials: FB > Home directory: /home/apigee > GECOS: Foo Bar > Login shell: /bin/sh > Kerberos principal: apigee at F21 > Email address: apigee at f21.test > UID: 1889400080 > GID: 1889400080 > Password: False > Member of groups: ipausers > Kerberos keys available: False > > > # ldapsearch -Y GSSAPI -b 'uid=apigee,cn=users,cn=accounts,dc=f21' uid > ipaSshSigTimestamp > SASL/GSSAPI authentication started > SASL username: admin at F21 > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: uid ipaSshSigTimestamp > # > > # apigee, users, accounts, f21 > dn: uid=apigee,cn=users,cn=accounts,dc=f21 > uid: apigee > ipaSshSigTimestamp: barbar > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > > BTW, did you read one of the very relevant upstream guides how to add > custom > attributes to LDAP? It pretty much covers the procedure you are working on: > > http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > > Martin > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Mon Mar 23 12:33:07 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 23 Mar 2015 13:33:07 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> <550FDE5E.7000501@redhat.com> <550FF891.60002@redhat.com> Message-ID: <55100803.6090602@redhat.com> On 23.3.2015 12:33, Roberto Cornacchia wrote: > OK, thanks. > That would be "Dynamic updates", right? Then it is enabled. > > $ ipa dnszone-show --all > Zone name: hq.example.com > dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com > Zone name: hq.example.com. > Active zone: TRUE > Authoritative nameserver: ipa.hq.example.com. > Administrator e-mail address: hostmaster.hq.example.com. > SOA serial: 1427108043 > SOA refresh: 3600 > SOA retry: 900 > SOA expire: 1209600 > SOA minimum: 3600 > BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant HQ.EXAMPLE.COM > krb5-self * AAAA; grant HQ.EXAMPLE.COM krb5-self * SSHFP; > Dynamic update: TRUE This is correct (but it should not affect SOA query anyway). Could you share named logs on debug level 10 with us? It would be even better is you could provide us tcpdump with transactions in question. On the client (before you start installation) please: 1) Execute command $ tcpdump -i any -w /tmp/dns.pcap 'port 53' 2) Run ipa-client-install 3) Kill the tcpdump: $ pkill tcpdump 4) Send us the file. Feel free to send the files to me (pspacek at redhat.com) and Martin^2 (mbasti at redhat.com) privately if you do not want to make them public. Have a nice day! Petr^2 Spacek > Allow query: any; > Allow transfer: none; > Allow PTR sync: FALSE > nsrecord: ipa.hq.example.com. > objectclass: idnszone, top, idnsrecord > > > On 23 March 2015 at 12:27, Martin Basti wrote: > >> On 23/03/15 12:19, Roberto Cornacchia wrote: >> >> BTW, shouldn't named.conf contain an "allow-update" statement? Mine >> doesn't. Or is this managed differently? >> >> It is not needed. >> bind-dyndb-ldap plugin overrides this configuration, you just need to >> enable updates in IPA zone setting. >> >> Martin >> >> >> >> On 23 March 2015 at 12:16, Roberto Cornacchia < >> roberto.cornacchia at gmail.com> wrote: >> >>> >>> >>> On 23 March 2015 at 10:35, Petr Spacek wrote: >>> >>>> On 23.3.2015 10:21, Roberto Cornacchia wrote: >>>>> About the DNS update, this is what the debug log has to say: >>>>> >>>>> Found zone name: hq.example.com >>>>> The master is: ipa.hq.example.com >>>>> start_gssrequest >>>>> Found realm from ticket: HQ.EXAMPLE.COM >>>>> send_gssrequest >>>>> *; Communication with 192.168.0.72#53 failed: operation canceled* >>>>> *Reply from SOA query:* >>>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4923 >>>>> ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 >>>>> ;; QUESTION SECTION: >>>>> ;1835417091.sig-ipa.hq.example.com. ANY TKEY >>>>> >>>>> response to SOA query was unsuccessful >>>> >>>> - Please verify that 192.168.0.72 is the correct IP address of the >>>> FreeIPA server. >>>> >>> >>> Positive >>> >>> >>>> - Please check named.logs on the server side to see if there are any >>>> complains >>>> about unsuccessful key negotiation with client. >>>> >>>> >>> I raised named's log level to debug 10 and restarted >>> Ran ipa-client-install again. >>> The log shows many queries from the client, for A/AAA/SOA record types, >>> both about the server and the client. All approved, no problem. >>> The log does not seem to contain a single failure / rejection. >>> >>> However: >>> 1) The client reports that response to SOA query was unsuccessful. The >>> server log does not say anything about this. >>> 2) The server log does not contain any update request >>> >>> >>>>> Notice that is is *different* from what I got before the chronyd >>>> change. >>>>> Before, there was not even a reply: >>>>> >>>>> Found zone name: hq.example.com >>>>> The master is: ipa.hq.example.com >>>>> start_gssrequest >>>>> Found realm from ticket: HQ.EXAMPLE.COM >>>>> send_gssrequest >>>>> *; Communication with 192.168.0.72#53 failed: operation canceled* >>>>> *could not reach any name server* >>>> >>>> Interesting, this should not be related to time synchronization in any >>>> way. >>>> DNS server simply did not return any answer. >>>> >>>> -- >>>> Petr^2 Spacek From janellenicole80 at gmail.com Mon Mar 23 12:50:08 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 23 Mar 2015 05:50:08 -0700 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <550FF343.3030105@redhat.com> References: <550F836F.7090201@gmail.com> <550FF343.3030105@redhat.com> Message-ID: <55100C00.3010302@gmail.com> On 3/23/15 4:04 AM, Martin Kosek wrote: > On 03/23/2015 04:07 AM, Janelle wrote: >> Hello >> >> Starting to see a lot of these and wondering what I am dealign with? >> >> attrlist_replace - attr_replace (nsslapd-referral, >> ldap://ipa1.example.com:389/o%3Dipaca) failed. > Hm, I do not met this error yet. This looks like error from 389-ds-base, it has > functions like attrlist_replace. > > If this is the case, can you please share a bigger section of the errors log, > ideally for the whole day (if not too big)? There might be some other related > error messages. CCing Ludwig and Thierry for reference. > > Also, what environment are we talking about, is this still > FreeIPA 4.1.3 at CentOS-7? Maybe the server also has a replication agreement also > with CentOS-6? We need to know this also. > > Thanks, > Martin FreeIPA 4.1.3, CentOS 7 Only CentOS 7 -- no other versions intermixed. Nothing else to give you. Sadly, it just repeats alot. No other errrors in the log. It has a replication agreement with another master - both CA's One interesting note -- this was the server that had the ipa-replica-install --setup-ca run on it from the other master. And the other master is ipa1 server. This server that has these errors is ipa2. So this is complaining(?) that the original server is doing something? [23/Mar/2015:04:13:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:13:52 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:13:52 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:13:52 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:23:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:28:52 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:28:52 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:28:52 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. [23/Mar/2015:05:38:50 -0700] attrlist_replace - attr_replace (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. From yks0000 at gmail.com Mon Mar 23 12:56:21 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 23 Mar 2015 18:26:21 +0530 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: <20150323110046.GL4110@hendrix.arn.redhat.com> References: <20150323064115.GZ8409@hendrix.redhat.com> <20150323075131.GA4110@hendrix.arn.redhat.com> <20150323092912.GH4110@hendrix.arn.redhat.com> <20150323110046.GL4110@hendrix.arn.redhat.com> Message-ID: Thanks Jakub. All the issue seems to be resolved now except that getent is not able to resolve on IPA Server however working fine on other. Below are the logs where it says it is not able to connect DataProvided. (Mon Mar 23 18:12:25 2015) [sssd[nss]] [server_setup] (0x0400): CONFDB: /var/lib/sss/db/config.ldb (Mon Mar 23 18:12:25 2015) [sssd[nss]] [confdb_get_domain_internal] (0x0400): No enumeration for [stg.initd.com]! (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sbus_init_connection] (0x0200): Adding connection B96E29C0 (Mon Mar 23 18:12:25 2015) [sssd[nss]] [monitor_common_send_id] (0x0100): Sending ID: (nss,1) (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sss_names_init] (0x0100): Using re [(((?P[^\\]+)\\(?P.+$))|((?P[^@]+)@(?P.+$))|(^(?P[^@\\]+)$))]. (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sbus_init_connection] (0x0200): Adding connection B96E3FB8 (Mon Mar 23 18:12:25 2015) [sssd[nss]] [dp_common_send_id] (0x0100): Sending ID to DP: (1,NSS) (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sysdb_domain_init_internal] (0x0200): DB File for stg.initd.com: /var/lib/sss/db/cache_stg.initd.com.ldb (Mon Mar 23 18:12:25 2015) [sssd[nss]] [ldb] (0x0400): asq: Unable to register control with rootdse! (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sss_process_init] (0x0400): Responder Initialization complete (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/USER/stg.initd.com/root] to negative cache permanently (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'root' matched without domain, user is root (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Mar 23 18:12:25 2015) [sssd[nss]] [sss_ncache_set_str] (0x0400): Adding [NCE/GROUP/stg.initd.com/root] to negative cache permanently (Mon Mar 23 18:12:25 2015) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /bin/sh in /etc/shells (Mon Mar 23 18:12:25 2015) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /bin/bash in /etc/shells (Mon Mar 23 18:12:25 2015) [sssd[nss]] [nss_get_etc_shells] (0x0400): Found shell /sbin/nologin in /etc/shells (Mon Mar 23 18:12:25 2015) [sssd[nss]] [responder_set_fd_limit] (0x0100): Maximum file descriptors set to [8192] (Mon Mar 23 18:12:25 2015) [sssd[nss]] [nss_process_init] (0x0400): NSS Initialization complete (Mon Mar 23 18:12:25 2015) [sssd[nss]] [id_callback] (0x0100): Got id ack and version (1) from Monitor (Mon Mar 23 18:12:25 2015) [sssd[nss]] [dp_id_callback] (0x0100): Got id ack and version (1) from DP (Mon Mar 23 18:12:32 2015) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected! (Mon Mar 23 18:12:32 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Mon Mar 23 18:12:32 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Mon Mar 23 18:12:32 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): name 'stg.initd.com' matched without domain, user is stg.initd.com (Mon Mar 23 18:12:32 2015) [sssd[nss]] [sss_parse_name_for_domains] (0x0200): using default domain [(null)] (Mon Mar 23 18:12:32 2015) [sssd[nss]] [setnetgrent_send] (0x0100): Requesting info for netgroup [stg.initd.com] from [] (Mon Mar 23 18:12:32 2015) [sssd[nss]] [lookup_netgr_step] (0x0100): Requesting info for [stg.initd.com at stg.initd.com] (Mon Mar 23 18:12:32 2015) [sssd[nss]] [lookup_netgr_step] (0x0040): No results for netgroup stg.initd.com (domain stg.initd.com) (Mon Mar 23 18:12:32 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0xb77624d0:4:stg.initd.com at stg.initd.com] (Mon Mar 23 18:12:32 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [stg.initd.com][4100][1][name=stg.initd.com] (Mon Mar 23 18:12:32 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0xb77624d0:4:stg.initd.com at stg.initd.com] *(Mon Mar 23 18:12:33 2015) [sssd[nss]] [lookup_netgr_dp_callback] (0x0040): Unable to get information from Data Provider* *Error: 3, 17, Netgroup lookup failed* *Will try to return what we have in cache* (Mon Mar 23 18:12:33 2015) [sssd[nss]] [lookup_netgr_step] (0x0100): Requesting info for [stg.initd.com at stg.initd.com] (Mon Mar 23 18:12:33 2015) [sssd[nss]] [lookup_netgr_step] (0x0040): No results for netgroup stg.initd.com (domain stg.initd.com) (Mon Mar 23 18:12:33 2015) [sssd[nss]] [lookup_netgr_step] (0x0080): No matching domain found for [stg.initd.com], fail! (Mon Mar 23 18:12:33 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0xb77624d0:4:stg.initd.com at stg.initd.com] (Mon Mar 23 18:12:33 2015) [sssd[nss]] [client_recv] (0x0200): Client disconnected! Below is SSSD.conf: (Text in Bold resovled the cache issue, I have kept low for testing purpose :) ) [domain/stg.initd.com] *enumerate = False* *cache_credentials = True* *entry_cache_timeout = 120* *entry_cache_netgroup_timeout = 60* krb5_store_password_if_offline = True ipa_domain = stg.initd.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = mipa.stg.initd.com chpass_provider = ipa ipa_server = mipa.stg.initd.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh config_file_version = 2 domains = stg.initd.com [nss] debug_level = 6 [pam] [sudo] [autofs] [ssh] [pac] *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Mon, Mar 23, 2015 at 4:30 PM, Jakub Hrozek wrote: > On Mon, Mar 23, 2015 at 04:27:14PM +0530, Yogesh Sharma wrote: > > I just deleted the netgroup, even though getent is resolving. > > > > [root at mipa ~]# getent netgroup stg.initd.com > > stg.initd.com (cipa.stg.initd.com,-,stg.initd.com) > > [root at mipa ~]# ipa netgroup-show stg.initd.com > > ipa: ERROR: stg.initd.com: netgroup not found > > > > Sent IPA Server Logs to you individually. > > You only sent the sssd section, that's not useful. Please read: > https://fedorahosted.org/sssd/wiki/Troubleshooting > > There is a section about generating SSSD logs. Also anything that > applies to resolving users applies to resolving netgroups as well. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Mon Mar 23 13:04:19 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Mon, 23 Mar 2015 14:04:19 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <55100803.6090602@redhat.com> References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> <550FDE5E.7000501@redhat.com> <550FF891.60002@redhat.com> <55100803.6090602@redhat.com> Message-ID: Thank you, dump sent privately On 23 March 2015 at 13:33, Petr Spacek wrote: > On 23.3.2015 12:33, Roberto Cornacchia wrote: > > OK, thanks. > > That would be "Dynamic updates", right? Then it is enabled. > > > > $ ipa dnszone-show --all > > Zone name: hq.example.com > > dn: idnsname=hq.example.com.,cn=dns,dc=hq,dc=example,dc=com > > Zone name: hq.example.com. > > Active zone: TRUE > > Authoritative nameserver: ipa.hq.example.com. > > Administrator e-mail address: hostmaster.hq.example.com. > > SOA serial: 1427108043 > > SOA refresh: 3600 > > SOA retry: 900 > > SOA expire: 1209600 > > SOA minimum: 3600 > > BIND update policy: grant HQ.EXAMPLE.COM krb5-self * A; grant > HQ.EXAMPLE.COM > > krb5-self * AAAA; grant HQ.EXAMPLE.COM krb5-self * SSHFP; > > Dynamic update: TRUE > > This is correct (but it should not affect SOA query anyway). > > Could you share named logs on debug level 10 with us? It would be even > better > is you could provide us tcpdump with transactions in question. > > On the client (before you start installation) please: > 1) Execute command $ tcpdump -i any -w /tmp/dns.pcap 'port 53' > 2) Run ipa-client-install > 3) Kill the tcpdump: $ pkill tcpdump > 4) Send us the file. > > Feel free to send the files to me (pspacek at redhat.com) and Martin^2 > (mbasti at redhat.com) privately if you do not want to make them public. > > Have a nice day! > > Petr^2 Spacek > > > Allow query: any; > > Allow transfer: none; > > Allow PTR sync: FALSE > > nsrecord: ipa.hq.example.com. > > objectclass: idnszone, top, idnsrecord > > > > > > On 23 March 2015 at 12:27, Martin Basti wrote: > > > >> On 23/03/15 12:19, Roberto Cornacchia wrote: > >> > >> BTW, shouldn't named.conf contain an "allow-update" statement? Mine > >> doesn't. Or is this managed differently? > >> > >> It is not needed. > >> bind-dyndb-ldap plugin overrides this configuration, you just need to > >> enable updates in IPA zone setting. > >> > >> Martin > >> > >> > >> > >> On 23 March 2015 at 12:16, Roberto Cornacchia < > >> roberto.cornacchia at gmail.com> wrote: > >> > >>> > >>> > >>> On 23 March 2015 at 10:35, Petr Spacek wrote: > >>> > >>>> On 23.3.2015 10:21, Roberto Cornacchia wrote: > >>>>> About the DNS update, this is what the debug log has to say: > >>>>> > >>>>> Found zone name: hq.example.com > >>>>> The master is: ipa.hq.example.com > >>>>> start_gssrequest > >>>>> Found realm from ticket: HQ.EXAMPLE.COM > >>>>> send_gssrequest > >>>>> *; Communication with 192.168.0.72#53 failed: operation canceled* > >>>>> *Reply from SOA query:* > >>>>> ;; ->>HEADER<<- opcode: QUERY, status: SERVFAIL, id: 4923 > >>>>> ;; flags: qr ra; QUESTION: 1, ANSWER: 0, AUTHORITY: 0, ADDITIONAL: 0 > >>>>> ;; QUESTION SECTION: > >>>>> ;1835417091.sig-ipa.hq.example.com. ANY TKEY > >>>>> > >>>>> response to SOA query was unsuccessful > >>>> > >>>> - Please verify that 192.168.0.72 is the correct IP address of the > >>>> FreeIPA server. > >>>> > >>> > >>> Positive > >>> > >>> > >>>> - Please check named.logs on the server side to see if there are any > >>>> complains > >>>> about unsuccessful key negotiation with client. > >>>> > >>>> > >>> I raised named's log level to debug 10 and restarted > >>> Ran ipa-client-install again. > >>> The log shows many queries from the client, for A/AAA/SOA record types, > >>> both about the server and the client. All approved, no problem. > >>> The log does not seem to contain a single failure / rejection. > >>> > >>> However: > >>> 1) The client reports that response to SOA query was unsuccessful. The > >>> server log does not say anything about this. > >>> 2) The server log does not contain any update request > >>> > >>> > >>>>> Notice that is is *different* from what I got before the chronyd > >>>> change. > >>>>> Before, there was not even a reply: > >>>>> > >>>>> Found zone name: hq.example.com > >>>>> The master is: ipa.hq.example.com > >>>>> start_gssrequest > >>>>> Found realm from ticket: HQ.EXAMPLE.COM > >>>>> send_gssrequest > >>>>> *; Communication with 192.168.0.72#53 failed: operation canceled* > >>>>> *could not reach any name server* > >>>> > >>>> Interesting, this should not be related to time synchronization in any > >>>> way. > >>>> DNS server simply did not return any answer. > >>>> > >>>> -- > >>>> Petr^2 Spacek > > -- > 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 tbordaz at redhat.com Mon Mar 23 13:15:44 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Mon, 23 Mar 2015 14:15:44 +0100 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <55100C00.3010302@gmail.com> References: <550F836F.7090201@gmail.com> <550FF343.3030105@redhat.com> <55100C00.3010302@gmail.com> Message-ID: <55101200.1010004@redhat.com> On 03/23/2015 01:50 PM, Janelle wrote: > On 3/23/15 4:04 AM, Martin Kosek wrote: >> On 03/23/2015 04:07 AM, Janelle wrote: >>> Hello >>> >>> Starting to see a lot of these and wondering what I am dealign with? >>> >>> attrlist_replace - attr_replace (nsslapd-referral, >>> ldap://ipa1.example.com:389/o%3Dipaca) failed. >> Hm, I do not met this error yet. This looks like error from >> 389-ds-base, it has >> functions like attrlist_replace. >> >> If this is the case, can you please share a bigger section of the >> errors log, >> ideally for the whole day (if not too big)? There might be some other >> related >> error messages. CCing Ludwig and Thierry for reference. >> >> Also, what environment are we talking about, is this still >> FreeIPA 4.1.3 at CentOS-7? Maybe the server also has a replication >> agreement also >> with CentOS-6? We need to know this also. >> >> Thanks, >> Martin > FreeIPA 4.1.3, CentOS 7 > Only CentOS 7 -- no other versions intermixed. > > Nothing else to give you. Sadly, it just repeats alot. No other > errrors in the log. > > It has a replication agreement with another master - both CA's > One interesting note -- this was the server that had the > ipa-replica-install --setup-ca run on it from the other master. And > the other master is ipa1 server. This server that has these errors is > ipa2. So this is complaining(?) that the original server is doing > something? > > [23/Mar/2015:04:13:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:23:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:28:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:38:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:43:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:53:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:04:58:53 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:00:00 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:05:02 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:08:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:13:52 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:13:52 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:13:52 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:23:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:23:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:23:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:28:52 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:28:52 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:28:52 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:38:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:38:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. > [23/Mar/2015:05:38:50 -0700] attrlist_replace - attr_replace > (nsslapd-referral, ldap://ipa1.example.com:389/o%3Dipaca) failed. Hello, These messages report that DS fails to update (MOD/replace) an entry with the 'nsslapd-referral: ldap://ipa1.example.com:389/o%3Dipaca' . Unfortunately neither the error code and the entry are logged. I think we should be able to see this in DS access logs if the operation is not an internal operation. Thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Mar 23 13:24:25 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Mar 2015 09:24:25 -0400 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: <550FF3E7.2090106@redhat.com> References: <550FF3E7.2090106@redhat.com> Message-ID: <55101409.5000505@redhat.com> Martin Kosek wrote: > This may mean that Dogtag is not up. Can you please check with "ipactl status" > that it (pki-ca) is up and running and that there are no related SELinux AVCs? > The problem seems to be java-related: The self test plugin named selftests.container.logger.class contains a value com.netscape.cms.logging.RollingLogFile which is invalid. I've seen cases where selftest failures don't cause the CA to not start up but does prevent it from actually operating. The bottom line of the errors you are seeing is that the CA is not completely running. I've cc'd a couple of dogtag developers to see if they can help with the Java exception. rob > On 03/23/2015 04:52 AM, Michael Pawlak wrote: >> Does anybody have any thoughts on this? >> >> *Michael Pawlak* >> Web Systems Administrator | Colovore LLC >> E: mike at colovore.com >> C: 408.316.2154 >> >> >> On Sun, Mar 22, 2015 at 12:05 AM, Michael Pawlak wrote: >> >>> I am not able to setup a replica using the 'ipa-replica-prepare' command. >>> After some debugging this appears related to the certmonger/dogtag system >>> that is incorporated with FreeIPA. I am including the output below of any >>> relevant logs / commands. >>> >>> ----- ipa-replica-prepare ----- >>> >>> ipa-replica-prepare newipa.example.com --ca=/etc/ipa/ca.crt --password >>> 'somepassword' >>> Preparing replica for newipa.example.com from ipa.example.com >>> Creating SSL certificate for the Directory Server >>> Certificate operation cannot be completed: Unable to communicate with CMS >>> (Not Found) >>> >>> ----- ipa-getcert list ----- >>> >>> Number of certificates and requests being tracked: 8. >>> Request ID '20140811232518': >>> status: CA_UNREACHABLE >>> ca-error: Server at https://ipa.example.com/ipa/xml failed request, >>> will retry: 4301 (RPC failed at server. Certificate operation cannot be >>> completed: Unable to communicate with CMS (Not Found)). >>> 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 >>> subject: CN=ipa.example.com,O=EXAMPLE >>> expires: 2016-08-11 23:24:36 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 '20140811232742': >>> status: CA_UNREACHABLE >>> ca-error: Server at https://ipa.example.com/ipa/xml failed request, >>> will retry: 4301 (RPC failed at server. Certificate operation cannot be >>> completed: Unable to communicate with CMS (Not Found)). >>> stuck: no >>> key pair storage: >>> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS >>> Certificate DB',pinfile='/etc/dirsrv/slapd-COLOVORE/pwdfile.txt' >>> certificate: >>> type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS >>> Certificate DB' >>> CA: IPA >>> issuer: CN=Certificate Authority,O=EXAMPLE >>> subject: CN=ipa.example.com,O=EXAMPLE >>> expires: 2016-08-11 23:24:34 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 '20140811232843': >>> status: CA_UNREACHABLE >>> ca-error: Server at https://ipa.example.com/ipa/xml failed request, >>> will retry: 4301 (RPC failed at server. Certificate operation cannot be >>> completed: Unable to communicate with CMS (Not Found)). >>> 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 >>> subject: CN=ipa.example.com,O=EXAMPLE >>> expires: 2016-08-11 23:24:37 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 >>> >>> ----- /etc/pki-ca/password.conf ----- >>> >>> internal=829325937546 >>> internaldb=somepassword >>> replicationdb=1270571739 >>> >>> ----- /var/log/pki-ca/debug ----- >>> >>> [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem id=selftests >>> [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init id=selftests >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): ENTERING . . . >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): loading self >>> test logger parameters >>> [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException >>> The self test plugin named selftests.container.logger.class contains a >>> value com.netscape.cms.logging.RollingLogFile which is invalid. >>> at >>> com.netscape.cmscore.selftests.SelfTestSubsystem.init(SelfTestSubsystem.java:1422) >>> at >>> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:866) >>> at >>> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:795) >>> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:316) >>> at com.netscape.certsrv.apps.CMS.init(CMS.java:153) >>> at com.netscape.certsrv.apps.CMS.start(CMS.java:1530) >>> at >>> com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:85) >>> at >>> org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) >>> at >>> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) >>> at >>> org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4425) >>> at >>> org.apache.catalina.core.StandardContext.start(StandardContext.java:4738) >>> at >>> org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) >>> at >>> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) >>> at >>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) >>> at >>> org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) >>> at >>> org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) >>> at >>> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) >>> at org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) >>> at >>> org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) >>> at >>> org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) >>> at >>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) >>> at org.apache.catalina.core.StandardHost.start(StandardHost.java:722) >>> at >>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) >>> at >>> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) >>> at >>> org.apache.catalina.core.StandardService.start(StandardService.java:516) >>> at >>> org.apache.catalina.core.StandardServer.start(StandardServer.java:710) >>> at org.apache.catalina.startup.Catalina.start(Catalina.java:593) >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at >>> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) >>> at >>> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.lang.reflect.Method.invoke(Method.java:606) >>> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) >>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) >>> [22/Mar/2015:06:45:10][main]: CMSEngine.shutdown() >>> [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization >>> for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use >>> default authz mgr: {2}. >>> [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization >>> for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use >>> default authz mgr: {2}. >>> [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password >>> store initialized before. >>> [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password >>> store initialized. >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: About to start >>> updateCertStatus >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting updateCertStatus >>> (entered lock) >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In updateCertStatus() >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> LdapBoundConnFactory::getConn() >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >>> getInvalidCertificatesByNotBeforeDate filter (certStatus=INVALID) >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >>> getInvalidCertificatesByNotBeforeDate: about to call findCertRecordsInList >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> LdapBoundConnFactory::getConn() >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter >>> attrs startFrom sortKey pageSize filter: (certStatus=INVALID) attrs: >>> [objectclass, certRecordId, x509cert] pageSize -200 startFrom >>> 20150322065510Z >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> getInvalidCertsByNotBeforeDate finally. >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: >>> 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: index may be empty >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> LdapBoundConnFactory::getConn() >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >>> getValidCertsByNotAfterDate filter (certStatus=VALID) >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> LdapBoundConnFactory::getConn() >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter >>> attrs startFrom sortKey pageSize filter: (certStatus=VALID) attrs: >>> [objectclass, certRecordId, x509cert] pageSize -200 startFrom >>> 20150322065510Z >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: >>> 69 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transidValidCertificates: >>> list size: 69 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitValidCertificates: >>> ltSize 1 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction getting >>> index 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not >>> qualify,notAfter Sat Jul 09 05:12:31 UTC 2016 date Sun Mar 22 06:55:10 UTC >>> 2015 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList EXPIRED >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> LdapBoundConnFactory::getConn() >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >>> getRevokedCertificatesByNotAfterDate filter (certStatus=REVOKED) >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >>> getRevokedCertificatesByNotAfterDate: about to call findCertRecordsInList >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> LdapBoundConnFactory::getConn() >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is connected >>> true >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In >>> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter >>> attrs startFrom sortKey pageSize filter: (certStatus=REVOKED) attrs: >>> [objectclass, certRevokedOn, certRecordId, certRevoInfo, notAfter, >>> x509cert] pageSize -200 startFrom 20150322065510Z >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 2 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns now 3 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List size: >>> 5 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >>> transitRevokedExpiredCertificates: list size: 5 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: >>> transitRevokedExpiredCertificates: ltSize 1 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction getting >>> index 0 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitRevokedExpired: >>> curRec: 0 CertRecord: 268369925 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not >>> qualify,notAfter Wed Jul 20 06:25:57 UTC 2016 date Sun Mar 22 06:55:10 UTC >>> 2015 >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList >>> REVOKED_EXPIRED >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: updateCertStatus done >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting cert checkRanges >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely >>> started. Returning .. >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: cert checkRanges done >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting request >>> checkRanges >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely >>> started. Returning .. >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: request checkRanges done >>> >>> >> >> >> > From bobby.prins at proxy.nl Mon Mar 23 15:37:34 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Mon, 23 Mar 2015 16:37:34 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <550C218F.2000907@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <20150319171119.GI27609@p.redhat.com> <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> <20150320111050.GN3878@redhat.com> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> Message-ID: <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> >On 03/20/2015 08:05 AM, Alexander Bokovoy wrote: >> On Fri, 20 Mar 2015, Bobby Prins wrote: >>>> On Fri, 20 Mar 2015, Sumit Bose wrote: >>>>> On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote: >>>>>> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >>>>>> >> Hi there, >>>>>> >> >>>>>> >> I'm currently trying to use the 'AD Trust for Legacy Clients' >>>>>> >> freeIPA setup (described here: >>>>>> >> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) >>>>>> >> to be able to autenticate AIX 7.1 clients against an AD domain >>>>>> >> using LDAP. After the trust was created all seems to work well >>>>>> >> on the freeIPA server. I can also do a lookup of AD users and >>>>>> >> groups on an AIX test server. >>>>>> >> >>>>>> >> But as soon as I want to log in on the AIX system I get an SSSD >>>>>> error on the freeIPA server in krb5_child.log (debug_level = 10): >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS >>>>>> key obtained for encrypted timestamp: aes256-cts/2F5D >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: >>>>>> Encrypted timestamp (for 1426778442.525165): plain >>>>>> 301AA011180F32303135303331393135323034325AA105020308036D, >>>>>> encrypted >>>>>> 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: >>>>>> Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: >>>>>> Produced preauth for next request: 2 >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: >>>>>> Sending request (238 bytes) to EXAMPLE.CORP >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: >>>>>> Resolving hostname dct020.example.corp. >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: >>>>>> Sending initial UDP request to dgram 192.168.143.1:88 >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: >>>>>> Received answer from dgram 192.168.143.1:88 >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: >>>>>> Response was not from master KDC >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: >>>>>> Received error from KDC: -1765328360/Preauthentication failed >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: >>>>>> Preauth tryagain input types: 16, 14, 19, 2 >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: >>>>>> Retrying AS request with master KDC >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: >>>>>> Getting initial credentials for BPrins at EXAMPLE.CORP >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: >>>>>> Sending request (160 bytes) to EXAMPLE.CORP (master) >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication >>>>>> failed] >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication >>>>>> failed] >>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>> [k5c_send_data] (0x0200): Received error code 1432158214 >>>>>> >> >>>>>> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit >>>>>> BPrins at EXAMPLE.CORP': >>>>>> >> [12299] 1426773524.361785: AS key obtained for encrypted >>>>>> timestamp: aes256-cts/B997 >>>>>> >> [12299] 1426773524.361850: Encrypted timestamp (for >>>>>> 1426773524.277583): plain >>>>>> 301AA011180F32303135303331393133353834345AA1050203043C4F, >>>>>> encrypted >>>>>> ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >>>>>> >> [12299] 1426773524.361876: Preauth module encrypted_timestamp >>>>>> (2) (flags=1) returned: 0/Success >>>>>> >> [12299] 1426773524.361880: Produced preauth for next request: 2 >>>>>> >> [12299] 1426773524.361901: Sending request (238 bytes) to >>>>>> EXAMPLE.CORP >>>>>> >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >>>>>> >> [12299] 1426773524.363841: Sending initial UDP request to dgram >>>>>> 192.168.141.1:88 >>>>>> >> [12299] 1426773524.368089: Received answer from dgram >>>>>> 192.168.141.1:88 >>>>>> >> [12299] 1426773524.368482: Response was not from master KDC >>>>>> >> [12299] 1426773524.368500: Received error from KDC: >>>>>> -1765328332/Response too big for UDP, retry with TCP >>>>>> >> [12299] 1426773524.368506: Request or response is too big for >>>>>> UDP; retrying with TCP >>>>>> >> [12299] 1426773524.368511: Sending request (238 bytes) to >>>>>> EXAMPLE.CORP (tcp only) >>>>>> >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >>>>>> >> [12299] 1426773524.370056: Initiating TCP connection to stream >>>>>> 192.168.143.5:88 >>>>>> >> [12299] 1426773524.375140: Sending TCP request to stream >>>>>> 192.168.143.5:88 >>>>>> >> [12299] 1426773524.383801: Received answer from stream >>>>>> 192.168.143.5:88 >>>>>> >> [12299] 1426773524.384237: Response was not from master KDC >>>>>> >> [12299] 1426773524.384263: Processing preauth types: 19 >>>>>> >> [12299] 1426773524.384271: Selected etype info: etype >>>>>> aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >>>>>> >> [12299] 1426773524.384275: Produced preauth for next request: >>>>>> (empty) >>>>>> >> [12299] 1426773524.384282: AS key determined by preauth: >>>>>> aes256-cts/B997 >>>>>> >> [12299] 1426773524.384329: Decrypted AS reply; session key is: >>>>>> rc4-hmac/39AB >>>>>> >> [12299] 1426773524.384333: FAST negotiation: unavailable >>>>>> >> [12299] 1426773524.384357: Initializing >>>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ >>>>>> BPrins at EXAMPLE.CORP >>>>>> >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> >>>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from >>>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>>> >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> >>>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in >>>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>>> >> [12299] 1426773524.384469: Storing config in >>>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v for >>>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 >>>>>> >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> >>>>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: >>>>>> from KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>>> >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> >>>>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: >>>>>> in KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>>> >> >>>>>> >> Any ideas? >>>>>> > >>>>>> >Can you log in to the IPA server as this user? If yes I would assume >>>>>> >that the password gets garbled somewhere on the way from AIX >>>>>> through the >>>>>> >IPA machinery to SSSD. Does the password contain some special >>>>>> characters >>>>>> >which some LDAP processing calls might want the escape? >>>>>> > >>>>>> >bye, >>>>>> >Sumit >>>>>> > >>>>>> Yes, I can login with the account on the IPA server without any >>>>>> problems. I tried it with different password to rule out problems >>>>>> with special characters. Finally I did a tcpdump on the IPA server. >>>>>> The AIX server sends the word 'INCORRECT' to the IPA server instead >>>>>> of the password. So I guess I have to do some more configuration >>>>>> checks on the AIX server. >>>>> >>>>> Thank you for the feedback. >>>>> >>>>> Just a wild guess, since you were able to see anything in the >>>>> tcpdump I >>>>> guess an unencrypted connection is used. Maybe AIX prevents that the >>>>> password is send via a clear text connection? >>>> It is openssh behavior. It sends INCORRECT line as part of the password >>>> when there is no valid shell for that user to login. >>>> >>>> OpenSSH validates content of 'struct passwd' returned for the user, >>>> including checks on whether shell is there as an executable file. This >>>> check fails and user is considered 'invalid'. Still, OpenSSH competes >>>> PAM authentication, making sure the password field is filled with >>>> specially constructed string "\b\n\r\177INCORRECT", to ensure there is >>>> registered failed login attempt. >>> Wow, thanks for that! If I do a lsuser/ldapsearch on the AIX host the >>> shell/loginShell is missing for AD users. The admin IPA user has this >>> attribute set and I can log in with that account. Can this be solved on >>> the IPA server? >> In FreeIPA 4.1 (Fedora 21+ or RHEL7.1) you can do set shell separately >> for each AD user using ID Views: >> >> ipa idoverrideuser-add 'Default Trust View' 'AD\User' --shell /bin/ksh >> >> Compat tree and SSSD on RHEL7.1/Fedora21 should take default trust view >> into account for AD users. >> >Once we are out of the woods here it would be really nice to have a blog >or a wiki page about how to configure AIX clients properly to leverage >trusts including this interesting aspect related to the shell. >Bobby would you be able to share this information? > >-- >Thank you, >Dmitri Pal No problem Dmitri. Would love to help with that! At the moment I'm still getting 'invalid user' messages on the AIX side even though the shell is set using an ID view. SSH server logging: debug3: AIX/loginrestrictions returned -1 msg 3004-300 You entered an invalid login name or password. Login restricted for bprins at aero.corp: 3004-300 You entered an invalid login name or password. Console logging: AIX Version 7 Copyright IBM Corporation, 1982, 2013. Console login: bprins at example.corp bprins at example.corp's Password: 3004-300 You entered an invalid login name or password. 'max_logname' in AIX is set to '50' (default is 9(?)). The only account attribute differences with a valid AIX user are the rather high id/UID and the pgrp/primary group and user name which contain a . and @-sign for the AD user. A local user on the AIX server with a high UID and symbols in the username can login (did some testing with different user names). For now, SSSD seems to handle the authentication request against AD without any problems if I try a console login. From prashant at apigee.com Mon Mar 23 15:40:12 2015 From: prashant at apigee.com (Prashant Bapat) Date: Mon, 23 Mar 2015 21:10:12 +0530 Subject: [Freeipa-users] Adding a custom attribute to user object In-Reply-To: References: <550FF6C3.1000400@redhat.com> Message-ID: Ok the command you gave me worked. But I was following the PDF and below command never worked. ipa config-mod --addattr=ipaUserObjectClasses=ApigeeUserAttr Is that expected ? Thanks. --Prashant On 23 March 2015 at 17:37, Prashant Bapat wrote: > Martin, > > Thanks! > > Let me double check. > > Yes I was referring to the exact same pdf. > > Regards. > --Prashant > > On 23 March 2015 at 16:49, Martin Kosek wrote: > >> On 03/23/2015 10:19 AM, Prashant Bapat wrote: >> > Hi, >> > >> > I'm trying to add a custom attribute to user object. Below is the ldif >> i'm >> > using. >> > >> > dn: cn=schema >> > changetype: modify >> > add: attributeTypes >> > attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME 'ipaSshSigTimestamp' >> > DESC 'SSH public key signature and timestamp' EQUALITY octetStringMatch >> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM FREEIPA >> EXTENTION' ) >> > - >> > add: objectclasses >> > objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME 'ApigeeUserAttr' SUP >> > top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY ipaSshSigTimestamp ) >> > >> > This gets added successfully using the ldapmodify command as directory >> > manager. But both the UI and the ipa config-mod commands refuse to add >> the >> > new attribute to ipaUserObjectClasses with error objectclass not found. >> > >> > What I'm I doing wrong ? >> >> Not sure yet, the schema above looks OK (except some typos). I tried it >> on my >> VM, and it just worked: >> >> # ldapmodify -D "cn=Directory Manager" -x -w Secret123 >> ... >> modifying entry "cn=schema" >> >> # ipa config-mod >> >> --userobjectclasses={ipaobject,person,top,ipasshuser,inetorgperson,organizationalperson,krbticketpolicyaux,krbprincipalaux,inetuser,posixaccount,ApigeeUserAttr} >> ... >> Default user objectclasses: ipaobject, person, top, ipasshuser, >> inetorgperson, organizationalperson, >> krbticketpolicyaux, krbprincipalaux, >> ApigeeUserAttr, inetuser, >> posixaccount >> >> >> # ipa user-add apigee --first Foo --last Bar --setattr >> ipaSshSigTimestamp=barbar >> ------------------- >> Added user "apigee" >> ------------------- >> User login: apigee >> First name: Foo >> Last name: Bar >> Full name: Foo Bar >> Display name: Foo Bar >> Initials: FB >> Home directory: /home/apigee >> GECOS: Foo Bar >> Login shell: /bin/sh >> Kerberos principal: apigee at F21 >> Email address: apigee at f21.test >> UID: 1889400080 >> GID: 1889400080 >> Password: False >> Member of groups: ipausers >> Kerberos keys available: False >> >> >> # ldapsearch -Y GSSAPI -b 'uid=apigee,cn=users,cn=accounts,dc=f21' uid >> ipaSshSigTimestamp >> SASL/GSSAPI authentication started >> SASL username: admin at F21 >> SASL SSF: 56 >> SASL data security layer installed. >> # extended LDIF >> # >> # LDAPv3 >> # base with scope subtree >> # filter: (objectclass=*) >> # requesting: uid ipaSshSigTimestamp >> # >> >> # apigee, users, accounts, f21 >> dn: uid=apigee,cn=users,cn=accounts,dc=f21 >> uid: apigee >> ipaSshSigTimestamp: barbar >> >> # search result >> search: 4 >> result: 0 Success >> >> # numResponses: 2 >> # numEntries: 1 >> >> >> >> BTW, did you read one of the very relevant upstream guides how to add >> custom >> attributes to LDAP? It pretty much covers the procedure you are working >> on: >> >> http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf >> >> Martin >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Mon Mar 23 15:44:47 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Mon, 23 Mar 2015 17:44:47 +0200 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <20150319171119.GI27609@p.redhat.com> <525094696.528275.1426848283484.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> <20150320111050.GN3878@redhat.com> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> Message-ID: <20150323154447.GR3878@redhat.com> On Mon, 23 Mar 2015, Bobby Prins wrote: >>On 03/20/2015 08:05 AM, Alexander Bokovoy wrote: >>> On Fri, 20 Mar 2015, Bobby Prins wrote: >>>>> On Fri, 20 Mar 2015, Sumit Bose wrote: >>>>>> On Fri, Mar 20, 2015 at 11:44:43AM +0100, Bobby Prins wrote: >>>>>>> On Thu, Mar 19, 2015 at 04:46:44PM +0100, Bobby Prins wrote: >>>>>>> >> Hi there, >>>>>>> >> >>>>>>> >> I'm currently trying to use the 'AD Trust for Legacy Clients' >>>>>>> >> freeIPA setup (described here: >>>>>>> >> http://www.freeipa.org/images/0/0d/FreeIPA33-legacy-clients.pdf) >>>>>>> >> to be able to autenticate AIX 7.1 clients against an AD domain >>>>>>> >> using LDAP. After the trust was created all seems to work well >>>>>>> >> on the freeIPA server. I can also do a lookup of AD users and >>>>>>> >> groups on an AIX test server. >>>>>>> >> >>>>>>> >> But as soon as I want to log in on the AIX system I get an SSSD >>>>>>> error on the freeIPA server in krb5_child.log (debug_level = 10): >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590260: AS >>>>>>> key obtained for encrypted timestamp: aes256-cts/2F5D >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590326: >>>>>>> Encrypted timestamp (for 1426778442.525165): plain >>>>>>> 301AA011180F32303135303331393135323034325AA105020308036D, >>>>>>> encrypted >>>>>>> 9B3299264F09E50D63D84B385A09A4C64D44116A02B58FFF12830B39F88722CD9B792F5ABA0653578DE9138B91D29C17C197453D8B8A5E7A >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590349: >>>>>>> Preauth module encrypted_timestamp (2) (flags=1) returned: 0/Success >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590360: >>>>>>> Produced preauth for next request: 2 >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.590384: >>>>>>> Sending request (238 bytes) to EXAMPLE.CORP >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591325: >>>>>>> Resolving hostname dct020.example.corp. >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.591889: >>>>>>> Sending initial UDP request to dgram 192.168.143.1:88 >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636127: >>>>>>> Received answer from dgram 192.168.143.1:88 >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636626: >>>>>>> Response was not from master KDC >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636667: >>>>>>> Received error from KDC: -1765328360/Preauthentication failed >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636698: >>>>>>> Preauth tryagain input types: 16, 14, 19, 2 >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636728: >>>>>>> Retrying AS request with master KDC >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636741: >>>>>>> Getting initial credentials for BPrins at EXAMPLE.CORP >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [sss_child_krb5_trace_cb] (0x4000): [12775] 1426778442.636787: >>>>>>> Sending request (160 bytes) to EXAMPLE.CORP (master) >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [get_and_save_tgt] (0x0020): 979: [-1765328360][Preauthentication >>>>>>> failed] >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [map_krb5_error] (0x0020): 1040: [-1765328360][Preauthentication >>>>>>> failed] >>>>>>> >> (Thu Mar 19 16:20:42 2015) [[sssd[krb5_child[12775]]]] >>>>>>> [k5c_send_data] (0x0200): Received error code 1432158214 >>>>>>> >> >>>>>>> >> If I do the same with 'KRB5_TRACE=/dev/stderr kinit >>>>>>> BPrins at EXAMPLE.CORP': >>>>>>> >> [12299] 1426773524.361785: AS key obtained for encrypted >>>>>>> timestamp: aes256-cts/B997 >>>>>>> >> [12299] 1426773524.361850: Encrypted timestamp (for >>>>>>> 1426773524.277583): plain >>>>>>> 301AA011180F32303135303331393133353834345AA1050203043C4F, >>>>>>> encrypted >>>>>>> ED9CF995617740C4B14DB9CC84187E3505B664FE5C0AD16D19477E912F5400FB2C4665A090E3A37CD749535B3C80595809E14D15CB3527C0 >>>>>>> >> [12299] 1426773524.361876: Preauth module encrypted_timestamp >>>>>>> (2) (flags=1) returned: 0/Success >>>>>>> >> [12299] 1426773524.361880: Produced preauth for next request: 2 >>>>>>> >> [12299] 1426773524.361901: Sending request (238 bytes) to >>>>>>> EXAMPLE.CORP >>>>>>> >> [12299] 1426773524.363002: Resolving hostname dct020.EXAMPLE.corp. >>>>>>> >> [12299] 1426773524.363841: Sending initial UDP request to dgram >>>>>>> 192.168.141.1:88 >>>>>>> >> [12299] 1426773524.368089: Received answer from dgram >>>>>>> 192.168.141.1:88 >>>>>>> >> [12299] 1426773524.368482: Response was not from master KDC >>>>>>> >> [12299] 1426773524.368500: Received error from KDC: >>>>>>> -1765328332/Response too big for UDP, retry with TCP >>>>>>> >> [12299] 1426773524.368506: Request or response is too big for >>>>>>> UDP; retrying with TCP >>>>>>> >> [12299] 1426773524.368511: Sending request (238 bytes) to >>>>>>> EXAMPLE.CORP (tcp only) >>>>>>> >> [12299] 1426773524.368953: Resolving hostname dct030.EXAMPLE.corp. >>>>>>> >> [12299] 1426773524.370056: Initiating TCP connection to stream >>>>>>> 192.168.143.5:88 >>>>>>> >> [12299] 1426773524.375140: Sending TCP request to stream >>>>>>> 192.168.143.5:88 >>>>>>> >> [12299] 1426773524.383801: Received answer from stream >>>>>>> 192.168.143.5:88 >>>>>>> >> [12299] 1426773524.384237: Response was not from master KDC >>>>>>> >> [12299] 1426773524.384263: Processing preauth types: 19 >>>>>>> >> [12299] 1426773524.384271: Selected etype info: etype >>>>>>> aes256-cts, salt "EXAMPLE.CORPBPrins", params "" >>>>>>> >> [12299] 1426773524.384275: Produced preauth for next request: >>>>>>> (empty) >>>>>>> >> [12299] 1426773524.384282: AS key determined by preauth: >>>>>>> aes256-cts/B997 >>>>>>> >> [12299] 1426773524.384329: Decrypted AS reply; session key is: >>>>>>> rc4-hmac/39AB >>>>>>> >> [12299] 1426773524.384333: FAST negotiation: unavailable >>>>>>> >> [12299] 1426773524.384357: Initializing >>>>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v with default princ >>>>>>> BPrins at EXAMPLE.CORP >>>>>>> >> [12299] 1426773524.384400: Removing BPrins at EXAMPLE.CORP -> >>>>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP from >>>>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>>>> >> [12299] 1426773524.384407: Storing BPrins at EXAMPLE.CORP -> >>>>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP in >>>>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>>>> >> [12299] 1426773524.384469: Storing config in >>>>>>> KEYRING:persistent:0:krb_ccache_rhX3V4v for >>>>>>> krbtgt/EXAMPLE.CORP at EXAMPLE.CORP: pa_type: 2 >>>>>>> >> [12299] 1426773524.384484: Removing BPrins at EXAMPLE.CORP -> >>>>>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: >>>>>>> from KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>>>> >> [12299] 1426773524.384492: Storing BPrins at EXAMPLE.CORP -> >>>>>>> krb5_ccache_conf_data/pa_type/krbtgt\/EXAMPLE.CORP\@EXAMPLE.CORP at X-CACHECONF: >>>>>>> in KEYRING:persistent:0:krb_ccache_rhX3V4v >>>>>>> >> >>>>>>> >> Any ideas? >>>>>>> > >>>>>>> >Can you log in to the IPA server as this user? If yes I would assume >>>>>>> >that the password gets garbled somewhere on the way from AIX >>>>>>> through the >>>>>>> >IPA machinery to SSSD. Does the password contain some special >>>>>>> characters >>>>>>> >which some LDAP processing calls might want the escape? >>>>>>> > >>>>>>> >bye, >>>>>>> >Sumit >>>>>>> > >>>>>>> Yes, I can login with the account on the IPA server without any >>>>>>> problems. I tried it with different password to rule out problems >>>>>>> with special characters. Finally I did a tcpdump on the IPA server. >>>>>>> The AIX server sends the word 'INCORRECT' to the IPA server instead >>>>>>> of the password. So I guess I have to do some more configuration >>>>>>> checks on the AIX server. >>>>>> >>>>>> Thank you for the feedback. >>>>>> >>>>>> Just a wild guess, since you were able to see anything in the >>>>>> tcpdump I >>>>>> guess an unencrypted connection is used. Maybe AIX prevents that the >>>>>> password is send via a clear text connection? >>>>> It is openssh behavior. It sends INCORRECT line as part of the password >>>>> when there is no valid shell for that user to login. >>>>> >>>>> OpenSSH validates content of 'struct passwd' returned for the user, >>>>> including checks on whether shell is there as an executable file. This >>>>> check fails and user is considered 'invalid'. Still, OpenSSH competes >>>>> PAM authentication, making sure the password field is filled with >>>>> specially constructed string "\b\n\r\177INCORRECT", to ensure there is >>>>> registered failed login attempt. >>>> Wow, thanks for that! If I do a lsuser/ldapsearch on the AIX host the >>>> shell/loginShell is missing for AD users. The admin IPA user has this >>>> attribute set and I can log in with that account. Can this be solved on >>>> the IPA server? >>> In FreeIPA 4.1 (Fedora 21+ or RHEL7.1) you can do set shell separately >>> for each AD user using ID Views: >>> >>> ipa idoverrideuser-add 'Default Trust View' 'AD\User' --shell /bin/ksh >>> >>> Compat tree and SSSD on RHEL7.1/Fedora21 should take default trust view >>> into account for AD users. >>> >>Once we are out of the woods here it would be really nice to have a blog >>or a wiki page about how to configure AIX clients properly to leverage >>trusts including this interesting aspect related to the shell. >>Bobby would you be able to share this information? >> >>-- >>Thank you, >>Dmitri Pal > >No problem Dmitri. Would love to help with that! > >At the moment I'm still getting 'invalid user' messages on the AIX side even though the shell is set using an ID view. > >SSH server logging: >debug3: AIX/loginrestrictions returned -1 msg 3004-300 You entered an invalid login name or password. >Login restricted for bprins at aero.corp: 3004-300 You entered an invalid login name or password. > >Console logging: >AIX Version 7 >Copyright IBM Corporation, 1982, 2013. >Console login: bprins at example.corp >bprins at example.corp's Password: >3004-300 You entered an invalid login name or password. > >'max_logname' in AIX is set to '50' (default is 9(?)). The only account >attribute differences with a valid AIX user are the rather high id/UID >and the pgrp/primary group and user name which contain a . and @-sign >for the AD user. A local user on the AIX server with a high UID and >symbols in the username can login (did some testing with different user >names). > >For now, SSSD seems to handle the authentication request against AD >without any problems if I try a console login. Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access and sssd logs from IPA master (with debug_level = 10) at least in [domain], [nss], and [pam] sections. You need to filter dirsrv logs by connection coming from AIX IP address and then by conn= where number is the same number as the one with IP address line. When authenticating, AIX would talk to IPA LDAP server to compat tree and slapi-nis plugin which serves compat tree would do PAM authentication as service system-auth where SSSD on IPA master will do the actual authentication work. -- / Alexander Bokovoy From rcritten at redhat.com Mon Mar 23 15:49:19 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Mar 2015 11:49:19 -0400 Subject: [Freeipa-users] Adding a custom attribute to user object In-Reply-To: References: <550FF6C3.1000400@redhat.com> Message-ID: <551035FF.30404@redhat.com> Prashant Bapat wrote: > Ok the command you gave me worked. But I was following the PDF and below > command never worked. > > ipa config-mod --addattr=ipaUserObjectClasses=ApigeeUserAttr > > Is that expected ? Did you restart httpd after adding the schema? A cached copy is used and restarting will cause it to re-read the schema. rob > > Thanks. > --Prashant > > > On 23 March 2015 at 17:37, Prashant Bapat > wrote: > > Martin, > > Thanks! > > Let me double check. > > Yes I was referring to the exact same pdf. > > Regards. > --Prashant > > On 23 March 2015 at 16:49, Martin Kosek > wrote: > > On 03/23/2015 10:19 AM, Prashant Bapat wrote: > > Hi, > > > > I'm trying to add a custom attribute to user object. Below is > the ldif i'm > > using. > > > > dn: cn=schema > > changetype: modify > > add: attributeTypes > > attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME > 'ipaSshSigTimestamp' > > DESC 'SSH public key signature and timestamp' EQUALITY > octetStringMatch > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM FREEIPA > EXTENTION' ) > > - > > add: objectclasses > > objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME > 'ApigeeUserAttr' SUP > > top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY > ipaSshSigTimestamp ) > > > > This gets added successfully using the ldapmodify command as > directory > > manager. But both the UI and the ipa config-mod commands > refuse to add the > > new attribute to ipaUserObjectClasses with error objectclass > not found. > > > > What I'm I doing wrong ? > > Not sure yet, the schema above looks OK (except some typos). I > tried it on my > VM, and it just worked: > > # ldapmodify -D "cn=Directory Manager" -x -w Secret123 > ... > modifying entry "cn=schema" > > # ipa config-mod > --userobjectclasses={ipaobject,person,top,ipasshuser,inetorgperson,organizationalperson,krbticketpolicyaux,krbprincipalaux,inetuser,posixaccount,ApigeeUserAttr} > ... > Default user objectclasses: ipaobject, person, top, ipasshuser, > inetorgperson, organizationalperson, > krbticketpolicyaux, krbprincipalaux, > ApigeeUserAttr, inetuser, > posixaccount > > > # ipa user-add apigee --first Foo --last Bar --setattr > ipaSshSigTimestamp=barbar > ------------------- > Added user "apigee" > ------------------- > User login: apigee > First name: Foo > Last name: Bar > Full name: Foo Bar > Display name: Foo Bar > Initials: FB > Home directory: /home/apigee > GECOS: Foo Bar > Login shell: /bin/sh > Kerberos principal: apigee at F21 > Email address: apigee at f21.test > UID: 1889400080 > GID: 1889400080 > Password: False > Member of groups: ipausers > Kerberos keys available: False > > > # ldapsearch -Y GSSAPI -b > 'uid=apigee,cn=users,cn=accounts,dc=f21' uid > ipaSshSigTimestamp > SASL/GSSAPI authentication started > SASL username: admin at F21 > SASL SSF: 56 > SASL data security layer installed. > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (objectclass=*) > # requesting: uid ipaSshSigTimestamp > # > > # apigee, users, accounts, f21 > dn: uid=apigee,cn=users,cn=accounts,dc=f21 > uid: apigee > ipaSshSigTimestamp: barbar > > # search result > search: 4 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > > > > BTW, did you read one of the very relevant upstream guides how > to add custom > attributes to LDAP? It pretty much covers the procedure you are > working on: > > http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > > Martin > > > > > From jhrozek at redhat.com Mon Mar 23 16:18:58 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 23 Mar 2015 17:18:58 +0100 Subject: [Freeipa-users] SUDO with HostGroup and UserGroup not working In-Reply-To: References: <20150323064115.GZ8409@hendrix.redhat.com> <20150323075131.GA4110@hendrix.arn.redhat.com> <20150323092912.GH4110@hendrix.arn.redhat.com> <20150323110046.GL4110@hendrix.arn.redhat.com> Message-ID: <20150323161858.GT4110@hendrix.arn.redhat.com> On Mon, Mar 23, 2015 at 06:26:21PM +0530, Yogesh Sharma wrote: > Thanks Jakub. > > All the issue seems to be resolved now except that getent is not able to > resolve on IPA Server however working fine on other. > > Below are the logs where it says it is not able to connect DataProvided. > [ ...] > *(Mon Mar 23 18:12:33 2015) [sssd[nss]] [lookup_netgr_dp_callback] > (0x0040): Unable to get information from Data Provider* > *Error: 3, 17, Netgroup lookup failed* > *Will try to return what we have in cache* The lines above ^^ tell me that the Data Provider couldn't retrieve the netgroups from the server. You'd have to look into the domain logs to see why.. > (Mon Mar 23 18:12:33 2015) [sssd[nss]] [lookup_netgr_step] (0x0100): > Requesting info for [stg.initd.com at stg.initd.com] > (Mon Mar 23 18:12:33 2015) [sssd[nss]] [lookup_netgr_step] (0x0040): No > results for netgroup stg.initd.com (domain stg.initd.com) > (Mon Mar 23 18:12:33 2015) [sssd[nss]] [lookup_netgr_step] (0x0080): No > matching domain found for [stg.initd.com], fail! > (Mon Mar 23 18:12:33 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): > Deleting request: [0xb77624d0:4:stg.initd.com at stg.initd.com] > (Mon Mar 23 18:12:33 2015) [sssd[nss]] [client_recv] (0x0200): Client > disconnected! From prashant at apigee.com Mon Mar 23 16:22:46 2015 From: prashant at apigee.com (Prashant Bapat) Date: Mon, 23 Mar 2015 21:52:46 +0530 Subject: [Freeipa-users] Adding a custom attribute to user object In-Reply-To: <551035FF.30404@redhat.com> References: <550FF6C3.1000400@redhat.com> <551035FF.30404@redhat.com> Message-ID: Hi Rob, Yes I did restart it. Ok another problem. I'm not able to add this attr to existing users. Only the new ones. Any pointers ? Thanks. --Prashant On 23 March 2015 at 21:19, Rob Crittenden wrote: > Prashant Bapat wrote: > > Ok the command you gave me worked. But I was following the PDF and below > > command never worked. > > > > ipa config-mod --addattr=ipaUserObjectClasses=ApigeeUserAttr > > > > Is that expected ? > > Did you restart httpd after adding the schema? A cached copy is used and > restarting will cause it to re-read the schema. > > rob > > > > > Thanks. > > --Prashant > > > > > > On 23 March 2015 at 17:37, Prashant Bapat > > wrote: > > > > Martin, > > > > Thanks! > > > > Let me double check. > > > > Yes I was referring to the exact same pdf. > > > > Regards. > > --Prashant > > > > On 23 March 2015 at 16:49, Martin Kosek > > wrote: > > > > On 03/23/2015 10:19 AM, Prashant Bapat wrote: > > > Hi, > > > > > > I'm trying to add a custom attribute to user object. Below is > > the ldif i'm > > > using. > > > > > > dn: cn=schema > > > changetype: modify > > > add: attributeTypes > > > attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME > > 'ipaSshSigTimestamp' > > > DESC 'SSH public key signature and timestamp' EQUALITY > > octetStringMatch > > > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM FREEIPA > > EXTENTION' ) > > > - > > > add: objectclasses > > > objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME > > 'ApigeeUserAttr' SUP > > > top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY > > ipaSshSigTimestamp ) > > > > > > This gets added successfully using the ldapmodify command as > > directory > > > manager. But both the UI and the ipa config-mod commands > > refuse to add the > > > new attribute to ipaUserObjectClasses with error objectclass > > not found. > > > > > > What I'm I doing wrong ? > > > > Not sure yet, the schema above looks OK (except some typos). I > > tried it on my > > VM, and it just worked: > > > > # ldapmodify -D "cn=Directory Manager" -x -w Secret123 > > ... > > modifying entry "cn=schema" > > > > # ipa config-mod > > > --userobjectclasses={ipaobject,person,top,ipasshuser,inetorgperson,organizationalperson,krbticketpolicyaux,krbprincipalaux,inetuser,posixaccount,ApigeeUserAttr} > > ... > > Default user objectclasses: ipaobject, person, top, ipasshuser, > > inetorgperson, organizationalperson, > > krbticketpolicyaux, > krbprincipalaux, > > ApigeeUserAttr, inetuser, > > posixaccount > > > > > > # ipa user-add apigee --first Foo --last Bar --setattr > > ipaSshSigTimestamp=barbar > > ------------------- > > Added user "apigee" > > ------------------- > > User login: apigee > > First name: Foo > > Last name: Bar > > Full name: Foo Bar > > Display name: Foo Bar > > Initials: FB > > Home directory: /home/apigee > > GECOS: Foo Bar > > Login shell: /bin/sh > > Kerberos principal: apigee at F21 > > Email address: apigee at f21.test > > UID: 1889400080 > > GID: 1889400080 > > Password: False > > Member of groups: ipausers > > Kerberos keys available: False > > > > > > # ldapsearch -Y GSSAPI -b > > 'uid=apigee,cn=users,cn=accounts,dc=f21' uid > > ipaSshSigTimestamp > > SASL/GSSAPI authentication started > > SASL username: admin at F21 > > SASL SSF: 56 > > SASL data security layer installed. > > # extended LDIF > > # > > # LDAPv3 > > # base with scope > subtree > > # filter: (objectclass=*) > > # requesting: uid ipaSshSigTimestamp > > # > > > > # apigee, users, accounts, f21 > > dn: uid=apigee,cn=users,cn=accounts,dc=f21 > > uid: apigee > > ipaSshSigTimestamp: barbar > > > > # search result > > search: 4 > > result: 0 Success > > > > # numResponses: 2 > > # numEntries: 1 > > > > > > > > BTW, did you read one of the very relevant upstream guides how > > to add custom > > attributes to LDAP? It pretty much covers the procedure you are > > working on: > > > > > http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > > > > Martin > > > > > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Mon Mar 23 16:27:59 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 23 Mar 2015 17:27:59 +0100 Subject: [Freeipa-users] Adding a custom attribute to user object In-Reply-To: References: <550FF6C3.1000400@redhat.com> <551035FF.30404@redhat.com> Message-ID: <55103F0F.6080105@redhat.com> You would need to extend user-mod to add this objectclass to existing modified users. There is an example of such plugin in the PDF I mentioned. On 03/23/2015 05:22 PM, Prashant Bapat wrote: > Hi Rob, > > Yes I did restart it. > > Ok another problem. I'm not able to add this attr to existing users. Only > the new ones. Any pointers ? > > Thanks. > --Prashant > > On 23 March 2015 at 21:19, Rob Crittenden wrote: > >> Prashant Bapat wrote: >>> Ok the command you gave me worked. But I was following the PDF and below >>> command never worked. >>> >>> ipa config-mod --addattr=ipaUserObjectClasses=ApigeeUserAttr >>> >>> Is that expected ? >> >> Did you restart httpd after adding the schema? A cached copy is used and >> restarting will cause it to re-read the schema. >> >> rob >> >>> >>> Thanks. >>> --Prashant >>> >>> >>> On 23 March 2015 at 17:37, Prashant Bapat >> > wrote: >>> >>> Martin, >>> >>> Thanks! >>> >>> Let me double check. >>> >>> Yes I was referring to the exact same pdf. >>> >>> Regards. >>> --Prashant >>> >>> On 23 March 2015 at 16:49, Martin Kosek >> > wrote: >>> >>> On 03/23/2015 10:19 AM, Prashant Bapat wrote: >>> > Hi, >>> > >>> > I'm trying to add a custom attribute to user object. Below is >>> the ldif i'm >>> > using. >>> > >>> > dn: cn=schema >>> > changetype: modify >>> > add: attributeTypes >>> > attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME >>> 'ipaSshSigTimestamp' >>> > DESC 'SSH public key signature and timestamp' EQUALITY >>> octetStringMatch >>> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM FREEIPA >>> EXTENTION' ) >>> > - >>> > add: objectclasses >>> > objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME >>> 'ApigeeUserAttr' SUP >>> > top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY >>> ipaSshSigTimestamp ) >>> > >>> > This gets added successfully using the ldapmodify command as >>> directory >>> > manager. But both the UI and the ipa config-mod commands >>> refuse to add the >>> > new attribute to ipaUserObjectClasses with error objectclass >>> not found. >>> > >>> > What I'm I doing wrong ? >>> >>> Not sure yet, the schema above looks OK (except some typos). I >>> tried it on my >>> VM, and it just worked: >>> >>> # ldapmodify -D "cn=Directory Manager" -x -w Secret123 >>> ... >>> modifying entry "cn=schema" >>> >>> # ipa config-mod >>> >> --userobjectclasses={ipaobject,person,top,ipasshuser,inetorgperson,organizationalperson,krbticketpolicyaux,krbprincipalaux,inetuser,posixaccount,ApigeeUserAttr} >>> ... >>> Default user objectclasses: ipaobject, person, top, ipasshuser, >>> inetorgperson, organizationalperson, >>> krbticketpolicyaux, >> krbprincipalaux, >>> ApigeeUserAttr, inetuser, >>> posixaccount >>> >>> >>> # ipa user-add apigee --first Foo --last Bar --setattr >>> ipaSshSigTimestamp=barbar >>> ------------------- >>> Added user "apigee" >>> ------------------- >>> User login: apigee >>> First name: Foo >>> Last name: Bar >>> Full name: Foo Bar >>> Display name: Foo Bar >>> Initials: FB >>> Home directory: /home/apigee >>> GECOS: Foo Bar >>> Login shell: /bin/sh >>> Kerberos principal: apigee at F21 >>> Email address: apigee at f21.test >>> UID: 1889400080 >>> GID: 1889400080 >>> Password: False >>> Member of groups: ipausers >>> Kerberos keys available: False >>> >>> >>> # ldapsearch -Y GSSAPI -b >>> 'uid=apigee,cn=users,cn=accounts,dc=f21' uid >>> ipaSshSigTimestamp >>> SASL/GSSAPI authentication started >>> SASL username: admin at F21 >>> SASL SSF: 56 >>> SASL data security layer installed. >>> # extended LDIF >>> # >>> # LDAPv3 >>> # base with scope >> subtree >>> # filter: (objectclass=*) >>> # requesting: uid ipaSshSigTimestamp >>> # >>> >>> # apigee, users, accounts, f21 >>> dn: uid=apigee,cn=users,cn=accounts,dc=f21 >>> uid: apigee >>> ipaSshSigTimestamp: barbar >>> >>> # search result >>> search: 4 >>> result: 0 Success >>> >>> # numResponses: 2 >>> # numEntries: 1 >>> >>> >>> >>> BTW, did you read one of the very relevant upstream guides how >>> to add custom >>> attributes to LDAP? It pretty much covers the procedure you are >>> working on: >>> >>> >> http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf >>> >>> Martin >>> >>> >>> >>> >>> >> >> > From mike at colovore.com Mon Mar 23 17:09:52 2015 From: mike at colovore.com (Michael Pawlak) Date: Mon, 23 Mar 2015 10:09:52 -0700 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: <550FF3E7.2090106@redhat.com> References: <550FF3E7.2090106@redhat.com> Message-ID: Martin, The CA service definitely appears to be up and selinux is disabled on the host. ----- ipactl status ----- Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING ----- service pki-cad status ----- pki-ca (pid 17719) is running... [ OK ] Unsecure Port = http://ipa.example.com:9180/ca/ee/ca Secure Agent Port = https://ipa.example.com:9443/ca/agent/ca Secure EE Port = https://ipa.example.com:9444/ca/ee/ca Secure Admin Port = https://ipa.example.com:9445/ca/services EE Client Auth Port = https://ipa.example.com:9446/ca/eeca/ca PKI Console Port = pkiconsole https://ipa.example.com:9445/ca Tomcat Port = 9701 (for shutdown) PKI Instance Name: pki-ca PKI Subsystem Type: CA Clone (Security Domain) Registered PKI Security Domain Information: ========================================================================== Name: IPA URL: https://ipa.example.com:443 ========================================================================== ----- cat /etc/selinux/config ----- # This file controls the state of SELinux on the system. # SELINUX= can take one of these three values: # enforcing - SELinux security policy is enforced. # permissive - SELinux prints warnings instead of enforcing. # disabled - SELinux is fully disabled. SELINUX=disabled # SELINUXTYPE= type of policy in use. Possible values are: # targeted - Only targeted network daemons are protected. # strict - Full SELinux protection. SELINUXTYPE=targeted On Mon, Mar 23, 2015 at 4:07 AM, Martin Kosek wrote: > This may mean that Dogtag is not up. Can you please check with "ipactl > status" > that it (pki-ca) is up and running and that there are no related SELinux > AVCs? > > On 03/23/2015 04:52 AM, Michael Pawlak wrote: > > Does anybody have any thoughts on this? > > > > *Michael Pawlak* > > Web Systems Administrator | Colovore LLC > > E: mike at colovore.com > > C: 408.316.2154 > > > > > > On Sun, Mar 22, 2015 at 12:05 AM, Michael Pawlak > wrote: > > > >> I am not able to setup a replica using the 'ipa-replica-prepare' > command. > >> After some debugging this appears related to the certmonger/dogtag > system > >> that is incorporated with FreeIPA. I am including the output below of > any > >> relevant logs / commands. > >> > >> ----- ipa-replica-prepare ----- > >> > >> ipa-replica-prepare newipa.example.com --ca=/etc/ipa/ca.crt --password > >> 'somepassword' > >> Preparing replica for newipa.example.com from ipa.example.com > >> Creating SSL certificate for the Directory Server > >> Certificate operation cannot be completed: Unable to communicate with > CMS > >> (Not Found) > >> > >> ----- ipa-getcert list ----- > >> > >> Number of certificates and requests being tracked: 8. > >> Request ID '20140811232518': > >> status: CA_UNREACHABLE > >> ca-error: Server at https://ipa.example.com/ipa/xml failed request, > >> will retry: 4301 (RPC failed at server. Certificate operation cannot be > >> completed: Unable to communicate with CMS (Not Found)). > >> 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 > >> subject: CN=ipa.example.com,O=EXAMPLE > >> expires: 2016-08-11 23:24:36 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 '20140811232742': > >> status: CA_UNREACHABLE > >> ca-error: Server at https://ipa.example.com/ipa/xml failed request, > >> will retry: 4301 (RPC failed at server. Certificate operation cannot be > >> completed: Unable to communicate with CMS (Not Found)). > >> stuck: no > >> key pair storage: > >> > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS > >> Certificate DB',pinfile='/etc/dirsrv/slapd-COLOVORE/pwdfile.txt' > >> certificate: > >> > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS > >> Certificate DB' > >> CA: IPA > >> issuer: CN=Certificate Authority,O=EXAMPLE > >> subject: CN=ipa.example.com,O=EXAMPLE > >> expires: 2016-08-11 23:24:34 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 '20140811232843': > >> status: CA_UNREACHABLE > >> ca-error: Server at https://ipa.example.com/ipa/xml failed request, > >> will retry: 4301 (RPC failed at server. Certificate operation cannot be > >> completed: Unable to communicate with CMS (Not Found)). > >> 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 > >> subject: CN=ipa.example.com,O=EXAMPLE > >> expires: 2016-08-11 23:24:37 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 > >> > >> ----- /etc/pki-ca/password.conf ----- > >> > >> internal=829325937546 > >> internaldb=somepassword > >> replicationdb=1270571739 > >> > >> ----- /var/log/pki-ca/debug ----- > >> > >> [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile > >> [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile > >> [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem id=selftests > >> [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init id=selftests > >> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): ENTERING . . . > >> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): loading self > >> test logger parameters > >> [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException > >> The self test plugin named selftests.container.logger.class contains a > >> value com.netscape.cms.logging.RollingLogFile which is invalid. > >> at > >> > com.netscape.cmscore.selftests.SelfTestSubsystem.init(SelfTestSubsystem.java:1422) > >> at > >> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:866) > >> at > >> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:795) > >> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:316) > >> at com.netscape.certsrv.apps.CMS.init(CMS.java:153) > >> at com.netscape.certsrv.apps.CMS.start(CMS.java:1530) > >> at > >> > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:85) > >> at > >> > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) > >> at > >> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) > >> at > >> > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4425) > >> at > >> > org.apache.catalina.core.StandardContext.start(StandardContext.java:4738) > >> at > >> > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) > >> at > >> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) > >> at > >> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) > >> at > >> > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) > >> at > >> > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) > >> at > >> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) > >> at > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) > >> at > >> > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) > >> at > >> > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) > >> at > >> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) > >> at > org.apache.catalina.core.StandardHost.start(StandardHost.java:722) > >> at > >> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) > >> at > >> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) > >> at > >> org.apache.catalina.core.StandardService.start(StandardService.java:516) > >> at > >> org.apache.catalina.core.StandardServer.start(StandardServer.java:710) > >> at org.apache.catalina.startup.Catalina.start(Catalina.java:593) > >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >> at > >> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > >> at > >> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >> at java.lang.reflect.Method.invoke(Method.java:606) > >> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) > >> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) > >> [22/Mar/2015:06:45:10][main]: CMSEngine.shutdown() > >> [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization > >> for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use > >> default authz mgr: {2}. > >> [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization > >> for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use > >> default authz mgr: {2}. > >> [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password > >> store initialized before. > >> [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): password > >> store initialized. > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: About to start > >> updateCertStatus > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting > updateCertStatus > >> (entered lock) > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In updateCertStatus() > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> LdapBoundConnFactory::getConn() > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >> getInvalidCertificatesByNotBeforeDate filter (certStatus=INVALID) > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >> getInvalidCertificatesByNotBeforeDate: about to call > findCertRecordsInList > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> LdapBoundConnFactory::getConn() > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > >> attrs startFrom sortKey pageSize filter: (certStatus=INVALID) attrs: > >> [objectclass, certRecordId, x509cert] pageSize -200 startFrom > >> 20150322065510Z > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 2 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> getInvalidCertsByNotBeforeDate finally. > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 3 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List > size: > >> 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: index may be empty > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> LdapBoundConnFactory::getConn() > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >> getValidCertsByNotAfterDate filter (certStatus=VALID) > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> LdapBoundConnFactory::getConn() > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > >> attrs startFrom sortKey pageSize filter: (certStatus=VALID) attrs: > >> [objectclass, certRecordId, x509cert] pageSize -200 startFrom > >> 20150322065510Z > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 2 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 3 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List > size: > >> 69 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > transidValidCertificates: > >> list size: 69 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > transitValidCertificates: > >> ltSize 1 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction > getting > >> index 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not > >> qualify,notAfter Sat Jul 09 05:12:31 UTC 2016 date Sun Mar 22 06:55:10 > UTC > >> 2015 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList EXPIRED > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> LdapBoundConnFactory::getConn() > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 2 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >> getRevokedCertificatesByNotAfterDate filter (certStatus=REVOKED) > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >> getRevokedCertificatesByNotAfterDate: about to call > findCertRecordsInList > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> LdapBoundConnFactory::getConn() > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is connected: > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >> true > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now 1 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > >> attrs startFrom sortKey pageSize filter: (certStatus=REVOKED) attrs: > >> [objectclass, certRevokedOn, certRecordId, certRevoInfo, notAfter, > >> x509cert] pageSize -200 startFrom 20150322065510Z > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 2 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 3 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List > size: > >> 5 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >> transitRevokedExpiredCertificates: list size: 5 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >> transitRevokedExpiredCertificates: ltSize 1 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction > getting > >> index 0 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitRevokedExpired: > >> curRec: 0 CertRecord: 268369925 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not > >> qualify,notAfter Wed Jul 20 06:25:57 UTC 2016 date Sun Mar 22 06:55:10 > UTC > >> 2015 > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList > >> REVOKED_EXPIRED > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: updateCertStatus done > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting cert > checkRanges > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely > >> started. Returning .. > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: cert checkRanges done > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting request > >> checkRanges > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely > >> started. Returning .. > >> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: request checkRanges done > >> > >> > > > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at colovore.com Mon Mar 23 17:10:46 2015 From: mike at colovore.com (Michael Pawlak) Date: Mon, 23 Mar 2015 10:10:46 -0700 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: <55101409.5000505@redhat.com> References: <550FF3E7.2090106@redhat.com> <55101409.5000505@redhat.com> Message-ID: Rob, Thanks. Any additional eyes would be greatly apprecated. *Michael Pawlak* Web Systems Administrator | Colovore LLC E: mike at colovore.com C: 408.316.2154 On Mon, Mar 23, 2015 at 6:24 AM, Rob Crittenden wrote: > Martin Kosek wrote: > > This may mean that Dogtag is not up. Can you please check with "ipactl > status" > > that it (pki-ca) is up and running and that there are no related SELinux > AVCs? > > > > The problem seems to be java-related: > > The self test plugin named selftests.container.logger.class contains a > value com.netscape.cms.logging.RollingLogFile which is invalid. > > I've seen cases where selftest failures don't cause the CA to not start > up but does prevent it from actually operating. > > The bottom line of the errors you are seeing is that the CA is not > completely running. I've cc'd a couple of dogtag developers to see if > they can help with the Java exception. > > rob > > > On 03/23/2015 04:52 AM, Michael Pawlak wrote: > >> Does anybody have any thoughts on this? > >> > >> *Michael Pawlak* > >> Web Systems Administrator | Colovore LLC > >> E: mike at colovore.com > >> C: 408.316.2154 > >> > >> > >> On Sun, Mar 22, 2015 at 12:05 AM, Michael Pawlak > wrote: > >> > >>> I am not able to setup a replica using the 'ipa-replica-prepare' > command. > >>> After some debugging this appears related to the certmonger/dogtag > system > >>> that is incorporated with FreeIPA. I am including the output below of > any > >>> relevant logs / commands. > >>> > >>> ----- ipa-replica-prepare ----- > >>> > >>> ipa-replica-prepare newipa.example.com --ca=/etc/ipa/ca.crt --password > >>> 'somepassword' > >>> Preparing replica for newipa.example.com from ipa.example.com > >>> Creating SSL certificate for the Directory Server > >>> Certificate operation cannot be completed: Unable to communicate with > CMS > >>> (Not Found) > >>> > >>> ----- ipa-getcert list ----- > >>> > >>> Number of certificates and requests being tracked: 8. > >>> Request ID '20140811232518': > >>> status: CA_UNREACHABLE > >>> ca-error: Server at https://ipa.example.com/ipa/xml failed > request, > >>> will retry: 4301 (RPC failed at server. Certificate operation cannot > be > >>> completed: Unable to communicate with CMS (Not Found)). > >>> 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 > >>> subject: CN=ipa.example.com,O=EXAMPLE > >>> expires: 2016-08-11 23:24:36 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 '20140811232742': > >>> status: CA_UNREACHABLE > >>> ca-error: Server at https://ipa.example.com/ipa/xml failed > request, > >>> will retry: 4301 (RPC failed at server. Certificate operation cannot > be > >>> completed: Unable to communicate with CMS (Not Found)). > >>> stuck: no > >>> key pair storage: > >>> > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS > >>> Certificate DB',pinfile='/etc/dirsrv/slapd-COLOVORE/pwdfile.txt' > >>> certificate: > >>> > type=NSSDB,location='/etc/dirsrv/slapd-EXAMPLE',nickname='Server-Cert',token='NSS > >>> Certificate DB' > >>> CA: IPA > >>> issuer: CN=Certificate Authority,O=EXAMPLE > >>> subject: CN=ipa.example.com,O=EXAMPLE > >>> expires: 2016-08-11 23:24:34 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 '20140811232843': > >>> status: CA_UNREACHABLE > >>> ca-error: Server at https://ipa.example.com/ipa/xml failed > request, > >>> will retry: 4301 (RPC failed at server. Certificate operation cannot > be > >>> completed: Unable to communicate with CMS (Not Found)). > >>> 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 > >>> subject: CN=ipa.example.com,O=EXAMPLE > >>> expires: 2016-08-11 23:24:37 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 > >>> > >>> ----- /etc/pki-ca/password.conf ----- > >>> > >>> internal=829325937546 > >>> internaldb=somepassword > >>> replicationdb=1270571739 > >>> > >>> ----- /var/log/pki-ca/debug ----- > >>> > >>> [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile > >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile > >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem id=selftests > >>> [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init id=selftests > >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): ENTERING . . > . > >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): loading > self > >>> test logger parameters > >>> [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException > >>> The self test plugin named selftests.container.logger.class contains a > >>> value com.netscape.cms.logging.RollingLogFile which is invalid. > >>> at > >>> > com.netscape.cmscore.selftests.SelfTestSubsystem.init(SelfTestSubsystem.java:1422) > >>> at > >>> com.netscape.cmscore.apps.CMSEngine.initSubsystem(CMSEngine.java:866) > >>> at > >>> com.netscape.cmscore.apps.CMSEngine.initSubsystems(CMSEngine.java:795) > >>> at com.netscape.cmscore.apps.CMSEngine.init(CMSEngine.java:316) > >>> at com.netscape.certsrv.apps.CMS.init(CMS.java:153) > >>> at com.netscape.certsrv.apps.CMS.start(CMS.java:1530) > >>> at > >>> > com.netscape.cms.servlet.base.CMSStartServlet.init(CMSStartServlet.java:85) > >>> at > >>> > org.apache.catalina.core.StandardWrapper.loadServlet(StandardWrapper.java:1173) > >>> at > >>> org.apache.catalina.core.StandardWrapper.load(StandardWrapper.java:993) > >>> at > >>> > org.apache.catalina.core.StandardContext.loadOnStartup(StandardContext.java:4425) > >>> at > >>> > org.apache.catalina.core.StandardContext.start(StandardContext.java:4738) > >>> at > >>> > org.apache.catalina.core.ContainerBase.addChildInternal(ContainerBase.java:791) > >>> at > >>> org.apache.catalina.core.ContainerBase.addChild(ContainerBase.java:771) > >>> at > >>> org.apache.catalina.core.StandardHost.addChild(StandardHost.java:526) > >>> at > >>> > org.apache.catalina.startup.HostConfig.deployDirectory(HostConfig.java:1041) > >>> at > >>> > org.apache.catalina.startup.HostConfig.deployDirectories(HostConfig.java:964) > >>> at > >>> org.apache.catalina.startup.HostConfig.deployApps(HostConfig.java:502) > >>> at > org.apache.catalina.startup.HostConfig.start(HostConfig.java:1277) > >>> at > >>> > org.apache.catalina.startup.HostConfig.lifecycleEvent(HostConfig.java:321) > >>> at > >>> > org.apache.catalina.util.LifecycleSupport.fireLifecycleEvent(LifecycleSupport.java:142) > >>> at > >>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1053) > >>> at > org.apache.catalina.core.StandardHost.start(StandardHost.java:722) > >>> at > >>> org.apache.catalina.core.ContainerBase.start(ContainerBase.java:1045) > >>> at > >>> org.apache.catalina.core.StandardEngine.start(StandardEngine.java:443) > >>> at > >>> > org.apache.catalina.core.StandardService.start(StandardService.java:516) > >>> at > >>> org.apache.catalina.core.StandardServer.start(StandardServer.java:710) > >>> at org.apache.catalina.startup.Catalina.start(Catalina.java:593) > >>> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > >>> at > >>> > sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) > >>> at > >>> > sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > >>> at java.lang.reflect.Method.invoke(Method.java:606) > >>> at org.apache.catalina.startup.Bootstrap.start(Bootstrap.java:289) > >>> at org.apache.catalina.startup.Bootstrap.main(Bootstrap.java:414) > >>> [22/Mar/2015:06:45:10][main]: CMSEngine.shutdown() > >>> [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization > >>> for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use > >>> default authz mgr: {2}. > >>> [22/Mar/2015:06:45:25][http-9444-1]: according to ccMode, authorization > >>> for servlet: caProfileSubmitSSLClient is LDAP based, not XML {1}, use > >>> default authz mgr: {2}. > >>> [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): > password > >>> store initialized before. > >>> [22/Mar/2015:06:50:09][Timer-0]: CMSEngine: getPasswordStore(): > password > >>> store initialized. > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: About to start > >>> updateCertStatus > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting > updateCertStatus > >>> (entered lock) > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In updateCertStatus() > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> LdapBoundConnFactory::getConn() > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is > connected: > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now > 2 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >>> getInvalidCertificatesByNotBeforeDate filter (certStatus=INVALID) > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >>> getInvalidCertificatesByNotBeforeDate: about to call > findCertRecordsInList > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> LdapBoundConnFactory::getConn() > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is > connected: > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now > 1 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > >>> attrs startFrom sortKey pageSize filter: (certStatus=INVALID) attrs: > >>> [objectclass, certRecordId, x509cert] pageSize -200 startFrom > >>> 20150322065510Z > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 2 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> getInvalidCertsByNotBeforeDate finally. > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 3 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List > size: > >>> 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: index may be empty > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> LdapBoundConnFactory::getConn() > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is > connected: > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now > 2 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >>> getValidCertsByNotAfterDate filter (certStatus=VALID) > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> LdapBoundConnFactory::getConn() > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is > connected: > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now > 1 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > >>> attrs startFrom sortKey pageSize filter: (certStatus=VALID) attrs: > >>> [objectclass, certRecordId, x509cert] pageSize -200 startFrom > >>> 20150322065510Z > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 2 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 3 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List > size: > >>> 69 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > transidValidCertificates: > >>> list size: 69 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > transitValidCertificates: > >>> ltSize 1 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction > getting > >>> index 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not > >>> qualify,notAfter Sat Jul 09 05:12:31 UTC 2016 date Sun Mar 22 06:55:10 > UTC > >>> 2015 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList EXPIRED > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> LdapBoundConnFactory::getConn() > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is > connected: > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now > 2 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >>> getRevokedCertificatesByNotAfterDate filter (certStatus=REVOKED) > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >>> getRevokedCertificatesByNotAfterDate: about to call > findCertRecordsInList > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> LdapBoundConnFactory::getConn() > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: masterConn is > connected: > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: conn is > connected > >>> true > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getConn: mNumConns now > 1 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In > >>> findCertRecordsInListRawJumpto with Jumpto 20150322065510Z > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: In DBVirtualList filter > >>> attrs startFrom sortKey pageSize filter: (certStatus=REVOKED) attrs: > >>> [objectclass, certRevokedOn, certRecordId, certRevoInfo, notAfter, > >>> x509cert] pageSize -200 startFrom 20150322065510Z > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 2 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: returnConn: mNumConns > now 3 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getEntries returning 1 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: mTop 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Getting Virtual List > size: > >>> 5 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >>> transitRevokedExpiredCertificates: list size: 5 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: > >>> transitRevokedExpiredCertificates: ltSize 1 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: getElementAt: 0 mTop 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: reverse direction > getting > >>> index 0 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitRevokedExpired: > >>> curRec: 0 CertRecord: 268369925 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Record does not > >>> qualify,notAfter Wed Jul 20 06:25:57 UTC 2016 date Sun Mar 22 06:55:10 > UTC > >>> 2015 > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: transitCertList > >>> REVOKED_EXPIRED > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: updateCertStatus done > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting cert > checkRanges > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely > >>> started. Returning .. > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: cert checkRanges done > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Starting request > >>> checkRanges > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: Server not completely > >>> started. Returning .. > >>> [22/Mar/2015:06:55:10][CertStatusUpdateThread]: request checkRanges > done > >>> > >>> > >> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From prashant at apigee.com Mon Mar 23 17:14:21 2015 From: prashant at apigee.com (Prashant Bapat) Date: Mon, 23 Mar 2015 22:44:21 +0530 Subject: [Freeipa-users] Adding a custom attribute to user object In-Reply-To: <55103F0F.6080105@redhat.com> References: <550FF6C3.1000400@redhat.com> <551035FF.30404@redhat.com> <55103F0F.6080105@redhat.com> Message-ID: ?Thanks. I will take a look. However will using this attr only on new users from the time it was added have any issues ? Also, will replication include this new attr ?? On 23 March 2015 at 21:57, Martin Kosek wrote: > You would need to extend user-mod to add this objectclass to existing > modified > users. There is an example of such plugin in the PDF I mentioned. > > On 03/23/2015 05:22 PM, Prashant Bapat wrote: > > Hi Rob, > > > > Yes I did restart it. > > > > Ok another problem. I'm not able to add this attr to existing users. Only > > the new ones. Any pointers ? > > > > Thanks. > > --Prashant > > > > On 23 March 2015 at 21:19, Rob Crittenden wrote: > > > >> Prashant Bapat wrote: > >>> Ok the command you gave me worked. But I was following the PDF and > below > >>> command never worked. > >>> > >>> ipa config-mod --addattr=ipaUserObjectClasses=ApigeeUserAttr > >>> > >>> Is that expected ? > >> > >> Did you restart httpd after adding the schema? A cached copy is used and > >> restarting will cause it to re-read the schema. > >> > >> rob > >> > >>> > >>> Thanks. > >>> --Prashant > >>> > >>> > >>> On 23 March 2015 at 17:37, Prashant Bapat >>> > wrote: > >>> > >>> Martin, > >>> > >>> Thanks! > >>> > >>> Let me double check. > >>> > >>> Yes I was referring to the exact same pdf. > >>> > >>> Regards. > >>> --Prashant > >>> > >>> On 23 March 2015 at 16:49, Martin Kosek >>> > wrote: > >>> > >>> On 03/23/2015 10:19 AM, Prashant Bapat wrote: > >>> > Hi, > >>> > > >>> > I'm trying to add a custom attribute to user object. Below is > >>> the ldif i'm > >>> > using. > >>> > > >>> > dn: cn=schema > >>> > changetype: modify > >>> > add: attributeTypes > >>> > attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME > >>> 'ipaSshSigTimestamp' > >>> > DESC 'SSH public key signature and timestamp' EQUALITY > >>> octetStringMatch > >>> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM FREEIPA > >>> EXTENTION' ) > >>> > - > >>> > add: objectclasses > >>> > objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME > >>> 'ApigeeUserAttr' SUP > >>> > top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY > >>> ipaSshSigTimestamp ) > >>> > > >>> > This gets added successfully using the ldapmodify command as > >>> directory > >>> > manager. But both the UI and the ipa config-mod commands > >>> refuse to add the > >>> > new attribute to ipaUserObjectClasses with error objectclass > >>> not found. > >>> > > >>> > What I'm I doing wrong ? > >>> > >>> Not sure yet, the schema above looks OK (except some typos). I > >>> tried it on my > >>> VM, and it just worked: > >>> > >>> # ldapmodify -D "cn=Directory Manager" -x -w Secret123 > >>> ... > >>> modifying entry "cn=schema" > >>> > >>> # ipa config-mod > >>> > >> > --userobjectclasses={ipaobject,person,top,ipasshuser,inetorgperson,organizationalperson,krbticketpolicyaux,krbprincipalaux,inetuser,posixaccount,ApigeeUserAttr} > >>> ... > >>> Default user objectclasses: ipaobject, person, top, > ipasshuser, > >>> inetorgperson, organizationalperson, > >>> krbticketpolicyaux, > >> krbprincipalaux, > >>> ApigeeUserAttr, inetuser, > >>> posixaccount > >>> > >>> > >>> # ipa user-add apigee --first Foo --last Bar --setattr > >>> ipaSshSigTimestamp=barbar > >>> ------------------- > >>> Added user "apigee" > >>> ------------------- > >>> User login: apigee > >>> First name: Foo > >>> Last name: Bar > >>> Full name: Foo Bar > >>> Display name: Foo Bar > >>> Initials: FB > >>> Home directory: /home/apigee > >>> GECOS: Foo Bar > >>> Login shell: /bin/sh > >>> Kerberos principal: apigee at F21 > >>> Email address: apigee at f21.test > >>> UID: 1889400080 > >>> GID: 1889400080 > >>> Password: False > >>> Member of groups: ipausers > >>> Kerberos keys available: False > >>> > >>> > >>> # ldapsearch -Y GSSAPI -b > >>> 'uid=apigee,cn=users,cn=accounts,dc=f21' uid > >>> ipaSshSigTimestamp > >>> SASL/GSSAPI authentication started > >>> SASL username: admin at F21 > >>> SASL SSF: 56 > >>> SASL data security layer installed. > >>> # extended LDIF > >>> # > >>> # LDAPv3 > >>> # base with scope > >> subtree > >>> # filter: (objectclass=*) > >>> # requesting: uid ipaSshSigTimestamp > >>> # > >>> > >>> # apigee, users, accounts, f21 > >>> dn: uid=apigee,cn=users,cn=accounts,dc=f21 > >>> uid: apigee > >>> ipaSshSigTimestamp: barbar > >>> > >>> # search result > >>> search: 4 > >>> result: 0 Success > >>> > >>> # numResponses: 2 > >>> # numEntries: 1 > >>> > >>> > >>> > >>> BTW, did you read one of the very relevant upstream guides how > >>> to add custom > >>> attributes to LDAP? It pretty much covers the procedure you are > >>> working on: > >>> > >>> > >> http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > >>> > >>> Martin > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Mon Mar 23 17:21:36 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 23 Mar 2015 13:21:36 -0400 Subject: [Freeipa-users] Adding a custom attribute to user object In-Reply-To: References: <550FF6C3.1000400@redhat.com> <551035FF.30404@redhat.com> <55103F0F.6080105@redhat.com> Message-ID: <55104BA0.9010102@redhat.com> Prashant Bapat wrote: > ?Thanks. I will take a look. However will using this attr only on new > users from the time it was added have any issues ? Shouldn't cause any problems with IPA. > Also, will replication include this new attr ?? Yes. Schema is replicated as well. rob > > On 23 March 2015 at 21:57, Martin Kosek > wrote: > > You would need to extend user-mod to add this objectclass to > existing modified > users. There is an example of such plugin in the PDF I mentioned. > > On 03/23/2015 05:22 PM, Prashant Bapat wrote: > > Hi Rob, > > > > Yes I did restart it. > > > > Ok another problem. I'm not able to add this attr to existing > users. Only > > the new ones. Any pointers ? > > > > Thanks. > > --Prashant > > > > On 23 March 2015 at 21:19, Rob Crittenden > wrote: > > > >> Prashant Bapat wrote: > >>> Ok the command you gave me worked. But I was following the PDF > and below > >>> command never worked. > >>> > >>> ipa config-mod --addattr=ipaUserObjectClasses=ApigeeUserAttr > >>> > >>> Is that expected ? > >> > >> Did you restart httpd after adding the schema? A cached copy is > used and > >> restarting will cause it to re-read the schema. > >> > >> rob > >> > >>> > >>> Thanks. > >>> --Prashant > >>> > >>> > >>> On 23 March 2015 at 17:37, Prashant Bapat > >>> >> wrote: > >>> > >>> Martin, > >>> > >>> Thanks! > >>> > >>> Let me double check. > >>> > >>> Yes I was referring to the exact same pdf. > >>> > >>> Regards. > >>> --Prashant > >>> > >>> On 23 March 2015 at 16:49, Martin Kosek > >>> >> wrote: > >>> > >>> On 03/23/2015 10:19 AM, Prashant Bapat wrote: > >>> > Hi, > >>> > > >>> > I'm trying to add a custom attribute to user object. > Below is > >>> the ldif i'm > >>> > using. > >>> > > >>> > dn: cn=schema > >>> > changetype: modify > >>> > add: attributeTypes > >>> > attributeTypes: (2.16.840.1.113730.3.8.11.31.1 NAME > >>> 'ipaSshSigTimestamp' > >>> > DESC 'SSH public key signature and timestamp' EQUALITY > >>> octetStringMatch > >>> > SYNTAX 1.3.6.1.4.1.1466.115.121.1.40 X-ORIGIN 'CUSTOM > FREEIPA > >>> EXTENTION' ) > >>> > - > >>> > add: objectclasses > >>> > objectclasses: ( 2.16.840.1.113730.3.8.11.31.2 NAME > >>> 'ApigeeUserAttr' SUP > >>> > top AUXILIARY DESC 'CUSTOM FREEIPA EXTENTION' MAY > >>> ipaSshSigTimestamp ) > >>> > > >>> > This gets added successfully using the ldapmodify > command as > >>> directory > >>> > manager. But both the UI and the ipa config-mod commands > >>> refuse to add the > >>> > new attribute to ipaUserObjectClasses with error > objectclass > >>> not found. > >>> > > >>> > What I'm I doing wrong ? > >>> > >>> Not sure yet, the schema above looks OK (except some > typos). I > >>> tried it on my > >>> VM, and it just worked: > >>> > >>> # ldapmodify -D "cn=Directory Manager" -x -w Secret123 > >>> ... > >>> modifying entry "cn=schema" > >>> > >>> # ipa config-mod > >>> > >> > --userobjectclasses={ipaobject,person,top,ipasshuser,inetorgperson,organizationalperson,krbticketpolicyaux,krbprincipalaux,inetuser,posixaccount,ApigeeUserAttr} > >>> ... > >>> Default user objectclasses: ipaobject, person, top, > ipasshuser, > >>> inetorgperson, organizationalperson, > >>> krbticketpolicyaux, > >> krbprincipalaux, > >>> ApigeeUserAttr, inetuser, > >>> posixaccount > >>> > >>> > >>> # ipa user-add apigee --first Foo --last Bar --setattr > >>> ipaSshSigTimestamp=barbar > >>> ------------------- > >>> Added user "apigee" > >>> ------------------- > >>> User login: apigee > >>> First name: Foo > >>> Last name: Bar > >>> Full name: Foo Bar > >>> Display name: Foo Bar > >>> Initials: FB > >>> Home directory: /home/apigee > >>> GECOS: Foo Bar > >>> Login shell: /bin/sh > >>> Kerberos principal: apigee at F21 > >>> Email address: apigee at f21.test > >>> UID: 1889400080 > >>> GID: 1889400080 > >>> Password: False > >>> Member of groups: ipausers > >>> Kerberos keys available: False > >>> > >>> > >>> # ldapsearch -Y GSSAPI -b > >>> 'uid=apigee,cn=users,cn=accounts,dc=f21' uid > >>> ipaSshSigTimestamp > >>> SASL/GSSAPI authentication started > >>> SASL username: admin at F21 > >>> SASL SSF: 56 > >>> SASL data security layer installed. > >>> # extended LDIF > >>> # > >>> # LDAPv3 > >>> # base with scope > >> subtree > >>> # filter: (objectclass=*) > >>> # requesting: uid ipaSshSigTimestamp > >>> # > >>> > >>> # apigee, users, accounts, f21 > >>> dn: uid=apigee,cn=users,cn=accounts,dc=f21 > >>> uid: apigee > >>> ipaSshSigTimestamp: barbar > >>> > >>> # search result > >>> search: 4 > >>> result: 0 Success > >>> > >>> # numResponses: 2 > >>> # numEntries: 1 > >>> > >>> > >>> > >>> BTW, did you read one of the very relevant upstream > guides how > >>> to add custom > >>> attributes to LDAP? It pretty much covers the procedure > you are > >>> working on: > >>> > >>> > >> http://www.freeipa.org/images/5/5b/FreeIPA33-extending-freeipa.pdf > >>> > >>> Martin > >>> > >>> > >>> > >>> > >>> > >> > >> > > > > From edewata at redhat.com Mon Mar 23 19:14:20 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 23 Mar 2015 14:14:20 -0500 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: References: <550FF3E7.2090106@redhat.com> <55101409.5000505@redhat.com> Message-ID: <5510660C.5020709@redhat.com> On 3/23/2015 12:10 PM, Michael Pawlak wrote: > Rob, > > Thanks. Any additional eyes would be greatly apprecated. > > *Michael Pawlak* > Web Systems Administrator | Colovore LLC > E: mike at colovore.com > C: 408.316.2154 > > > On Mon, Mar 23, 2015 at 6:24 AM, Rob Crittenden > wrote: > > Martin Kosek wrote: > > This may mean that Dogtag is not up. Can you please check with > "ipactl status" > > that it (pki-ca) is up and running and that there are no related > SELinux AVCs? > > > > The problem seems to be java-related: > > The self test plugin named selftests.container.logger.class contains a > value com.netscape.cms.logging.RollingLogFile which is invalid. > > I've seen cases where selftest failures don't cause the CA to not start > up but does prevent it from actually operating. > > The bottom line of the errors you are seeing is that the CA is not > completely running. I've cc'd a couple of dogtag developers to see if > they can help with the Java exception. > > rob > > > On 03/23/2015 04:52 AM, Michael Pawlak wrote: > >>> ----- /var/log/pki-ca/debug ----- > >>> > >>> [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile > >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile > >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem id=selftests > >>> [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init id=selftests > >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): > ENTERING . . . > >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): > loading self > >>> test logger parameters > >>> [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException > >>> The self test plugin named selftests.container.logger.class > contains a > >>> value com.netscape.cms.logging.RollingLogFile which is invalid. > >>> at > >>> > com.netscape.cmscore.selftests.SelfTestSubsystem.init(SelfTestSubsystem.java:1422) > >>> at > >>> Hi, Unfortunately the code doesn't log the exact cause of the problem. I need some additional info: 1. Which platform are you using? 2. What are the versions of the pki-* packages before and after upgrade? 3. Please provide the /etc/pki-ca/CS.cfg and /var/log/pki-ca/transactions. Thanks. -- Endi S. Dewata From edewata at redhat.com Mon Mar 23 19:21:09 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 23 Mar 2015 14:21:09 -0500 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: <54F5C301.60604@redhat.com> References: <54F1360B.2080807@redhat.com> <54F5C301.60604@redhat.com> Message-ID: <551067A5.60002@redhat.com> On 3/3/2015 8:19 AM, Endi Sukma Dewata wrote: > On 2/28/2015 1:01 PM, Hadoop Solutions wrote: >> Hi Rob, >> >> please find the attached log of /var/log/ipaserver-install.log >> >> kindly let me know the solution for this.. >> >> Thanks, >> Shaik > > Hi, > > I see this near the bottom of the ipaserver-install.log. > > ############################################# > Attempting to connect to: sv2lxdpdsedi02.corp.equinix.com:9445 > Connected. > Posting Query = > https://sv2lxdpdsedi02.corp.equinix.com:9445//ca/admin/console/config/wizard?p=9&op=next&xml=true&host=sv2lxdpdsedi02.corp.equinix.com&port=7389&binddn=cn%3DDirectory+Manager&__bindpwd=XXXXXXXX&basedn=o%3Dipaca&database=ipaca&display=%24displayStr > > RESPONSE STATUS: HTTP/1.1 404 Not Found > RESPONSE HEADER: Server: Apache-Coyote/1.1 > RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 > RESPONSE HEADER: Date: Sat, 28 Feb 2015 05:57:35 GMT > RESPONSE HEADER: Connection: close > ERROR: unable to parse xml > ERROR XML = > ERROR: Tag='updateStatus' has no values > Error in LdapConnectionPanel(): updateStatus value is null > ERROR: ConfigureCA: LdapConnectionPanel() failure > ERROR: unable to create CA > > ####################################################################### > > 2015-02-28T05:57:35Z DEBUG stderr=[Fatal Error] :-1:-1: Premature end of > file. > org.xml.sax.SAXParseException: Premature end of file. > at org.apache.xerces.parsers.DOMParser.parse(xerces-j2-2.7.1.jar.so) > at > org.apache.xerces.jaxp.DocumentBuilderImpl.parse(xerces-j2-2.7.1.jar.so) > at javax.xml.parsers.DocumentBuilder.parse(libgcj.so.10) > at ParseXML.parse(ParseXML.java:258) > at ConfigureCA.getStatus(ConfigureCA.java:205) > at ConfigureCA.checkStatus(ConfigureCA.java:221) > at ConfigureCA.checkStatus(ConfigureCA.java:216) > at ConfigureCA.LdapConnectionPanel(ConfigureCA.java:510) > at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1225) > at ConfigureCA.main(ConfigureCA.java:1672) > > Could you post the /var/log/pki-ca/debug? Thanks. > Hi, if this is still a problem please let me know. Thanks. -- Endi S. Dewata From mike at colovore.com Mon Mar 23 19:47:03 2015 From: mike at colovore.com (Michael Pawlak) Date: Mon, 23 Mar 2015 12:47:03 -0700 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: <5510660C.5020709@redhat.com> References: <550FF3E7.2090106@redhat.com> <55101409.5000505@redhat.com> <5510660C.5020709@redhat.com> Message-ID: Endi, 1. I am currently using CentOS 6.5. 2. Below are the package versions. Former: Don't have that information available Current: pki-java-tools-9.0.3-38.el6_6.noarch pki-silent-9.0.3-38.el6_6.noarch ipa-pki-common-theme-9.0.3-7.el6.noarch pki-ca-9.0.3-38.el6_6.noarch pki-setup-9.0.3-38.el6_6.noarch pki-native-tools-9.0.3-38.el6_6.x86_64 pki-util-9.0.3-38.el6_6.noarch pki-selinux-9.0.3-38.el6_6.noarch pki-common-9.0.3-38.el6_6.noarch ipa-pki-ca-theme-9.0.3-7.el6.noarch pki-symkey-9.0.3-38.el6_6.x86_64 3. Attached *Michael Pawlak* Web Systems Administrator | Colovore LLC E: mike at colovore.com C: 408.316.2154 On Mon, Mar 23, 2015 at 12:14 PM, Endi Sukma Dewata wrote: > On 3/23/2015 12:10 PM, Michael Pawlak wrote: > >> Rob, >> >> Thanks. Any additional eyes would be greatly apprecated. >> >> *Michael Pawlak* >> Web Systems Administrator | Colovore LLC >> E: mike at colovore.com >> C: 408.316.2154 >> >> >> On Mon, Mar 23, 2015 at 6:24 AM, Rob Crittenden > > wrote: >> >> Martin Kosek wrote: >> > This may mean that Dogtag is not up. Can you please check with >> "ipactl status" >> > that it (pki-ca) is up and running and that there are no related >> SELinux AVCs? >> > >> >> The problem seems to be java-related: >> >> The self test plugin named selftests.container.logger.class contains >> a >> value com.netscape.cms.logging.RollingLogFile which is invalid. >> >> I've seen cases where selftest failures don't cause the CA to not >> start >> up but does prevent it from actually operating. >> >> The bottom line of the errors you are seeing is that the CA is not >> completely running. I've cc'd a couple of dogtag developers to see if >> they can help with the Java exception. >> >> rob >> >> > On 03/23/2015 04:52 AM, Michael Pawlak wrote: >> >>> ----- /var/log/pki-ca/debug ----- >> >>> >> >>> [22/Mar/2015:06:45:10][main]: CMSEngine: done init id=profile >> >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initialized profile >> >>> [22/Mar/2015:06:45:10][main]: CMSEngine: initSubsystem >> id=selftests >> >>> [22/Mar/2015:06:45:10][main]: CMSEngine: ready to init >> id=selftests >> >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): >> ENTERING . . . >> >>> [22/Mar/2015:06:45:10][main]: SelfTestSubsystem::init(): >> loading self >> >>> test logger parameters >> >>> [22/Mar/2015:06:45:10][main]: CMS:Caught EBaseException >> >>> The self test plugin named selftests.container.logger.class >> contains a >> >>> value com.netscape.cms.logging.RollingLogFile which is invalid. >> >>> at >> >>> >> com.netscape.cmscore.selftests.SelfTestSubsystem. >> init(SelfTestSubsystem.java:1422) >> >>> at >> >>> >> > > Hi, > > Unfortunately the code doesn't log the exact cause of the problem. I need > some additional info: > > 1. Which platform are you using? > 2. What are the versions of the pki-* packages before and after upgrade? > 3. Please provide the /etc/pki-ca/CS.cfg and /var/log/pki-ca/transactions. > > Thanks. > > -- > Endi S. Dewata > -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: transactions Type: application/octet-stream Size: 21864 bytes Desc: not available URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: CS.cfg Type: application/octet-stream Size: 77818 bytes Desc: not available URL: From edewata at redhat.com Mon Mar 23 20:36:48 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Mon, 23 Mar 2015 16:36:48 -0400 (EDT) Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: References: <550FF3E7.2090106@redhat.com> <55101409.5000505@redhat.com> <5510660C.5020709@redhat.com> Message-ID: <107823642.2856345.1427143008792.JavaMail.zimbra@redhat.com> Thanks for the info. The transaction log doesn't indicate the cause of the problem either. I might need to provide a custom build that generates more useful information. Would you be able to test that? Thanks. -- Endi S. Dewata ----- Original Message ----- > Endi, > > 1. I am currently using CentOS 6.5. > > 2. Below are the package versions. > > Former: > Don't have that information available > > Current: > pki-java-tools-9.0.3-38.el6_6.noarch > pki-silent-9.0.3-38.el6_6.noarch > ipa-pki-common-theme-9.0.3-7.el6.noarch > pki-ca-9.0.3-38.el6_6.noarch > pki-setup-9.0.3-38.el6_6.noarch > pki-native-tools-9.0.3-38.el6_6.x86_64 > pki-util-9.0.3-38.el6_6.noarch > pki-selinux-9.0.3-38.el6_6.noarch > pki-common-9.0.3-38.el6_6.noarch > ipa-pki-ca-theme-9.0.3-7.el6.noarch > pki-symkey-9.0.3-38.el6_6.x86_64 > > 3. Attached > > *Michael Pawlak* > Web Systems Administrator | Colovore LLC > E: mike at colovore.com > C: 408.316.2154 > > > On Mon, Mar 23, 2015 at 12:14 PM, Endi Sukma Dewata > wrote: > > > > Hi, > > > > Unfortunately the code doesn't log the exact cause of the problem. I need > > some additional info: > > > > 1. Which platform are you using? > > 2. What are the versions of the pki-* packages before and after upgrade? > > 3. Please provide the /etc/pki-ca/CS.cfg and /var/log/pki-ca/transactions. > > > > Thanks. > > > > -- > > Endi S. Dewata From matt.wells at mosaic451.com Mon Mar 23 21:13:12 2015 From: matt.wells at mosaic451.com (Matt Wells) Date: Mon, 23 Mar 2015 14:13:12 -0700 Subject: [Freeipa-users] Chained IPA Servers Message-ID: We have two authentication domains; both on 4.X. Domain 1 - Internal and contains our employee accounts Domain 2 - External accounts that reside outside of our company. These accounts are utilized to gain access to some of our web resources. Is their a method to point our older app at "domain 2" IPA servers and forward on to internal if not found? As always, thanks to all who monitor and read this list. One of the best. From mike at colovore.com Mon Mar 23 21:55:44 2015 From: mike at colovore.com (Michael Pawlak) Date: Mon, 23 Mar 2015 14:55:44 -0700 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: <107823642.2856345.1427143008792.JavaMail.zimbra@redhat.com> References: <550FF3E7.2090106@redhat.com> <55101409.5000505@redhat.com> <5510660C.5020709@redhat.com> <107823642.2856345.1427143008792.JavaMail.zimbra@redhat.com> Message-ID: Endi, I could test that. *Michael Pawlak* Web Systems Administrator | Colovore LLC E: mike at colovore.com C: 408.316.2154 On Mon, Mar 23, 2015 at 1:36 PM, Endi Sukma Dewata wrote: > Thanks for the info. The transaction log doesn't indicate the cause of the > problem either. I might need to provide a custom build that generates more > useful information. Would you be able to test that? Thanks. > > -- > Endi S. Dewata > > ----- Original Message ----- > > Endi, > > > > 1. I am currently using CentOS 6.5. > > > > 2. Below are the package versions. > > > > Former: > > Don't have that information available > > > > Current: > > pki-java-tools-9.0.3-38.el6_6.noarch > > pki-silent-9.0.3-38.el6_6.noarch > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > pki-ca-9.0.3-38.el6_6.noarch > > pki-setup-9.0.3-38.el6_6.noarch > > pki-native-tools-9.0.3-38.el6_6.x86_64 > > pki-util-9.0.3-38.el6_6.noarch > > pki-selinux-9.0.3-38.el6_6.noarch > > pki-common-9.0.3-38.el6_6.noarch > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > pki-symkey-9.0.3-38.el6_6.x86_64 > > > > 3. Attached > > > > *Michael Pawlak* > > Web Systems Administrator | Colovore LLC > > E: mike at colovore.com > > C: 408.316.2154 > > > > > > On Mon, Mar 23, 2015 at 12:14 PM, Endi Sukma Dewata > > wrote: > > > > > > Hi, > > > > > > Unfortunately the code doesn't log the exact cause of the problem. I > need > > > some additional info: > > > > > > 1. Which platform are you using? > > > 2. What are the versions of the pki-* packages before and after > upgrade? > > > 3. Please provide the /etc/pki-ca/CS.cfg and > /var/log/pki-ca/transactions. > > > > > > Thanks. > > > > > > -- > > > Endi S. Dewata > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at thetimmy.com Mon Mar 23 21:56:38 2015 From: lists at thetimmy.com (Timothy Worman) Date: Mon, 23 Mar 2015 14:56:38 -0700 Subject: [Freeipa-users] inserting users via java Message-ID: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> I have an existing web app built with java/WebObjects that currently handles some user/groups tasks with our current directory server (Open Directory). We are investigating a move to FreeIPA for our directory services. Just in mucking around, I?ve found that if I try to insert a new user (inetOrgPerson) into into IPA?s implementation, the new user does not inherit all the object classes it should. It only inherits the ones leading to inetOrgPerson. This does result in a successful inetOrgPerson insertion, but that user record does not show up in the Web GUI management tools. Usually, I have focused on inetOrgPerson because that is where the bulk of the info about a user lives. We have a SQL database that contains people in our organization (used by other services), so, we need to be able to leverage that and push users into IPA when appropriate and we have an existing app to do this. Tim W From nathan at nathanpeters.com Mon Mar 23 23:09:08 2015 From: nathan at nathanpeters.com (nathan at nathanpeters.com) Date: Mon, 23 Mar 2015 16:09:08 -0700 Subject: [Freeipa-users] Certificate and key problems in Linux In-Reply-To: <20150322194423.GB9374@Jakubs-MacBook-Pro.local> References: <428b2348ab216151ac44120c84469b1e.squirrel@webmail.nathanpeters.com> <550C8FFC.4060102@redhat.com> <5fe92a2cd252072f537a863d564dc1e8.squirrel@webmail.nathanpeters.com> <550CB099.5090105@redhat.com> <550CBC0E.30901@redhat.com> <20150322194423.GB9374@Jakubs-MacBook-Pro.local> Message-ID: <13f0505d157c16bbc3c585c5b4ecd2d4.squirrel@webmail.nathanpeters.com> > Thanks for CC-ing me Dmitri, I only monitor freeipa-users based on > subjects and didn't realize this thread was about SSSD. > > I didn't reproduce the problem myself yet, but I checked the sources and > I think it's a bug, much like one in the autofs responder we've had some > time ago. Please open a bug upstream or in RHBZ, we need to track this > problem. > > Thanks! > > -- > 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 > Here is the bug report I submitted. I hope I did that in the right place. https://fedorahosted.org/sssd/ticket/2609 From dpal at redhat.com Tue Mar 24 00:23:00 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 23 Mar 2015 20:23:00 -0400 Subject: [Freeipa-users] Chained IPA Servers In-Reply-To: References: Message-ID: <5510AE64.7050900@redhat.com> On 03/23/2015 05:13 PM, Matt Wells wrote: > We have two authentication domains; both on 4.X. > > Domain 1 - Internal and contains our employee accounts > Domain 2 - External accounts that reside outside of our company. > These accounts are utilized to gain access to some of our web > resources. > > Is their a method to point our older app at "domain 2" IPA servers and > forward on to internal if not found? > As always, thanks to all who monitor and read this list. One of the best. > Can you please be a bit more specific. You have an app that is currently pointing to external servers. How does it point to them? Using LDAP or some other way? What kind of app it is? Can you modify it or it is a stock software? Forward to the internal "if not found" what? User? So you want for app to be able to access users from both domains effectively, right? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue Mar 24 00:29:14 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 23 Mar 2015 20:29:14 -0400 Subject: [Freeipa-users] inserting users via java In-Reply-To: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> Message-ID: <5510AFDA.2020602@redhat.com> On 03/23/2015 05:56 PM, Timothy Worman wrote: > I have an existing web app built with java/WebObjects that currently handles some user/groups tasks with our current directory server (Open Directory). We are investigating a move to FreeIPA for our directory services. > > Just in mucking around, I?ve found that if I try to insert a new user (inetOrgPerson) into into IPA?s implementation, the new user does not inherit all the object classes it should. It only inherits the ones leading to inetOrgPerson. This does result in a successful inetOrgPerson insertion, but that user record does not show up in the Web GUI management tools. > > Usually, I have focused on inetOrgPerson because that is where the bulk of the info about a user lives. > > We have a SQL database that contains people in our organization (used by other services), so, we need to be able to leverage that and push users into IPA when appropriate and we have an existing app to do this. > > Tim W > You have several options: 1) Call ipa CLI from your application - this is possible right now (but not quite nice) 2) Call ipa JSON API from your application - this is not supported but possible. We use python API. You can do it in Java but it will be a lot of work. 3) Use more elaborate LDAP add commands (with all the object classes needed for users). Hard, but doable. 4) Help us with testing the upcoming feature http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow creating users via simple ldap command in a staging area and them moving them to normal users area with automatic creation of missing attributes by means of a cron job. I would vote for 1) as a temp solution and 4) as a longer term one. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jhrozek at redhat.com Tue Mar 24 07:25:32 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Mar 2015 08:25:32 +0100 Subject: [Freeipa-users] Chained IPA Servers In-Reply-To: <5510AE64.7050900@redhat.com> References: <5510AE64.7050900@redhat.com> Message-ID: <20150324072532.GD2989@hendrix.redhat.com> On Mon, Mar 23, 2015 at 08:23:00PM -0400, Dmitri Pal wrote: > On 03/23/2015 05:13 PM, Matt Wells wrote: > >We have two authentication domains; both on 4.X. > > > >Domain 1 - Internal and contains our employee accounts > >Domain 2 - External accounts that reside outside of our company. > >These accounts are utilized to gain access to some of our web > >resources. > > > >Is their a method to point our older app at "domain 2" IPA servers and > >forward on to internal if not found? > >As always, thanks to all who monitor and read this list. One of the best. > > > Can you please be a bit more specific. > > You have an app that is currently pointing to external servers. > How does it point to them? Using LDAP or some other way? > What kind of app it is? > Can you modify it or it is a stock software? > > Forward to the internal "if not found" what? User? > So you want for app to be able to access users from both domains > effectively, right? That's the way I read the original question, too and if it's the case, then it's pretty much how SSSD's domains behave. so if you had in sssd.conf: domains = dom1, dom2 Then a query for a username would first look into dom2. If the user was found, it would be returned to the NSS stack and dom2 wouldn't be queried at all. If there are conflicting names, however and you want to go straight to dom2, you need to qualify the names: getent passwd user at dom2 From mkosek at redhat.com Tue Mar 24 07:58:26 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Mar 2015 08:58:26 +0100 Subject: [Freeipa-users] inserting users via java In-Reply-To: <5510AFDA.2020602@redhat.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> Message-ID: <55111922.8010705@redhat.com> On 03/24/2015 01:29 AM, Dmitri Pal wrote: > On 03/23/2015 05:56 PM, Timothy Worman wrote: >> I have an existing web app built with java/WebObjects that currently handles >> some user/groups tasks with our current directory server (Open Directory). We >> are investigating a move to FreeIPA for our directory services. >> >> Just in mucking around, I?ve found that if I try to insert a new user >> (inetOrgPerson) into into IPA?s implementation, the new user does not inherit >> all the object classes it should. It only inherits the ones leading to >> inetOrgPerson. This does result in a successful inetOrgPerson insertion, but >> that user record does not show up in the Web GUI management tools. >> >> Usually, I have focused on inetOrgPerson because that is where the bulk of >> the info about a user lives. >> >> We have a SQL database that contains people in our organization (used by >> other services), so, we need to be able to leverage that and push users into >> IPA when appropriate and we have an existing app to do this. >> >> Tim W >> > You have several options: > 1) Call ipa CLI from your application - this is possible right now (but not > quite nice) > 2) Call ipa JSON API from your application - this is not supported but > possible. We use python API. You can do it in Java but it will be a lot of work. > 3) Use more elaborate LDAP add commands (with all the object classes needed for > users). Hard, but doable. > 4) Help us with testing the upcoming feature > http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow > creating users via simple ldap command in a staging area and them moving them > to normal users area with automatic creation of missing attributes by means of > a cron job. > > I would vote for 1) as a temp solution and 4) as a longer term one. I do not fully agree with preferring 1) over 2). Java has libraries for JSON-RPC protocol, it should be pretty doable to write a call that calls the "user_add" command. We are lacking proper documentation for the API, but what you can look in the sources or in the Web UI with and see the JSONs sent to the server, if you are interested in the real life examples. Advantage of 2) over 1) is that you get the native objects (strings, arrays, numbers) and you do not need to parse it from CLI. Martin From ender at kofeina.net Tue Mar 24 08:49:46 2015 From: ender at kofeina.net (=?iso-8859-2?Q?=A3ukasz_Jaworski?=) Date: Tue, 24 Mar 2015 09:49:46 +0100 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <550FF343.3030105@redhat.com> References: <550F836F.7090201@gmail.com> <550FF343.3030105@redhat.com> Message-ID: <430C6CA9-9B64-42E5-82DE-3166EC5B443B@kofeina.net> Wiadomo?? napisana przez Martin Kosek w dniu 23 mar 2015, o godz. 12:04: > On 03/23/2015 04:07 AM, Janelle wrote: >> attrlist_replace - attr_replace (nsslapd-referral, >> ldap://ipa1.example.com:389/o%3Dipaca) failed. > > Hm, I do not met this error yet. This looks like error from 389-ds-base, it has > functions like attrlist_replace. > > If this is the case, can you please share a bigger section of the errors log, > ideally for the whole day (if not too big)? There might be some other related > error messages. CCing Ludwig and Thierry for reference. > > Also, what environment are we talking about, is this still > FreeIPA 4.1.3 at CentOS-7? Maybe the server also has a replication agreement also > with CentOS-6? We need to know this also. We have the same problem (yesterday we've migrated users to IPA4, 8 server wit --setup-ca), on every server we have many: [24/Mar/2015:09:40:04 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx28.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:16 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:16 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:16 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:17 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx28.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:17 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx28.xxxxx:389/o%3Dipaca) failed. [24/Mar/2015:09:40:17 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx28.xxxxx:389/o%3Dipaca) failed. Distributor ID: Fedora Description: Fedora release 21 (Twenty One) 389-ds and freeipa: 389-ds-base-1.3.3.8-1.fc21.x86_64 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 freeipa-server-4.1.3-2.fc21.x86_64 Best regards, Ender From tbordaz at redhat.com Tue Mar 24 09:01:31 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 24 Mar 2015 10:01:31 +0100 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <430C6CA9-9B64-42E5-82DE-3166EC5B443B@kofeina.net> References: <550F836F.7090201@gmail.com> <550FF343.3030105@redhat.com> <430C6CA9-9B64-42E5-82DE-3166EC5B443B@kofeina.net> Message-ID: <551127EB.8020603@redhat.com> On 03/24/2015 09:49 AM, ?ukasz Jaworski wrote: > Wiadomo?? napisana przez Martin Kosek w dniu 23 mar 2015, o godz. 12:04: >> On 03/23/2015 04:07 AM, Janelle wrote: >>> attrlist_replace - attr_replace (nsslapd-referral, >>> ldap://ipa1.example.com:389/o%3Dipaca) failed. >> Hm, I do not met this error yet. This looks like error from 389-ds-base, it has >> functions like attrlist_replace. >> >> If this is the case, can you please share a bigger section of the errors log, >> ideally for the whole day (if not too big)? There might be some other related >> error messages. CCing Ludwig and Thierry for reference. >> >> Also, what environment are we talking about, is this still >> FreeIPA 4.1.3 at CentOS-7? Maybe the server also has a replication agreement also >> with CentOS-6? We need to know this also. > We have the same problem (yesterday we've migrated users to IPA4, 8 server wit --setup-ca), on every server we have many: > > [24/Mar/2015:09:40:04 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx28.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:08 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:14 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx51.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:16 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:16 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:16 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx26.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:17 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx28.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:17 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx28.xxxxx:389/o%3Dipaca) failed. > [24/Mar/2015:09:40:17 +0100] attrlist_replace - attr_replace (nsslapd-referral, ldap://xxxxx28.xxxxx:389/o%3Dipaca) failed. > > Distributor ID: Fedora > Description: Fedora release 21 (Twenty One) > > 389-ds and freeipa: > 389-ds-base-1.3.3.8-1.fc21.x86_64 > 389-ds-base-libs-1.3.3.8-1.fc21.x86_64 > freeipa-server-4.1.3-2.fc21.x86_64 > > > Best regards, > Ender > > Hello, It seems that this error is logged each time a replication session is started. At the beginning of the session, the replica that receive the replication request, tries to update the referral list of the replicated suffix (replica) according to the metadata sent by the master. At this step, it fails with these logs. I would like to check the validity (duplicate ?) of if the referrals contained in the master metadata. Would it be possible you do the following command on all your instances: ldapsearch -h.. -pxxx -D "cn=directory manager" -w xxx -b "o=ipaca""(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" nscpentrywsi thanks thierry -------------- next part -------------- An HTML attachment was scrubbed... URL: From ender at kofeina.net Tue Mar 24 10:20:10 2015 From: ender at kofeina.net (=?iso-8859-2?Q?=A3ukasz_Jaworski?=) Date: Tue, 24 Mar 2015 11:20:10 +0100 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <551127EB.8020603@redhat.com> References: <550F836F.7090201@gmail.com> <550FF343.3030105@redhat.com> <430C6CA9-9B64-42E5-82DE-3166EC5B443B@kofeina.net> <551127EB.8020603@redhat.com> Message-ID: <77B789E3-A004-4FCD-8DE6-7FEEF8C689A0@kofeina.net> Hi, Wiadomo?? napisana przez thierry bordaz w dniu 24 mar 2015, o godz. 10:01: > > It seems that this error is logged each time a replication session is started. At the beginning of the session, the replica that receive the replication request, tries to update the referral list of the replicated suffix (replica) according to the metadata sent by the master. > At this step, it fails with these logs. > I would like to check the validity (duplicate ?) of if the referrals contained in the master metadata. Would it be possible you do the following command on all your instances: > ldapsearch -h .. -pxxx -D "cn=directory manager" -w xxx -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" nscpentrywsi Servers: dc1: host25.xxxxx1.net: host26.xxxxx1.net: host27.xxxxx1.net: host28.xxxxx1.net: host68.xxxxx1.net: dc2: host51.xxxxx2: host52.xxxxx2: host32.xxxxx2: host33.xxxxx2: host18.xxxxx2: connected: 68 ---- 28 ---- 25 ---- 51 ---- 33 ---- 18 | | | | | | | | 27 ---- 26 ---- 52 ---- 32 host25.xxxxx1.net: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s50026.xxxxx1.net-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41651.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 96 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: uid=pkidbuser,ou=people,o=ipaca nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323102941Z nscpentrywsi: modifyTimestamp: 20150324090956Z nscpentrywsi: nsState:: YAAAAAAAAADcKRFVAAAAAAAAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: 7bed7405-d14711e4-92bcd6f7-18cf6218 nscpentrywsi: numSubordinates: 3 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host26.xxxxx1.net-pki-tomcat;host26.xxxxx1.net;389;97;551129d7000000600000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host28.xxxxx1.net-pki-tomcat;host28.xxxxx1.net;389;1195;551129d7000000600000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host51.xxxxx2-pki-tomcat;host51.xxxxx2;389;91;551129d7000000600000 nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d8 nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bb nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112710 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 5511138e nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c85 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsds5ReplicaChangeCount: 398 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host26.xxxxx1.net: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s50026.xxxxx1.net-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s50027.xxxxx1.net-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 97 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323102941Z nscpentrywsi: modifyTimestamp: 20150324085804Z nscpentrywsi: nsState:: YQAAAAAAAAASJxFVAAAAAAAAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: 64ae86ce-d14711e4-855b9344-95bb5df8 nscpentrywsi: numSubordinates: 3 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host26.xxxxx1.net-pki-tomcat;host25.xxxxx1.net;389;96;55112711000400610000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host52.xxxxx2-pki-tomcat;host52.xxxxx2;389;1295;55112711000400610000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host27.xxxxx1.net-pki-tomcat;host27.xxxxx1.net;389;1095;55112711000400610000 nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 5511270f nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 5511138e nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c85 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129da nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bc nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b3 nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6c nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 5510000b nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 55100387 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8c nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012f2 nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 nscpentrywsi: nsds5ReplicaChangeCount: 528 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host27.xxxxx1.net: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s50027.xxxxx1.net-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s50028.xxxxx1.net-pki-tomcat,ou=csusers,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 1095 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323103718Z nscpentrywsi: modifyTimestamp: 20150324081313Z nscpentrywsi: nsState:: RwQAAAAAAACMHBFVAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: 75abc7ce-d14811e4-abf7895b-05b94d86 nscpentrywsi: numSubordinates: 2 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host27.xxxxx1.net-pki-tomcat;host26.xxxxx1.net;389;97;55111c8b000504470000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host28.xxxxx1.net-pki-tomcat;host28.xxxxx1.net;389;1195;55111c8b000504470000 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c89 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d8 nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113be nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 55111390 nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c86 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8c nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012f1 nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 nscpentrywsi: nsds5ReplicaChangeCount: 670 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host28.xxxxx1.net: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s50028.xxxxx1.net-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s50268.xxxxx1.net-pki-tomcat,ou=csusers,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 1195 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323104527Z nscpentrywsi: modifyTimestamp: 20150324090957Z nscpentrywsi: nsState:: qwQAAAAAAADZKRFVAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: 99bbd8ce-d14911e4-8662bb9c-72d12cd4 nscpentrywsi: numSubordinates: 3 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host28.xxxxx1.net-pki-tomcat;host27.xxxxx1.net;389;1095;551129d7000804ab0000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host68.xxxxx1.net-pki-tomcat;host68.xxxxx1.net;389;1685;551129d7000804ab0000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host25.xxxxx1.net-pki-tomcat;host25.xxxxx1.net;389;96;551129d7000804ab0000 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d5 nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ef nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8c nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bc nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 55111390 nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c86 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6f nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 5510000b nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 55100389 nscpentrywsi: nsds5ReplicaChangeCount: 530 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host68.xxxxx1.net: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s50268.xxxxx1.net-pki-tomcat,ou=csusers,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 1685 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323133616Z nscpentrywsi: modifyTimestamp: 20150323133901Z nscpentrywsi: nsState:: lQYAAAAAAAB0FxBVAAAAAAAAAAAAAAAAAgAAAAAAAAABAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: 92082e1e-d16111e4-91d3f5c5-aa315d46 nscpentrywsi: numSubordinates: 1 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host68.xxxxx1.net-pki-tomcat;host28.xxxxx1.net;389;unavailable nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d8 nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113be nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 55111390 nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c86 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsds5ReplicaChangeCount: 409 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host51.xxxxx2: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41651.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41652.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 91 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323105544Z nscpentrywsi: modifyTimestamp: 20150324073531Z nscpentrywsi: nsState:: WwAAAAAAAAC8ExFVAAAAAAAAAAAAAAAAAgAAAAAAAAABAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: 07b4cfce-d14b11e4-ba8ec04a-83710c77 nscpentrywsi: numSubordinates: 3 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d6 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d8 nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112710 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b1 nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsds5ReplicaChangeCount: 54 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host52.xxxxx2: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41652.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41732.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 1295 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323110420Z nscpentrywsi: modifyTimestamp: 20150324073439Z nscpentrywsi: nsState:: DwUAAAAAAACOExFVAAAAAAAAAAAAAAAAAgAAAAAAAAAEAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: 3b4429ce-d14c11e4-aeb1ef50-5dea5fec nscpentrywsi: numSubordinates: 3 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host52.xxxxx2-pki-tomcat;host51.xxxxx2;389;91;5511138e000b050f0000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host26.xxxxx1.net-pki-tomcat;host26.xxxxx1.net;389;97;5511138e000b050f0000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host32.xxxxx2-pki-tomcat;host32.xxxxx2;389;1395;5511138e000b050f0000 nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 5511138c nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c85 nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 5511270f nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d6 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129da nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bb nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 55100387 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8c nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ef nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 nscpentrywsi: nsds5ReplicaChangeCount: 583 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host32.xxxxx2: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41732.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41733.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 1395 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323111537Z nscpentrywsi: modifyTimestamp: 20150324070448Z nscpentrywsi: nsState:: cwUAAAAAAACGDBFVAAAAAAAAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: d12c844e-d14d11e4-ab5cc4a6-0e1a9829 nscpentrywsi: numSubordinates: 2 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host32.xxxxx2-pki-tomcat;host52.xxxxx2;389;1295;55110c85000305730000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host33.xxxxx2-pki-tomcat;host33.xxxxx2;389;1495;55110c85000305730000 nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c83 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b1 nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 5511138f nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 5511270f nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d6 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129dc nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bb nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d98 nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012f5 nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 nscpentrywsi: nsds5ReplicaChangeCount: 566 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host33.xxxxx2: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41733.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41718.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 1495 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323112523Z nscpentrywsi: modifyTimestamp: 20150324085213Z nscpentrywsi: nsState:: 1wUAAAAAAACzJRFVAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: 2ddc6ece-d14f11e4-b3d2de6b-b5736bad nscpentrywsi: numSubordinates: 3 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host18.xxxxx2-pki-tomcat;host18.xxxxx2;389;1585;551125b1000105d70000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host32.xxxxx2-pki-tomcat;host32.xxxxx2;389;1395;551125b1000105d70000 nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host51.xxxxx2-pki-tomcat;host51.xxxxx2;389;91;551125b1000105d70000 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125af nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d6 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129da nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsds5ReplicaChangeCount: 50 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 host18.xxxxx2: # extended LDIF # # LDAPv3 # base with scope subtree # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) # requesting: nscpentrywsi # # replica, o\3Dipaca, mapping tree, config dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config nscpentrywsi: objectClass: top nscpentrywsi: objectClass: nsDS5Replica nscpentrywsi: objectClass: extensibleobject nscpentrywsi: nsDS5ReplicaRoot: o=ipaca nscpentrywsi: nsDS5ReplicaType: 3 nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41718.xxxxx2-pki-tomcat,ou=csusers,cn=config nscpentrywsi: cn: replica nscpentrywsi: nsDS5ReplicaId: 1585 nscpentrywsi: nsDS5Flags: 1 nscpentrywsi: creatorsName: cn=directory manager nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config nscpentrywsi: createTimestamp: 20150323121308Z nscpentrywsi: modifyTimestamp: 20150323124633Z nscpentrywsi: nsState:: MQYAAAAAAAAnCxBVAAAAAAAAAAAAAAAAAgAAAAAAAAABAAAAAAAAAA== nscpentrywsi: nsDS5ReplicaName: f3c29b1e-d15511e4-8d35ce39-9b469c1f nscpentrywsi: numSubordinates: 1 nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b0 nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c83 nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 55111391 nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8c nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129db nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bc nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 nscpentrywsi: nsds5ReplicaChangeCount: 364 nscpentrywsi: nsds5replicareapactive: 0 # search result search: 2 result: 0 Success # numResponses: 2 # numEntries: 1 From dpal at redhat.com Tue Mar 24 10:42:12 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 06:42:12 -0400 Subject: [Freeipa-users] Chained IPA Servers In-Reply-To: <20150324072532.GD2989@hendrix.redhat.com> References: <5510AE64.7050900@redhat.com> <20150324072532.GD2989@hendrix.redhat.com> Message-ID: <55113F84.2030007@redhat.com> On 03/24/2015 03:25 AM, Jakub Hrozek wrote: > On Mon, Mar 23, 2015 at 08:23:00PM -0400, Dmitri Pal wrote: >> On 03/23/2015 05:13 PM, Matt Wells wrote: >>> We have two authentication domains; both on 4.X. >>> >>> Domain 1 - Internal and contains our employee accounts >>> Domain 2 - External accounts that reside outside of our company. >>> These accounts are utilized to gain access to some of our web >>> resources. >>> >>> Is their a method to point our older app at "domain 2" IPA servers and >>> forward on to internal if not found? >>> As always, thanks to all who monitor and read this list. One of the best. >>> >> Can you please be a bit more specific. >> >> You have an app that is currently pointing to external servers. >> How does it point to them? Using LDAP or some other way? >> What kind of app it is? >> Can you modify it or it is a stock software? >> >> Forward to the internal "if not found" what? User? >> So you want for app to be able to access users from both domains >> effectively, right? > That's the way I read the original question, too and if it's the case, > then it's pretty much how SSSD's domains behave. > > so if you had in sssd.conf: > domains = dom1, dom2 > Then a query for a username would first look into dom2. If the user was > found, it would be returned to the NSS stack and dom2 wouldn't be > queried at all. If there are conflicting names, however and you want to > go straight to dom2, you need to qualify the names: > getent passwd user at dom2 > Right, the question is can the application take advantage of the SSSD integration? I mean this is the perfect case for the external authentication approach we promote. http://www.freeipa.org/page/Web_App_Authentication -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From bentech4you at gmail.com Tue Mar 24 11:20:38 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 24 Mar 2015 14:20:38 +0300 Subject: [Freeipa-users] how can i give set of users to one particular host Message-ID: HI i am using IPA 3.3 and my client is solaris 10. how can i give only some set of users to this client without creating user group in ad? thanks & Regards, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobby.prins at proxy.nl Tue Mar 24 13:01:37 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Tue, 24 Mar 2015 14:01:37 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150323154447.GR3878@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> <20150320111050.GN3878@redhat.com> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> Message-ID: <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> >----- Oorspronkelijk bericht ----- >Van: "Alexander Bokovoy" >Aan: "Bobby Prins" >Cc: dpal at redhat.com, freeipa-users at redhat.com >Verzonden: Maandag 23 maart 2015 16:44:47 >Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode > >... > >Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >and sssd logs from IPA master (with debug_level = 10) at least in >[domain], [nss], and [pam] sections. > >You need to filter dirsrv logs by connection coming from AIX IP address >and then by conn= where number is the same number as the one >with IP address line. > >When authenticating, AIX would talk to IPA LDAP server to compat tree >and slapi-nis plugin which serves compat tree would do PAM >authentication as service system-auth where SSSD on IPA master will do >the actual authentication work. > >-- >/ Alexander Bokovoy Here you can see the DS connection from AIX: [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 As you can see it also takes quite some time to process the login. Could that be a problem? The SSSD log files are a bit large with debug_level set to 10 and it will take me some time to strip all customer data from it. Any log events in particular you would like to see? From dpal at redhat.com Tue Mar 24 13:42:32 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 09:42:32 -0400 Subject: [Freeipa-users] how can i give set of users to one particular host In-Reply-To: References: Message-ID: <551169C8.1030005@redhat.com> On 03/24/2015 07:20 AM, Ben .T.George wrote: > HI > > i am using IPA 3.3 and my client is solaris 10. > > how can i give only some set of users to this client without creating > user group in ad? > > thanks & Regards, > Ben > > You can create a group in IPA and make Solaris check that group at the access phase of PAM if Solaris is capable of checking groups this way. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roberto.cornacchia at gmail.com Tue Mar 24 13:43:23 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Tue, 24 Mar 2015 14:43:23 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> Message-ID: Hi there, All the issues I reported in this long thread are SOLVED. For completeness, I'm posting here the conclusions. ipa-client-install did enroll the client but failed in several points: $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd [...] Synchronizing time with KDC... Unable to sync time with IPA NTP server, assuming the time is in sync. Please check that 123 UDP port is opened. [...] Failed to update DNS records. [...] Could not update DNS SSHFP records. [...] Unable to find 'admin' user with 'getent passwd admin at hq.example.com'! Unable to reliably detect configuration. Check NSS setup manually. [...] Client configuration complete. There were two distinct problems: 1) NTP sync failed because despite using --force-ntp, chronyd wasn't stopped beforehand. Stopping it manually solved the issue. I believe ipa-client-install stopping chronyd was the intended behaviour, in which case this is perhaps a bug. If it needs to be stopped manually, then it should be documented clearly. The failed NTP sync caused Kerberos to fail, which explains "Unable to find 'admin' user with 'getent passwd admin at hq.example.com'". 2) DNS update failed because for some obscure reason I forgot to open port 53/tcp on the server's firewall. Only 53/udp was open. This fooled me, because with 53/udp open, the DNS was almost completely functional. However, updates also require 53/tcp. All in all, it was a full 2day digging and debugging. Bright side is, I learned a lot. A sincere thank you for the many useful answers I received! Best, Roberto On 23 March 2015 at 10:07, Roberto Cornacchia wrote: > Dmitri, Rob, Jakub, > > I found at least one of the major problems: chronyd. > > This is what I get when I use ipa-client-install on a plain FC21 machine, > *without* using --force-ntpd > > WARNING: ntpd time&date synchronization service will not be configured as > conflicting service (chronyd) is enabled > Use --force-ntpd option to disable it and force configuration of ntpd > > > Good, then I abort and run it again with --force-ntpd: > > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened. > > > Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it > would take care of stopping and disabling chronyd. But it doesn't. That's > why I get the error above. > > If I first stop chronyd manually and run the installation again, then it > does synchronise with NTP. > This was apparently the cause of "id admin" not working (kerberos failing > without proper NTP sync?) > Now the basic functionalities are all OK. > Also, chronyd is disabled and ntpd is enabled after installation - good. > > My nsswitch.conf now looks like this: > > passwd: files sss > shadow: files sss > group: files sss > hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname > bootparams: nisplus [NOTFOUND=return] files > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > services: files sss > netgroup: files sss > publickey: nisplus > automount: files sss > aliases: files nisplus > sudoers: files sss > > > > I am left with 2 issues: > > 1) Is the above expected? Do I have to stop chronyd manually? Or is it a > bug? > 2) DNS update still does not work > > > The latest installation log: > > > $ systemctl stop chronyd > $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd > Discovery was successful! > Hostname: meson.hq.example.com > Realm: HQ.EXAMPLE.COM > DNS Domain: hq.example.com > IPA Server: ipa.hq.example.com > BaseDN: dc=hq,dc=example,dc=com > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > User authorized to enroll computers: User authorized to enroll computers: > admin > Password for admin at HQ.EXAMPLE.COM: > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Valid From: Mon Mar 16 18:44:35 2015 UTC > Valid Until: Fri Mar 16 18:44:35 2035 UTC > > Enrolled in IPA realm HQ.EXAMPLE.COM > 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 HQ.EXAMPLE.COM > trying https://ipa.hq.example.com/ipa/json > Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' > Forwarding 'ca_is_enabled' to json server 'https://ipa.hq.example.com > /ipa/json' > Systemwide CA database updated. > Added CA certificates to the default NSS database. > Hostname (meson.hq.example.com) not found in DNS > *Failed to update DNS records.* > Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Forwarding 'host_mod' to json server 'https://ipa.hq.example.com/ipa/json' > *Could not update DNS SSHFP records.* > SSSD enabled > Configured /etc/openldap/ldap.conf > NTP enabled > Configured /etc/ssh/ssh_config > Configured /etc/ssh/sshd_config > Configuring hq.example.com as NIS domain. > Client configuration complete. > > $ id admin > uid=1172000000(admin) gid=1172000000(admins) groups=1172000000(admins) > > > > > On 22 March 2015 at 21:04, Jakub Hrozek wrote: > >> On Sun, Mar 22, 2015 at 04:24:49PM +0100, Roberto Cornacchia wrote: >> > Thanks Rob. >> > >> > Knowing that /etc/nsswitch.conf is created wrongly is a step forward, >> > although we don't know why that happens yet. >> > I'm not very keen on fixing it post-installation (except if this is >> just to >> > learn more about the issue), even if this seems to solve problems. I'm >> not >> > going to deploy freeIPA for real before I can at least run successfully >> a >> > plain installation. >> >> Hi, >> >> I find it a bit unexpected that the client system didn't have >> nsswitch.conf configured..I've never seen the client installation fail >> in this particular way. >> >> For debugging SSSD issues, we've created a new troubleshooting page >> upstream that should walk you through the config: >> https://fedorahosted.org/sssd/wiki/Troubleshooting >> maybe this article would also help: >> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ >> >> But most improtantly, I wouldn't expect to see any issues as long as >> you use ipa-client-install. I guess re-enrolling the client would be the >> fastest way forward? >> >> -- >> 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 Mar 24 13:44:42 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 09:44:42 -0400 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> <20150320111050.GN3878@redhat.com> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> Message-ID: <55116A4A.8020108@redhat.com> On 03/24/2015 09:01 AM, Bobby Prins wrote: >> ----- Oorspronkelijk bericht ----- >> Van: "Alexander Bokovoy" >> Aan: "Bobby Prins" >> Cc: dpal at redhat.com, freeipa-users at redhat.com >> Verzonden: Maandag 23 maart 2015 16:44:47 >> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >> >> ... >> >> Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >> and sssd logs from IPA master (with debug_level = 10) at least in >> [domain], [nss], and [pam] sections. >> >> You need to filter dirsrv logs by connection coming from AIX IP address >> and then by conn= where number is the same number as the one >> with IP address line. >> >> When authenticating, AIX would talk to IPA LDAP server to compat tree >> and slapi-nis plugin which serves compat tree would do PAM >> authentication as service system-auth where SSSD on IPA master will do >> the actual authentication work. >> >> -- >> / Alexander Bokovoy > Here you can see the DS connection from AIX: > [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 > [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 > [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" > [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 > > As you can see it also takes quite some time to process the login. Could that be a problem? > > The SSSD log files are a bit large with debug_level set to 10 and it will take me some time to strip all customer data from it. Any log events in particular you would like to see? Does the user that you use (bprins at example.corp) is a member of many large groups? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue Mar 24 13:49:04 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 09:49:04 -0400 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> Message-ID: <55116B50.7040508@redhat.com> On 03/24/2015 09:43 AM, Roberto Cornacchia wrote: > Hi there, > > All the issues I reported in this long thread are SOLVED. Thanks for closing the loop. > For completeness, I'm posting here the conclusions. > > ipa-client-install did enroll the client but failed in several points: > > $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd > [...] > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened. > [...] > Failed to update DNS records. > [...] > Could not update DNS SSHFP records. > [...] > Unable to find 'admin' user with 'getent passwd admin at hq.example.com > '! > Unable to reliably detect configuration. Check NSS setup manually. > [...] > Client configuration complete. > > There were two distinct problems: > > 1) NTP sync failed because despite using --force-ntp, chronyd wasn't > stopped beforehand. Stopping it manually solved the issue. I believe > ipa-client-install stopping chronyd was the intended behaviour, in > which case this is perhaps a bug. If it needs to be stopped manually, > then it should be documented clearly. > The failed NTP sync caused Kerberos to fail, which explains "Unable to > find 'admin' user with 'getent passwd admin at hq.example.com > '". We should probably file a ticket about this. I am just not sure what exactly it should be. > > 2) DNS update failed because for some obscure reason I forgot to open > port 53/tcp on the server's firewall. Only 53/udp was open. This > fooled me, because with 53/udp open, the DNS was almost completely > functional. However, updates also require 53/tcp. > > > All in all, it was a full 2day digging and debugging. Bright side is, > I learned a lot. > > A sincere thank you for the many useful answers I received! > Best, > Roberto > > > On 23 March 2015 at 10:07, Roberto Cornacchia > > > wrote: > > Dmitri, Rob, Jakub, > > I found at least one of the major problems: chronyd. > > This is what I get when I use ipa-client-install on a plain FC21 > machine, /without/ using --force-ntpd > > WARNING: ntpd time&date synchronization service will not be > configured as > conflicting service (chronyd) is enabled > Use --force-ntpd option to disable it and force configuration > of ntpd > > > Good, then I abort and run it again with --force-ntpd: > > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is > in sync. Please check that 123 UDP port is opened. > > > Perhaps I misinterpreted the meaning of --force-ntpd. I had > assumed it would take care of stopping and disabling chronyd. But > it doesn't. That's why I get the error above. > > If I first stop chronyd manually and run the installation again, > then it does synchronise with NTP. > This was apparently the cause of "id admin" not working (kerberos > failing without proper NTP sync?) > Now the basic functionalities are all OK. > Also, chronyd is disabled and ntpd is enabled after installation - > good. > > My nsswitch.conf now looks like this: > > passwd: files sss > shadow: files sss > group: files sss > hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname > bootparams: nisplus [NOTFOUND=return] files > ethers: files > netmasks: files > networks: files > protocols: files > rpc: files > services: files sss > netgroup: files sss > publickey: nisplus > automount: files sss > aliases: files nisplus > sudoers: files sss > > > > I am left with 2 issues: > > 1) Is the above expected? Do I have to stop chronyd manually? Or > is it a bug? > 2) DNS update still does not work > > > The latest installation log: > > > $ systemctl stop chronyd > $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd > Discovery was successful! > Hostname: meson.hq.example.com > Realm: HQ.EXAMPLE.COM > DNS Domain: hq.example.com > IPA Server: ipa.hq.example.com > BaseDN: dc=hq,dc=example,dc=com > > Continue to configure the system with these values? [no]: yes > Synchronizing time with KDC... > User authorized to enroll computers: User authorized to enroll > computers: admin > Password for admin at HQ.EXAMPLE.COM : > Successfully retrieved CA cert > Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM > Valid From: Mon Mar 16 18:44:35 2015 UTC > Valid Until: Fri Mar 16 18:44:35 2035 UTC > > Enrolled in IPA realm HQ.EXAMPLE.COM > 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 HQ.EXAMPLE.COM > trying https://ipa.hq.example.com/ipa/json > Forwarding 'ping' to json server 'https://ipa.hq.example.com > /ipa/json' > Forwarding 'ca_is_enabled' to json server > 'https://ipa.hq.example.com /ipa/json' > Systemwide CA database updated. > Added CA certificates to the default NSS database. > Hostname (meson.hq.example.com ) not > found in DNS > *Failed to update DNS records.* > Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub > Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub > Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub > Forwarding 'host_mod' to json server 'https://ipa.hq.example.com > /ipa/json' > *Could not update DNS SSHFP records.* > SSSD enabled > Configured /etc/openldap/ldap.conf > NTP enabled > Configured /etc/ssh/ssh_config > Configured /etc/ssh/sshd_config > Configuring hq.example.com as NIS domain. > Client configuration complete. > > $ id admin > uid=1172000000(admin) gid=1172000000(admins) groups=1172000000(admins) > > > > > On 22 March 2015 at 21:04, Jakub Hrozek > wrote: > > On Sun, Mar 22, 2015 at 04:24:49PM +0100, Roberto Cornacchia > wrote: > > Thanks Rob. > > > > Knowing that /etc/nsswitch.conf is created wrongly is a step > forward, > > although we don't know why that happens yet. > > I'm not very keen on fixing it post-installation (except if > this is just to > > learn more about the issue), even if this seems to solve > problems. I'm not > > going to deploy freeIPA for real before I can at least run > successfully a > > plain installation. > > Hi, > > I find it a bit unexpected that the client system didn't have > nsswitch.conf configured..I've never seen the client > installation fail > in this particular way. > > For debugging SSSD issues, we've created a new troubleshooting > page > upstream that should walk you through the config: > https://fedorahosted.org/sssd/wiki/Troubleshooting > maybe this article would also help: > https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ > > But most improtantly, I wouldn't expect to see any issues as > long as > you use ipa-client-install. I guess re-enrolling the client > would be the > fastest way forward? > > -- > 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 roberto.cornacchia at gmail.com Tue Mar 24 14:01:00 2015 From: roberto.cornacchia at gmail.com (Roberto Cornacchia) Date: Tue, 24 Mar 2015 15:01:00 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <55116B50.7040508@redhat.com> References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> <55116B50.7040508@redhat.com> Message-ID: On 24 March 2015 at 14:49, Dmitri Pal wrote: > On 03/24/2015 09:43 AM, Roberto Cornacchia wrote: > > Hi there, > > All the issues I reported in this long thread are SOLVED. > > > Thanks for closing the loop. > > For completeness, I'm posting here the conclusions. > > ipa-client-install did enroll the client but failed in several points: > > $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd > [...] > Synchronizing time with KDC... > Unable to sync time with IPA NTP server, assuming the time is in sync. > Please check that 123 UDP port is opened. > [...] > Failed to update DNS records. > [...] > Could not update DNS SSHFP records. > [...] > Unable to find 'admin' user with 'getent passwd admin at hq.example.com'! > Unable to reliably detect configuration. Check NSS setup manually. > [...] > Client configuration complete. > > There were two distinct problems: > > 1) NTP sync failed because despite using --force-ntp, chronyd wasn't > stopped beforehand. Stopping it manually solved the issue. I believe > ipa-client-install stopping chronyd was the intended behaviour, in which > case this is perhaps a bug. If it needs to be stopped manually, then it > should be documented clearly. > The failed NTP sync caused Kerberos to fail, which explains "Unable to > find 'admin' user with 'getent passwd admin at hq.example.com'". > > > We should probably file a ticket about this. I am just not sure what > exactly it should be. > > > IMHO, the "assuming the time is in sync" bit is dangerous. The client and the server were already quite in sync (both automatically synced with a remote time server) , but apparently not enough. Being time sync so central in the infrastructure, I would probably want to abort the installation if no sync can be performed successfully. > > 2) DNS update failed because for some obscure reason I forgot to open > port 53/tcp on the server's firewall. Only 53/udp was open. This fooled me, > because with 53/udp open, the DNS was almost completely functional. > However, updates also require 53/tcp. > > > All in all, it was a full 2day digging and debugging. Bright side is, I > learned a lot. > > A sincere thank you for the many useful answers I received! > Best, > Roberto > > > On 23 March 2015 at 10:07, Roberto Cornacchia < > roberto.cornacchia at gmail.com> wrote: > >> Dmitri, Rob, Jakub, >> >> I found at least one of the major problems: chronyd. >> >> This is what I get when I use ipa-client-install on a plain FC21 >> machine, *without* using --force-ntpd >> >> WARNING: ntpd time&date synchronization service will not be configured >> as >> conflicting service (chronyd) is enabled >> Use --force-ntpd option to disable it and force configuration of ntpd >> >> >> Good, then I abort and run it again with --force-ntpd: >> >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP server, assuming the time is in sync. >> Please check that 123 UDP port is opened. >> >> >> Perhaps I misinterpreted the meaning of --force-ntpd. I had assumed it >> would take care of stopping and disabling chronyd. But it doesn't. That's >> why I get the error above. >> >> If I first stop chronyd manually and run the installation again, then >> it does synchronise with NTP. >> This was apparently the cause of "id admin" not working (kerberos failing >> without proper NTP sync?) >> Now the basic functionalities are all OK. >> Also, chronyd is disabled and ntpd is enabled after installation - good. >> >> My nsswitch.conf now looks like this: >> >> passwd: files sss >> shadow: files sss >> group: files sss >> hosts: files mdns4_minimal [NOTFOUND=return] dns myhostname >> bootparams: nisplus [NOTFOUND=return] files >> ethers: files >> netmasks: files >> networks: files >> protocols: files >> rpc: files >> services: files sss >> netgroup: files sss >> publickey: nisplus >> automount: files sss >> aliases: files nisplus >> sudoers: files sss >> >> >> >> I am left with 2 issues: >> >> 1) Is the above expected? Do I have to stop chronyd manually? Or is it >> a bug? >> 2) DNS update still does not work >> >> >> The latest installation log: >> >> >> $ systemctl stop chronyd >> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >> Discovery was successful! >> Hostname: meson.hq.example.com >> Realm: HQ.EXAMPLE.COM >> DNS Domain: hq.example.com >> IPA Server: ipa.hq.example.com >> BaseDN: dc=hq,dc=example,dc=com >> >> Continue to configure the system with these values? [no]: yes >> Synchronizing time with KDC... >> User authorized to enroll computers: User authorized to enroll >> computers: admin >> Password for admin at HQ.EXAMPLE.COM: >> Successfully retrieved CA cert >> Subject: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> Issuer: CN=Certificate Authority,O=HQ.EXAMPLE.COM >> Valid From: Mon Mar 16 18:44:35 2015 UTC >> Valid Until: Fri Mar 16 18:44:35 2035 UTC >> >> Enrolled in IPA realm HQ.EXAMPLE.COM >> 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 HQ.EXAMPLE.COM >> trying https://ipa.hq.example.com/ipa/json >> Forwarding 'ping' to json server 'https://ipa.hq.example.com/ipa/json' >> Forwarding 'ca_is_enabled' to json server 'https://ipa.hq.example.com >> /ipa/json' >> Systemwide CA database updated. >> Added CA certificates to the default NSS database. >> Hostname (meson.hq.example.com) not found in DNS >> *Failed to update DNS records.* >> Adding SSH public key from /etc/ssh/ssh_host_ed25519_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_ecdsa_key.pub >> Adding SSH public key from /etc/ssh/ssh_host_rsa_key.pub >> Forwarding 'host_mod' to json server 'https://ipa.hq.example.com >> /ipa/json' >> *Could not update DNS SSHFP records.* >> SSSD enabled >> Configured /etc/openldap/ldap.conf >> NTP enabled >> Configured /etc/ssh/ssh_config >> Configured /etc/ssh/sshd_config >> Configuring hq.example.com as NIS domain. >> Client configuration complete. >> >> $ id admin >> uid=1172000000(admin) gid=1172000000(admins) groups=1172000000(admins) >> >> >> >> >> On 22 March 2015 at 21:04, Jakub Hrozek wrote: >> >>> On Sun, Mar 22, 2015 at 04:24:49PM +0100, Roberto Cornacchia wrote: >>> > Thanks Rob. >>> > >>> > Knowing that /etc/nsswitch.conf is created wrongly is a step forward, >>> > although we don't know why that happens yet. >>> > I'm not very keen on fixing it post-installation (except if this is >>> just to >>> > learn more about the issue), even if this seems to solve problems. I'm >>> not >>> > going to deploy freeIPA for real before I can at least run >>> successfully a >>> > plain installation. >>> >>> Hi, >>> >>> I find it a bit unexpected that the client system didn't have >>> nsswitch.conf configured..I've never seen the client installation fail >>> in this particular way. >>> >>> For debugging SSSD issues, we've created a new troubleshooting page >>> upstream that should walk you through the config: >>> https://fedorahosted.org/sssd/wiki/Troubleshooting >>> maybe this article would also help: >>> >>> https://jhrozek.wordpress.com/2015/03/11/anatomy-of-sssd-user-lookup/ >>> >>> But most improtantly, I wouldn't expect to see any issues as long as >>> you use ipa-client-install. I guess re-enrolling the client would be the >>> fastest way forward? >>> >>> -- >>> 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. > > > -- > 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 abokovoy at redhat.com Tue Mar 24 14:13:38 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Mar 2015 16:13:38 +0200 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <20150320105109.GQ27609@p.redhat.com> <20150320111050.GN3878@redhat.com> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> Message-ID: <20150324141338.GT3878@redhat.com> On Tue, 24 Mar 2015, Bobby Prins wrote: >>----- Oorspronkelijk bericht ----- >>Van: "Alexander Bokovoy" >>Aan: "Bobby Prins" >>Cc: dpal at redhat.com, freeipa-users at redhat.com >>Verzonden: Maandag 23 maart 2015 16:44:47 >>Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >> >>... >> >>Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>and sssd logs from IPA master (with debug_level = 10) at least in >>[domain], [nss], and [pam] sections. >> >>You need to filter dirsrv logs by connection coming from AIX IP address >>and then by conn= where number is the same number as the one >>with IP address line. >> >>When authenticating, AIX would talk to IPA LDAP server to compat tree >>and slapi-nis plugin which serves compat tree would do PAM >>authentication as service system-auth where SSSD on IPA master will do >>the actual authentication work. >> >>-- >>/ Alexander Bokovoy > >Here you can see the DS connection from AIX: >[24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >[24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >[24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >[24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 > >As you can see it also takes quite some time to process the login. >Could that be a problem? 24 seconds sounds like bprins2example.com is a member of few groups with big amount of members. On the other hand, BIND operation result is 0 (success) and it doesn't look like AIX dropped the connection, at least there is no ABANDON within the context of this connection so AIX did not cancel the request by itself. How long does it take on AIX side to report the inability to login? Is this time longer or shorter the one reported in etime= value on RESULT line above? >The SSSD log files are a bit large with debug_level set to 10 and it >will take me some time to strip all customer data from it. Any log >events in particular you would like to see? https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for some times of issues you might find in the SSSD logs. I'd be interested in "Common AD provider issues", "Troubleshooting authentication, password change and access control". -- / Alexander Bokovoy From bobby.prins at proxy.nl Tue Mar 24 14:18:10 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Tue, 24 Mar 2015 15:18:10 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <55116A4A.8020108@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <55116A4A.8020108@redhat.com> Message-ID: <1099503529.591567.1427206690352.JavaMail.zimbra@proxy.nl> >----- Oorspronkelijk bericht ----- >Van: "Dmitri Pal" >Aan: "Bobby Prins" , "Alexander Bokovoy" >Cc: freeipa-users at redhat.com >Verzonden: Dinsdag 24 maart 2015 14:44:42 >Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode > >On 03/24/2015 09:01 AM, Bobby Prins wrote: >>> ----- Oorspronkelijk bericht ----- >>> Van: "Alexander Bokovoy" >>> Aan: "Bobby Prins" >>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>> Verzonden: Maandag 23 maart 2015 16:44:47 >>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>> >>> ... >>> >>> Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>> and sssd logs from IPA master (with debug_level = 10) at least in >>> [domain], [nss], and [pam] sections. >>> >>> You need to filter dirsrv logs by connection coming from AIX IP address >>> and then by conn= where number is the same number as the one >>> with IP address line. >>> >>> When authenticating, AIX would talk to IPA LDAP server to compat tree >>> and slapi-nis plugin which serves compat tree would do PAM >>> authentication as service system-auth where SSSD on IPA master will do >>> the actual authentication work. >>> >>> -- >>> / Alexander Bokovoy >> Here you can see the DS connection from AIX: >> [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >> [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >> [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >> [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >> >> As you can see it also takes quite some time to process the login. Could that be a problem? >> >> The SSSD log files are a bit large with debug_level set to 10 and it will take me some time to strip all customer data from it. Any log events in particular you would like to see? >Does the user that you use (bprins at example.corp) is a member of many >large groups? > >-- >Thank you, >Dmitri Pal > >Sr. Engineering Manager IdM portfolio >Red Hat, Inc. 53 groups in total ranging from groups with only a couple of users to groups with multiple hundreds of users. From tbordaz at redhat.com Tue Mar 24 14:18:45 2015 From: tbordaz at redhat.com (thierry bordaz) Date: Tue, 24 Mar 2015 15:18:45 +0100 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <77B789E3-A004-4FCD-8DE6-7FEEF8C689A0@kofeina.net> References: <550F836F.7090201@gmail.com> <550FF343.3030105@redhat.com> <430C6CA9-9B64-42E5-82DE-3166EC5B443B@kofeina.net> <551127EB.8020603@redhat.com> <77B789E3-A004-4FCD-8DE6-7FEEF8C689A0@kofeina.net> Message-ID: <55117245.10307@redhat.com> Hello, Sorry for the late answer. Those entries are named RUV. host25.xxxxx1.net RUV contains nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 *nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000* nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 *nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000* So host68:389 and host18:389 are masters for the same suffix (o=ipaca) but with different replica Identifier (1685,1690,1695 and 1585,1590,1595). Some of those Replica Identifiers are likely old one that need to cleared. Did you run CLEANRUV ? thanks thierry On 03/24/2015 11:20 AM, ?ukasz Jaworski wrote: > Hi, > > Wiadomo?? napisana przez thierry bordaz w dniu 24 mar 2015, o godz. 10:01: >> It seems that this error is logged each time a replication session is started. At the beginning of the session, the replica that receive the replication request, tries to update the referral list of the replicated suffix (replica) according to the metadata sent by the master. >> At this step, it fails with these logs. >> I would like to check the validity (duplicate ?) of if the referrals contained in the master metadata. Would it be possible you do the following command on all your instances: >> ldapsearch -h .. -pxxx -D "cn=directory manager" -w xxx -b "o=ipaca" "(&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff))" nscpentrywsi > Servers: > dc1: > host25.xxxxx1.net: > host26.xxxxx1.net: > host27.xxxxx1.net: > host28.xxxxx1.net: > host68.xxxxx1.net: > > dc2: > host51.xxxxx2: > host52.xxxxx2: > host32.xxxxx2: > host33.xxxxx2: > host18.xxxxx2: > > connected: > 68 ---- 28 ---- 25 ---- 51 ---- 33 ---- 18 > | | | | > | | | | > 27 ---- 26 ---- 52 ---- 32 > > > host25.xxxxx1.net: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s50026.xxxxx1.net-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41651.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 96 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: uid=pkidbuser,ou=people,o=ipaca > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323102941Z > nscpentrywsi: modifyTimestamp: 20150324090956Z > nscpentrywsi: nsState:: YAAAAAAAAADcKRFVAAAAAAAAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: 7bed7405-d14711e4-92bcd6f7-18cf6218 > nscpentrywsi: numSubordinates: 3 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host26.xxxxx1.net-pki-tomcat;host26.xxxxx1.net;389;97;551129d7000000600000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host28.xxxxx1.net-pki-tomcat;host28.xxxxx1.net;389;1195;551129d7000000600000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host51.xxxxx2-pki-tomcat;host51.xxxxx2;389;91;551129d7000000600000 > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d8 > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bb > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112710 > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 5511138e > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c85 > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsds5ReplicaChangeCount: 398 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host26.xxxxx1.net: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s50026.xxxxx1.net-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s50027.xxxxx1.net-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 97 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323102941Z > nscpentrywsi: modifyTimestamp: 20150324085804Z > nscpentrywsi: nsState:: YQAAAAAAAAASJxFVAAAAAAAAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: 64ae86ce-d14711e4-855b9344-95bb5df8 > nscpentrywsi: numSubordinates: 3 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host26.xxxxx1.net-pki-tomcat;host25.xxxxx1.net;389;96;55112711000400610000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host52.xxxxx2-pki-tomcat;host52.xxxxx2;389;1295;55112711000400610000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host27.xxxxx1.net-pki-tomcat;host27.xxxxx1.net;389;1095;55112711000400610000 > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 5511270f > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 5511138e > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c85 > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129da > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bc > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b3 > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6c > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 5510000b > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 55100387 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8c > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012f2 > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 > nscpentrywsi: nsds5ReplicaChangeCount: 528 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host27.xxxxx1.net: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s50027.xxxxx1.net-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s50028.xxxxx1.net-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 1095 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323103718Z > nscpentrywsi: modifyTimestamp: 20150324081313Z > nscpentrywsi: nsState:: RwQAAAAAAACMHBFVAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: 75abc7ce-d14811e4-abf7895b-05b94d86 > nscpentrywsi: numSubordinates: 2 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host27.xxxxx1.net-pki-tomcat;host26.xxxxx1.net;389;97;55111c8b000504470000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host28.xxxxx1.net-pki-tomcat;host28.xxxxx1.net;389;1195;55111c8b000504470000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c89 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d8 > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113be > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 55111390 > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c86 > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8c > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012f1 > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 > nscpentrywsi: nsds5ReplicaChangeCount: 670 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host28.xxxxx1.net: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s50028.xxxxx1.net-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s50268.xxxxx1.net-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 1195 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323104527Z > nscpentrywsi: modifyTimestamp: 20150324090957Z > nscpentrywsi: nsState:: qwQAAAAAAADZKRFVAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: 99bbd8ce-d14911e4-8662bb9c-72d12cd4 > nscpentrywsi: numSubordinates: 3 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host28.xxxxx1.net-pki-tomcat;host27.xxxxx1.net;389;1095;551129d7000804ab0000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host68.xxxxx1.net-pki-tomcat;host68.xxxxx1.net;389;1685;551129d7000804ab0000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host25.xxxxx1.net-pki-tomcat;host25.xxxxx1.net;389;96;551129d7000804ab0000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d5 > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ef > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8c > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bc > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 55111390 > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c86 > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6f > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 5510000b > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 55100389 > nscpentrywsi: nsds5ReplicaChangeCount: 530 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host68.xxxxx1.net: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s50268.xxxxx1.net-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 1685 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323133616Z > nscpentrywsi: modifyTimestamp: 20150323133901Z > nscpentrywsi: nsState:: lQYAAAAAAAB0FxBVAAAAAAAAAAAAAAAAAgAAAAAAAAABAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: 92082e1e-d16111e4-91d3f5c5-aa315d46 > nscpentrywsi: numSubordinates: 1 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host68.xxxxx1.net-pki-tomcat;host28.xxxxx1.net;389;unavailable > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d8 > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113be > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 55111390 > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c86 > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsds5ReplicaChangeCount: 409 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host51.xxxxx2: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41651.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41652.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 91 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323105544Z > nscpentrywsi: modifyTimestamp: 20150324073531Z > nscpentrywsi: nsState:: WwAAAAAAAAC8ExFVAAAAAAAAAAAAAAAAAgAAAAAAAAABAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: 07b4cfce-d14b11e4-ba8ec04a-83710c77 > nscpentrywsi: numSubordinates: 3 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d6 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129d8 > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112710 > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b1 > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsds5ReplicaChangeCount: 54 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host52.xxxxx2: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41652.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41732.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 1295 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323110420Z > nscpentrywsi: modifyTimestamp: 20150324073439Z > nscpentrywsi: nsState:: DwUAAAAAAACOExFVAAAAAAAAAAAAAAAAAgAAAAAAAAAEAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: 3b4429ce-d14c11e4-aeb1ef50-5dea5fec > nscpentrywsi: numSubordinates: 3 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host52.xxxxx2-pki-tomcat;host51.xxxxx2;389;91;5511138e000b050f0000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host26.xxxxx1.net-pki-tomcat;host26.xxxxx1.net;389;97;5511138e000b050f0000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host32.xxxxx2-pki-tomcat;host32.xxxxx2;389;1395;5511138e000b050f0000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 5511138c > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c85 > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 5511270f > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d6 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129da > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bb > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b2 > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 55100387 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8c > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ef > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 > nscpentrywsi: nsds5ReplicaChangeCount: 583 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host32.xxxxx2: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41732.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41733.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 1395 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323111537Z > nscpentrywsi: modifyTimestamp: 20150324070448Z > nscpentrywsi: nsState:: cwUAAAAAAACGDBFVAAAAAAAAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: d12c844e-d14d11e4-ab5cc4a6-0e1a9829 > nscpentrywsi: numSubordinates: 2 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host32.xxxxx2-pki-tomcat;host52.xxxxx2;389;1295;55110c85000305730000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;cloneAgreement1-host33.xxxxx2-pki-tomcat;host33.xxxxx2;389;1495;55110c85000305730000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c83 > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b1 > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 5511138f > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 5511270f > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d6 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129dc > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bb > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d98 > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 551012f5 > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e9 > nscpentrywsi: nsds5ReplicaChangeCount: 566 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host33.xxxxx2: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41733.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=replication manager,cn=config > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-s41718.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 1495 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323112523Z > nscpentrywsi: modifyTimestamp: 20150324085213Z > nscpentrywsi: nsState:: 1wUAAAAAAACzJRFVAAAAAAAAAAAAAAAAAgAAAAAAAAAAAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: 2ddc6ece-d14f11e4-b3d2de6b-b5736bad > nscpentrywsi: numSubordinates: 3 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host18.xxxxx2-pki-tomcat;host18.xxxxx2;389;1585;551125b1000105d70000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host32.xxxxx2-pki-tomcat;host32.xxxxx2;389;1395;551125b1000105d70000 > nscpentrywsi: nsds5agmtmaxcsn: o=ipaca;masterAgreement1-host51.xxxxx2-pki-tomcat;host51.xxxxx2;389;91;551125b1000105d70000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125af > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d6 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129da > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8b > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsds5ReplicaChangeCount: 50 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 > host18.xxxxx2: > # extended LDIF > # > # LDAPv3 > # base with scope subtree > # filter: (&(objectclass=nstombstone)(nsUniqueId=ffffffff-ffffffff-ffffffff-ffffffff)) > # requesting: nscpentrywsi > # > > # replica, o\3Dipaca, mapping tree, config > dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config > nscpentrywsi: objectClass: top > nscpentrywsi: objectClass: nsDS5Replica > nscpentrywsi: objectClass: extensibleobject > nscpentrywsi: nsDS5ReplicaRoot: o=ipaca > nscpentrywsi: nsDS5ReplicaType: 3 > nscpentrywsi: nsDS5ReplicaBindDN: cn=Replication Manager cloneAgreement1-s41718.xxxxx2-pki-tomcat,ou=csusers,cn=config > nscpentrywsi: cn: replica > nscpentrywsi: nsDS5ReplicaId: 1585 > nscpentrywsi: nsDS5Flags: 1 > nscpentrywsi: creatorsName: cn=directory manager > nscpentrywsi: modifiersName: cn=Multimaster Replication Plugin,cn=plugins,cn=config > nscpentrywsi: createTimestamp: 20150323121308Z > nscpentrywsi: modifyTimestamp: 20150323124633Z > nscpentrywsi: nsState:: MQYAAAAAAAAnCxBVAAAAAAAAAAAAAAAAAgAAAAAAAAABAAAAAAAAAA== > nscpentrywsi: nsDS5ReplicaName: f3c29b1e-d15511e4-8d35ce39-9b469c1f > nscpentrywsi: numSubordinates: 1 > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} 55100385000006310000 55100387000106310000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} 550ff837000005d70000 551125b1000105d70000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} 550feed9000004ab0000 551129d7000804ab0000 > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} 55100d8b0000069f0000 55100d8c0001069f0000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1585 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1495 ldap://host33.xxxxx2:389} 551125b0 > nscpentrywsi: nsruvReplicaLastModified: {replica 1395 ldap://host32.xxxxx2:389} 55110c83 > nscpentrywsi: nsruvReplicaLastModified: {replica 1295 ldap://host52.xxxxx2:389} 55111391 > nscpentrywsi: nsruvReplicaLastModified: {replica 97 ldap://host26.xxxxx1.net:389} 55112711 > nscpentrywsi: nsruvReplicaLastModified: {replica 1095 ldap://host27.xxxxx1.net:389} 55111c8c > nscpentrywsi: nsruvReplicaLastModified: {replica 96 ldap://host25.xxxxx1.net:389} 551129d5 > nscpentrywsi: nsruvReplicaLastModified: {replica 1195 ldap://host28.xxxxx1.net:389} 551129db > nscpentrywsi: nsruvReplicaLastModified: {replica 91 ldap://host51.xxxxx2:389} 551113bc > nscpentrywsi: nsruvReplicaLastModified: {replica 1595 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1590 ldap://host18.xxxxx2:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1695 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1690 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsruvReplicaLastModified: {replica 1685 ldap://host68.xxxxx1.net:389} 00000000 > nscpentrywsi: nsds5ReplicaChangeCount: 364 > nscpentrywsi: nsds5replicareapactive: 0 > > # search result > search: 2 > result: 0 Success > > # numResponses: 2 > # numEntries: 1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Mar 24 15:08:07 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 11:08:07 -0400 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <1099503529.591567.1427206690352.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <55116A4A.8020108@redhat.com> <1099503529.591567.1427206690352.JavaMail.zimbra@proxy.nl> Message-ID: <55117DD7.4070900@redhat.com> On 03/24/2015 10:18 AM, Bobby Prins wrote: >> ----- Oorspronkelijk bericht ----- >> Van: "Dmitri Pal" >> Aan: "Bobby Prins" , "Alexander Bokovoy" >> Cc: freeipa-users at redhat.com >> Verzonden: Dinsdag 24 maart 2015 14:44:42 >> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >> >> On 03/24/2015 09:01 AM, Bobby Prins wrote: >>>> ----- Oorspronkelijk bericht ----- >>>> Van: "Alexander Bokovoy" >>>> Aan: "Bobby Prins" >>>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>>> Verzonden: Maandag 23 maart 2015 16:44:47 >>>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>>> >>>> ... >>>> >>>> Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>> and sssd logs from IPA master (with debug_level = 10) at least in >>>> [domain], [nss], and [pam] sections. >>>> >>>> You need to filter dirsrv logs by connection coming from AIX IP address >>>> and then by conn= where number is the same number as the one >>>> with IP address line. >>>> >>>> When authenticating, AIX would talk to IPA LDAP server to compat tree >>>> and slapi-nis plugin which serves compat tree would do PAM >>>> authentication as service system-auth where SSSD on IPA master will do >>>> the actual authentication work. >>>> >>>> -- >>>> / Alexander Bokovoy >>> Here you can see the DS connection from AIX: >>> [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>> [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>> [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>> [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >>> >>> As you can see it also takes quite some time to process the login. Could that be a problem? >>> >>> The SSSD log files are a bit large with debug_level set to 10 and it will take me some time to strip all customer data from it. Any log events in particular you would like to see? >> Does the user that you use (bprins at example.corp) is a member of many >> large groups? >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. > 53 groups in total ranging from groups with only a couple of users to groups with multiple hundreds of users. And probably nesting is involved too, right? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From bobby.prins at proxy.nl Tue Mar 24 15:23:40 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Tue, 24 Mar 2015 16:23:40 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <55117DD7.4070900@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <55116A4A.8020108@redhat.com> <1099503529.591567.1427206690352.JavaMail.zimbra@proxy.nl> <55117DD7.4070900@redhat.com> Message-ID: <1710274491.593347.1427210620784.JavaMail.zimbra@proxy.nl> >----- Oorspronkelijk bericht ----- >Van: "Dmitri Pal" >Aan: "Bobby Prins" >Cc: "Alexander Bokovoy" , freeipa-users at redhat.com >Verzonden: Dinsdag 24 maart 2015 16:08:07 >Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode > >On 03/24/2015 10:18 AM, Bobby Prins wrote: >>> ----- Oorspronkelijk bericht ----- >>> Van: "Dmitri Pal" >>> Aan: "Bobby Prins" , "Alexander Bokovoy" >>> Cc: freeipa-users at redhat.com >>> Verzonden: Dinsdag 24 maart 2015 14:44:42 >>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>> >>> On 03/24/2015 09:01 AM, Bobby Prins wrote: >>>>> ----- Oorspronkelijk bericht ----- >>>>> Van: "Alexander Bokovoy" >>>>> Aan: "Bobby Prins" >>>>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>>>> Verzonden: Maandag 23 maart 2015 16:44:47 >>>>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>>>> >>>>> ... >>>>> >>>>> Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>>> and sssd logs from IPA master (with debug_level = 10) at least in >>>>> [domain], [nss], and [pam] sections. >>>>> >>>>> You need to filter dirsrv logs by connection coming from AIX IP address >>>>> and then by conn= where number is the same number as the one >>>>> with IP address line. >>>>> >>>>> When authenticating, AIX would talk to IPA LDAP server to compat tree >>>>> and slapi-nis plugin which serves compat tree would do PAM >>>>> authentication as service system-auth where SSSD on IPA master will do >>>>> the actual authentication work. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>> Here you can see the DS connection from AIX: >>>> [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>>> [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>>> [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>>> [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >>>> >>>> As you can see it also takes quite some time to process the login. Could that be a problem? >>>> >>>> The SSSD log files are a bit large with debug_level set to 10 and it will take me some time to strip all customer data from it. Any log events in particular you would like to see? >>> Does the user that you use (bprins at example.corp) is a member of many >>> large groups? >>> >>> -- >>> Thank you, >>> Dmitri Pal >>> >>> Sr. Engineering Manager IdM portfolio >>> Red Hat, Inc. >> 53 groups in total ranging from groups with only a couple of users to groups with multiple hundreds of users. >And probably nesting is involved too, right? > >-- >Thank you, >Dmitri Pal > >Sr. Engineering Manager IdM portfolio >Red Hat, Inc. Yes, that is correct, but the 53 groups is including nested memberships. From bobby.prins at proxy.nl Tue Mar 24 15:45:53 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Tue, 24 Mar 2015 16:45:53 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150324141338.GT3878@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> Message-ID: <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> >----- Oorspronkelijk bericht ----- >Van: "Alexander Bokovoy" >Aan: "Bobby Prins" >Cc: dpal at redhat.com, freeipa-users at redhat.com >Verzonden: Dinsdag 24 maart 2015 15:13:38 >Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode > >On Tue, 24 Mar 2015, Bobby Prins wrote: >>>----- Oorspronkelijk bericht ----- >>>Van: "Alexander Bokovoy" >>>Aan: "Bobby Prins" >>>Cc: dpal at redhat.com, freeipa-users at redhat.com >>>Verzonden: Maandag 23 maart 2015 16:44:47 >>>Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>> >>>... >>> >>>Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>and sssd logs from IPA master (with debug_level = 10) at least in >>>[domain], [nss], and [pam] sections. >>> >>>You need to filter dirsrv logs by connection coming from AIX IP address >>>and then by conn= where number is the same number as the one >>>with IP address line. >>> >>>When authenticating, AIX would talk to IPA LDAP server to compat tree >>>and slapi-nis plugin which serves compat tree would do PAM >>>authentication as service system-auth where SSSD on IPA master will do >>>the actual authentication work. >>> >>>-- >>>/ Alexander Bokovoy >> >>Here you can see the DS connection from AIX: >>[24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>[24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>[24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>[24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >> >>As you can see it also takes quite some time to process the login. >>Could that be a problem? >24 seconds sounds like bprins2example.com is a member of few groups with >big amount of members. On the other hand, BIND operation result is 0 >(success) and it doesn't look like AIX dropped the connection, at least >there is no ABANDON within the context of this connection so AIX did not >cancel the request by itself. > >How long does it take on AIX side to report the inability to login? Is >this time longer or shorter the one reported in etime= value on RESULT >line above? > >>The SSSD log files are a bit large with debug_level set to 10 and it >>will take me some time to strip all customer data from it. Any log >>events in particular you would like to see? >https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for >some times of issues you might find in the SSSD logs. I'd be interested >in "Common AD provider issues", "Troubleshooting authentication, >password change and access control". > >-- >/ Alexander Bokovoy The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. PAM logging on AIX: Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER Doing a ldapsearch with bprins at example.corp as bind user works without any problems. From mkosek at redhat.com Tue Mar 24 16:08:55 2015 From: mkosek at redhat.com (Martin Kosek) Date: Tue, 24 Mar 2015 17:08:55 +0100 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <55117245.10307@redhat.com> References: <550F836F.7090201@gmail.com> <550FF343.3030105@redhat.com> <430C6CA9-9B64-42E5-82DE-3166EC5B443B@kofeina.net> <551127EB.8020603@redhat.com> <77B789E3-A004-4FCD-8DE6-7FEEF8C689A0@kofeina.net> <55117245.10307@redhat.com> Message-ID: <55118C17.40807@redhat.com> On 03/24/2015 03:18 PM, thierry bordaz wrote: > Hello, > > Sorry for the late answer. > > Those entries are named RUV. > > host25.xxxxx1.net RUV contains > nscpentrywsi: nsds50ruv: {replicageneration} 550feb15000000600000 > nscpentrywsi: nsds50ruv: {replica 96 ldap://host25.xxxxx1.net:389} > 550feb1d000000600000 551129d7000000600000 > nscpentrywsi: nsds50ruv: {replica 1195 ldap://host28.xxxxx1.net:389} > 550feed9000004ab0000 551129d7000804ab0000 > *nscpentrywsi: nsds50ruv: {replica 1685 ldap://host68.xxxxx1.net:389} > 551016e7000006950000 551016e8000306950000 > nscpentrywsi: nsds50ruv: {replica 1690 ldap://host68.xxxxx1.net:389} > 551012ed0000069a0000 551012ee0001069a0000 > nscpentrywsi: nsds50ruv: {replica 1695 ldap://host68.xxxxx1.net:389} > 55100d8b0000069f0000 55100d8c0001069f0000* > nscpentrywsi: nsds50ruv: {replica 91 ldap://host51.xxxxx2:389} > 550ff1440000005b0000 551113bd0003005b0000 > nscpentrywsi: nsds50ruv: {replica 97 ldap://host26.xxxxx1.net:389} > 550feb27000000610000 55112711000400610000 > nscpentrywsi: nsds50ruv: {replica 1095 ldap://host27.xxxxx1.net:389} > 550fecef000004470000 55111c8b000504470000 > nscpentrywsi: nsds50ruv: {replica 1295 ldap://host52.xxxxx2:389} > 550ff3480000050f0000 5511138e000b050f0000 > nscpentrywsi: nsds50ruv: {replica 1395 ldap://host32.xxxxx2:389} > 550ff5ed000005730000 55110c85000305730000 > nscpentrywsi: nsds50ruv: {replica 1495 ldap://host33.xxxxx2:389} > 550ff837000005d70000 551125b1000105d70000 > *nscpentrywsi: nsds50ruv: {replica 1595 ldap://host18.xxxxx2:389} > 550ffc6b0000063b0000 550ffc6c0001063b0000 > nscpentrywsi: nsds50ruv: {replica 1590 ldap://host18.xxxxx2:389} > 5510000a000006360000 5510000b000106360000 > nscpentrywsi: nsds50ruv: {replica 1585 ldap://host18.xxxxx2:389} > 55100385000006310000 55100387000106310000* > > So host68:389 and host18:389 are masters for the same suffix (o=ipaca) but with > different replica Identifier (1685,1690,1695 and 1585,1590,1595). > > Some of those Replica Identifiers are likely old one that need to cleared. > Did you run CLEANRUV ? > > thanks > thierry Right. Maybe you reinstalled IPA replica (several times) without cleaning the RUV? With # ipa-replica-manage list-ruv # ipa-replica-manage clean-ruv you should be able to clean the old (lower) RUVs and see if the error disappears. More info in "man ipa-replica-manage" and on https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-topology.html#cleanruv Martin From dpal at redhat.com Tue Mar 24 16:11:20 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 12:11:20 -0400 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> Message-ID: <55118CA8.3080507@redhat.com> On 03/24/2015 11:45 AM, Bobby Prins wrote: >> ----- Oorspronkelijk bericht ----- >> Van: "Alexander Bokovoy" >> Aan: "Bobby Prins" >> Cc: dpal at redhat.com, freeipa-users at redhat.com >> Verzonden: Dinsdag 24 maart 2015 15:13:38 >> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >> >> On Tue, 24 Mar 2015, Bobby Prins wrote: >>>> ----- Oorspronkelijk bericht ----- >>>> Van: "Alexander Bokovoy" >>>> Aan: "Bobby Prins" >>>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>>> Verzonden: Maandag 23 maart 2015 16:44:47 >>>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>>> >>>> ... >>>> >>>> Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>> and sssd logs from IPA master (with debug_level = 10) at least in >>>> [domain], [nss], and [pam] sections. >>>> >>>> You need to filter dirsrv logs by connection coming from AIX IP address >>>> and then by conn= where number is the same number as the one >>>> with IP address line. >>>> >>>> When authenticating, AIX would talk to IPA LDAP server to compat tree >>>> and slapi-nis plugin which serves compat tree would do PAM >>>> authentication as service system-auth where SSSD on IPA master will do >>>> the actual authentication work. >>>> >>>> -- >>>> / Alexander Bokovoy >>> Here you can see the DS connection from AIX: >>> [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>> [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>> [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>> [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >>> >>> As you can see it also takes quite some time to process the login. >>> Could that be a problem? >> 24 seconds sounds like bprins2example.com is a member of few groups with >> big amount of members. On the other hand, BIND operation result is 0 >> (success) and it doesn't look like AIX dropped the connection, at least >> there is no ABANDON within the context of this connection so AIX did not >> cancel the request by itself. >> >> How long does it take on AIX side to report the inability to login? Is >> this time longer or shorter the one reported in etime= value on RESULT >> line above? >> >>> The SSSD log files are a bit large with debug_level set to 10 and it >>> will take me some time to strip all customer data from it. Any log >>> events in particular you would like to see? >> https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for >> some times of issues you might find in the SSSD logs. I'd be interested >> in "Common AD provider issues", "Troubleshooting authentication, >> password change and access control". >> >> -- >> / Alexander Bokovoy > The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. > > I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. > > PAM logging on AIX: > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate > Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed Seems like 15 sec timeout on the AIX side. Can you try with a user that does not have that many groups and see if that works? If it does then we should assume it is an AIX side timeout and focus on making sure the data gets over to IPA within this timeout. > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed > Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER > > Doing a ldapsearch with bprins at example.corp as bind user works without any problems. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From jhrozek at redhat.com Tue Mar 24 16:17:11 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Mar 2015 17:17:11 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> Message-ID: <20150324161710.GS2989@hendrix.redhat.com> On Tue, Mar 24, 2015 at 04:45:53PM +0100, Bobby Prins wrote: > >----- Oorspronkelijk bericht ----- > >Van: "Alexander Bokovoy" > >Aan: "Bobby Prins" > >Cc: dpal at redhat.com, freeipa-users at redhat.com > >Verzonden: Dinsdag 24 maart 2015 15:13:38 > >Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode > > > >On Tue, 24 Mar 2015, Bobby Prins wrote: > >>>----- Oorspronkelijk bericht ----- > >>>Van: "Alexander Bokovoy" > >>>Aan: "Bobby Prins" > >>>Cc: dpal at redhat.com, freeipa-users at redhat.com > >>>Verzonden: Maandag 23 maart 2015 16:44:47 > >>>Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode > >>> > >>>... > >>> > >>>Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access > >>>and sssd logs from IPA master (with debug_level = 10) at least in > >>>[domain], [nss], and [pam] sections. > >>> > >>>You need to filter dirsrv logs by connection coming from AIX IP address > >>>and then by conn= where number is the same number as the one > >>>with IP address line. > >>> > >>>When authenticating, AIX would talk to IPA LDAP server to compat tree > >>>and slapi-nis plugin which serves compat tree would do PAM > >>>authentication as service system-auth where SSSD on IPA master will do > >>>the actual authentication work. > >>> > >>>-- > >>>/ Alexander Bokovoy > >> > >>Here you can see the DS connection from AIX: > >>[24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 > >>[24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 > >>[24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" > >>[24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 > >> > >>As you can see it also takes quite some time to process the login. > >>Could that be a problem? > >24 seconds sounds like bprins2example.com is a member of few groups with > >big amount of members. On the other hand, BIND operation result is 0 > >(success) and it doesn't look like AIX dropped the connection, at least > >there is no ABANDON within the context of this connection so AIX did not > >cancel the request by itself. > > > >How long does it take on AIX side to report the inability to login? Is > >this time longer or shorter the one reported in etime= value on RESULT > >line above? > > > >>The SSSD log files are a bit large with debug_level set to 10 and it > >>will take me some time to strip all customer data from it. Any log > >>events in particular you would like to see? > >https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for > >some times of issues you might find in the SSSD logs. I'd be interested > >in "Common AD provider issues", "Troubleshooting authentication, > >password change and access control". > > > >-- > >/ Alexander Bokovoy > > The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. > > I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. I guess what Alexander meant (in a very simplified way) was that the 'id' command could take a long time. Sumit recently fixed two nasty issues that would make this operation take too long with POSIX attributes in effect and also that the initgroups operation might be done too frequently with SSH. I wonder if you might be seeing this issue, the SSSD logs capturing the login on the server side would help. > > PAM logging on AIX: > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix > Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate > Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user > Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed > Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER > > Doing a ldapsearch with bprins at example.corp as bind user works without any problems. > > -- > 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 Tue Mar 24 16:23:08 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Mar 2015 18:23:08 +0200 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> Message-ID: <20150324162308.GU3878@redhat.com> On Tue, 24 Mar 2015, Bobby Prins wrote: >>----- Oorspronkelijk bericht ----- >>Van: "Alexander Bokovoy" >>Aan: "Bobby Prins" >>Cc: dpal at redhat.com, freeipa-users at redhat.com >>Verzonden: Dinsdag 24 maart 2015 15:13:38 >>Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >> >>On Tue, 24 Mar 2015, Bobby Prins wrote: >>>>----- Oorspronkelijk bericht ----- >>>>Van: "Alexander Bokovoy" >>>>Aan: "Bobby Prins" >>>>Cc: dpal at redhat.com, freeipa-users at redhat.com >>>>Verzonden: Maandag 23 maart 2015 16:44:47 >>>>Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>>> >>>>... >>>> >>>>Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>>and sssd logs from IPA master (with debug_level = 10) at least in >>>>[domain], [nss], and [pam] sections. >>>> >>>>You need to filter dirsrv logs by connection coming from AIX IP address >>>>and then by conn= where number is the same number as the one >>>>with IP address line. >>>> >>>>When authenticating, AIX would talk to IPA LDAP server to compat tree >>>>and slapi-nis plugin which serves compat tree would do PAM >>>>authentication as service system-auth where SSSD on IPA master will do >>>>the actual authentication work. >>>> >>>>-- >>>>/ Alexander Bokovoy >>> >>>Here you can see the DS connection from AIX: >>>[24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>>[24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>>[24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>>[24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >>> >>>As you can see it also takes quite some time to process the login. >>>Could that be a problem? >>24 seconds sounds like bprins2example.com is a member of few groups with >>big amount of members. On the other hand, BIND operation result is 0 >>(success) and it doesn't look like AIX dropped the connection, at least >>there is no ABANDON within the context of this connection so AIX did not >>cancel the request by itself. >> >>How long does it take on AIX side to report the inability to login? Is >>this time longer or shorter the one reported in etime= value on RESULT >>line above? >> >>>The SSSD log files are a bit large with debug_level set to 10 and it >>>will take me some time to strip all customer data from it. Any log >>>events in particular you would like to see? >>https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for >>some times of issues you might find in the SSSD logs. I'd be interested >>in "Common AD provider issues", "Troubleshooting authentication, >>password change and access control". >> >>-- >>/ Alexander Bokovoy > >The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. > >I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. > >PAM logging on AIX: >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate >Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed >Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() >Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt >Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user >Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed >Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER > >Doing a ldapsearch with bprins at example.corp as bind user works without any problems. According to the log above you get failure from pam_aix which should be expected if pam_aix doesn't think that the user in question is coming from LDAP. Can you show output of lsuser -R LDAP bprins at example.corp lsuser -a registry SYSTEM bprins at example.corp The attributes 'registry' and 'SYSTEM' should be set to LDAP (or KRB5LDAP). Can you show how you configured the AIX client? -- / Alexander Bokovoy From jpazdziora at redhat.com Tue Mar 24 16:58:23 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Tue, 24 Mar 2015 17:58:23 +0100 Subject: [Freeipa-users] Fedora 20 upstream repo ipa-server-install fails Message-ID: <20150324165822.GA17848@redhat.com> Hello, after enabling https://copr.fedoraproject.org/coprs/mkosek/freeipa/repo/fedora-20/mkosek-freeipa-fedora-20.repo I've installed freeipa-server bind bind-dyndb-ldap and run ipa-server-install --domain example.test The process failed at [3/7]: setting up kerberos principal [4/7]: setting up SoftHSM [error] CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' returned non-zero exit status 1 Unexpected error - see /var/log/ipaserver-install.log for details: CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' returned non-zero exit status 1 and the log file ends with 2015-03-24T16:49:51Z DEBUG Saving SO PIN to /etc/ipa/dnssec/softhsm_pin_so 2015-03-24T16:49:51Z DEBUG Initializing tokens 2015-03-24T16:49:51Z DEBUG Starting external process 2015-03-24T16:49:51Z DEBUG args='/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX 2015-03-24T16:49:51Z DEBUG Process finished, return code=1 2015-03-24T16:49:51Z DEBUG stdout= 2015-03-24T16:49:51Z DEBUG stderr=ERROR: Could not load the library. 2015-03-24T16:49:51Z 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/dnskeysyncinstance.py", line 293, in __setup_softhsm ipautil.run(command, nolog=(pin, pin_so,)) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, in run raise CalledProcessError(p.returncode, arg_string, stdout) CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' returned non-zero exit status 1 2015-03-24T16:49:51Z DEBUG [error] CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' returned non-zero exit status 1 2015-03-24T16:49:51Z DEBUG File "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line 642, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1302, in main dnskeysyncd.create_instance(api.env.host, api.env.realm) File "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", line 146, in create_instance self.start_creation() 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/dnskeysyncinstance.py", line 293, in __setup_softhsm ipautil.run(command, nolog=(pin, pin_so,)) File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, in run raise CalledProcessError(p.returncode, arg_string, stdout) 2015-03-24T16:49:51Z DEBUG The ipa-server-install command failed, exception: CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' returned non-zero exit status 1 I've found discussion at https://www.redhat.com/archives/freeipa-users/2014-October/msg00362.html which seems related but it seems the issue is back or was never properly addressed. Attempt to run the command manually fails as well: # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf /usr/bin/softhsm2-util '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX ERROR: Could not load the library. I see the same bug both on host and in container. -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From bobby.prins at proxy.nl Tue Mar 24 17:03:31 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Tue, 24 Mar 2015 18:03:31 +0100 (CET) Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150324162308.GU3878@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> <20150324162308.GU3878@redhat.com> Message-ID: <500125243.595017.1427216611557.JavaMail.zimbra@proxy.nl> >----- Oorspronkelijk bericht ----- >Van: "Alexander Bokovoy" >Aan: "Bobby Prins" >Cc: dpal at redhat.com, freeipa-users at redhat.com >Verzonden: Dinsdag 24 maart 2015 17:23:08 >Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode > >On Tue, 24 Mar 2015, Bobby Prins wrote: >>>----- Oorspronkelijk bericht ----- >>>Van: "Alexander Bokovoy" >>>Aan: "Bobby Prins" >>>Cc: dpal at redhat.com, freeipa-users at redhat.com >>>Verzonden: Dinsdag 24 maart 2015 15:13:38 >>>Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>> >>>On Tue, 24 Mar 2015, Bobby Prins wrote: >>>>>----- Oorspronkelijk bericht ----- >>>>>Van: "Alexander Bokovoy" >>>>>Aan: "Bobby Prins" >>>>>Cc: dpal at redhat.com, freeipa-users at redhat.com >>>>>Verzonden: Maandag 23 maart 2015 16:44:47 >>>>>Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>>>> >>>>>... >>>>> >>>>>Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>>>and sssd logs from IPA master (with debug_level = 10) at least in >>>>>[domain], [nss], and [pam] sections. >>>>> >>>>>You need to filter dirsrv logs by connection coming from AIX IP address >>>>>and then by conn= where number is the same number as the one >>>>>with IP address line. >>>>> >>>>>When authenticating, AIX would talk to IPA LDAP server to compat tree >>>>>and slapi-nis plugin which serves compat tree would do PAM >>>>>authentication as service system-auth where SSSD on IPA master will do >>>>>the actual authentication work. >>>>> >>>>>-- >>>>>/ Alexander Bokovoy >>>> >>>>Here you can see the DS connection from AIX: >>>>[24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>>>[24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>>>[24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>>>[24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >>>> >>>>As you can see it also takes quite some time to process the login. >>>>Could that be a problem? >>>24 seconds sounds like bprins2example.com is a member of few groups with >>>big amount of members. On the other hand, BIND operation result is 0 >>>(success) and it doesn't look like AIX dropped the connection, at least >>>there is no ABANDON within the context of this connection so AIX did not >>>cancel the request by itself. >>> >>>How long does it take on AIX side to report the inability to login? Is >>>this time longer or shorter the one reported in etime= value on RESULT >>>line above? >>> >>>>The SSSD log files are a bit large with debug_level set to 10 and it >>>>will take me some time to strip all customer data from it. Any log >>>>events in particular you would like to see? >>>https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for >>>some times of issues you might find in the SSSD logs. I'd be interested >>>in "Common AD provider issues", "Troubleshooting authentication, >>>password change and access control". >>> >>>-- >>>/ Alexander Bokovoy >> >>The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. >> >>I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. >> >>PAM logging on AIX: >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate >>Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed >>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() >>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt >>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user >>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed >>Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER >> >>Doing a ldapsearch with bprins at example.corp as bind user works without any problems. >According to the log above you get failure from pam_aix which should be >expected if pam_aix doesn't think that the user in question is coming >from LDAP. > >Can you show output of > >lsuser -R LDAP bprins at example.corp >lsuser -a registry SYSTEM bprins at example.corp > >The attributes 'registry' and 'SYSTEM' should be set to LDAP (or KRB5LDAP). > >Can you show how you configured the AIX client? > >-- >/ Alexander Bokovoy lsuser -R LDAP bprins at example.corp: bprins at example.corp id=211623277 pgrp=bprins at example.corp groups=bprins at example.corp home=/home/example.corp/bprins shell=/bin/bash gecos=Bobby Prins login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=LDAP SYSTEM=LDAP logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minloweralpha=0 minupperalpha=0 minother=0 mindigit=0 minspecialchar=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=8388604 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles= lsuser -a registry SYSTEM bprins at example.corp: bprins at example.corp registry=LDAP SYSTEM=LDAP Contents of /etc/security/ldap/ldap.cfg: ldapservers:idm01.unix.example.corp authtype:ldap_auth useSSL:no userattrmappath:/etc/security/ldap/IPAuser.map groupattrmappath:/etc/security/ldap/IPAgroup.map userbasedn:cn=users,cn=compat,dc=unix,dc=example,dc=corp groupbasedn:cn=groups,cn=compat,dc=unix,dc=example,dc=corp userclasses:posixaccount groupclasses:posixgroup ldapport:389 searchmode:ALL defaultentrylocation:LDAP serverschematype:rfc2307 Map file /etc/security/ldap/IPAuser.map: #IPAuser.map file keyobjectclass SEC_CHAR posixaccount s # The following attributes are required by AIX to be functional username SEC_CHAR uid s id SEC_INT uidnumber s pgrp SEC_CHAR gidnumber s home SEC_CHAR homedirectory s shell SEC_CHAR loginshell s gecos SEC_CHAR gecos s spassword SEC_CHAR userpassword s lastupdate SEC_INT shadowlastchange s Map file /etc/security/ldap/IPAgroup.map: #IPAgroup.map file groupname SEC_CHAR cn s id SEC_INT gidNumber s users SEC_LIST member m With the current setup users created on the IPA server work, AD users not. From bentech4you at gmail.com Tue Mar 24 17:15:21 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 24 Mar 2015 20:15:21 +0300 Subject: [Freeipa-users] how can i give set of users to one particular host In-Reply-To: <551169C8.1030005@redhat.com> References: <551169C8.1030005@redhat.com> Message-ID: Hi current stage is AD users can able to login to solaris box. But i don't up to what level i can control the user. i don't think to there is much pan modules in solaris. still i cannot able to make home directory with pam. On Tue, Mar 24, 2015 at 4:42 PM, Dmitri Pal wrote: > On 03/24/2015 07:20 AM, Ben .T.George wrote: > > HI > > i am using IPA 3.3 and my client is solaris 10. > > how can i give only some set of users to this client without creating > user group in ad? > > thanks & Regards, > Ben > > > > You can create a group in IPA and make Solaris check that group at the > access phase of PAM if Solaris is capable of checking groups this way. > > -- > 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 abokovoy at redhat.com Tue Mar 24 17:42:26 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 24 Mar 2015 19:42:26 +0200 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <500125243.595017.1427216611557.JavaMail.zimbra@proxy.nl> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> <20150324162308.GU3878@redhat.com> <500125243.595017.1427216611557.JavaMail.zimbra@proxy.nl> Message-ID: <20150324174226.GW3878@redhat.com> On Tue, 24 Mar 2015, Bobby Prins wrote: >>>The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. >>> >>>I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. >>> >>>PAM logging on AIX: >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >>>Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate >>>Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >>>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed >>>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >>>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() >>>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >>>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt >>>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user >>>Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed >>>Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER >>> >>>Doing a ldapsearch with bprins at example.corp as bind user works without any problems. >>According to the log above you get failure from pam_aix which should be >>expected if pam_aix doesn't think that the user in question is coming >>from LDAP. >> >>Can you show output of >> >>lsuser -R LDAP bprins at example.corp >>lsuser -a registry SYSTEM bprins at example.corp >> >>The attributes 'registry' and 'SYSTEM' should be set to LDAP (or KRB5LDAP). >> >>Can you show how you configured the AIX client? >> >>-- >>/ Alexander Bokovoy > >lsuser -R LDAP bprins at example.corp: >bprins at example.corp id=211623277 pgrp=bprins at example.corp groups=bprins at example.corp home=/home/example.corp/bprins shell=/bin/bash gecos=Bobby Prins login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=LDAP SYSTEM=LDAP logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minloweralpha=0 minupperalpha=0 minother=0 mindigit=0 minspecialchar=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=8388604 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles= I assume you have /bin/bash installed on AIX? This user has shell defined as /bin/bash and if it is missing, login or ssh will deny its access to the system. > >lsuser -a registry SYSTEM bprins at example.corp: >bprins at example.corp registry=LDAP SYSTEM=LDAP > >Contents of /etc/security/ldap/ldap.cfg: >ldapservers:idm01.unix.example.corp >authtype:ldap_auth >useSSL:no >userattrmappath:/etc/security/ldap/IPAuser.map >groupattrmappath:/etc/security/ldap/IPAgroup.map >userbasedn:cn=users,cn=compat,dc=unix,dc=example,dc=corp >groupbasedn:cn=groups,cn=compat,dc=unix,dc=example,dc=corp >userclasses:posixaccount >groupclasses:posixgroup >ldapport:389 >searchmode:ALL >defaultentrylocation:LDAP >serverschematype:rfc2307 > >Map file /etc/security/ldap/IPAuser.map: >#IPAuser.map file >keyobjectclass SEC_CHAR posixaccount s > ># The following attributes are required by AIX to be functional >username SEC_CHAR uid s >id SEC_INT uidnumber s >pgrp SEC_CHAR gidnumber s >home SEC_CHAR homedirectory s >shell SEC_CHAR loginshell s >gecos SEC_CHAR gecos s >spassword SEC_CHAR userpassword s >lastupdate SEC_INT shadowlastchange s > >Map file /etc/security/ldap/IPAgroup.map: >#IPAgroup.map file >groupname SEC_CHAR cn s >id SEC_INT gidNumber s >users SEC_LIST member m > >With the current setup users created on the IPA server work, AD users not. The rest of configuration looks fine. Given that PAM debug output mentions pam_aix, can you show /etc/pam.conf and /etc/security/login.cfg. I suspect that you have auth_type=PAM_AUTH in /etc/security/login.cfg, that's why PAM authentication is in use and pam_aix should theoretically pick up LDAP via LAM mechanism. -- / Alexander Bokovoy From dpal at redhat.com Tue Mar 24 17:57:27 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 13:57:27 -0400 Subject: [Freeipa-users] how can i give set of users to one particular host In-Reply-To: References: <551169C8.1030005@redhat.com> Message-ID: <5511A587.1040101@redhat.com> On 03/24/2015 01:15 PM, Ben .T.George wrote: > Hi > > current stage is AD users can able to login to solaris box. But i > don't up to what level i can control the user. > > i don't think to there is much pan modules in solaris. still i cannot > able to make home directory with pam. I think pam_groupdn (if available on Solaris) might help but I could not find a clear example to share with you here. > > > > On Tue, Mar 24, 2015 at 4:42 PM, Dmitri Pal > wrote: > > On 03/24/2015 07:20 AM, Ben .T.George wrote: >> HI >> >> i am using IPA 3.3 and my client is solaris 10. >> >> how can i give only some set of users to this client without >> creating user group in ad? >> >> thanks & Regards, >> Ben >> >> > > You can create a group in IPA and make Solaris check that group at > the access phase of PAM if Solaris is capable of checking groups > this way. > > -- > 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 rcritten at redhat.com Tue Mar 24 18:03:24 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Mar 2015 14:03:24 -0400 Subject: [Freeipa-users] how can i give set of users to one particular host In-Reply-To: <5511A587.1040101@redhat.com> References: <551169C8.1030005@redhat.com> <5511A587.1040101@redhat.com> Message-ID: <5511A6EC.8050002@redhat.com> Dmitri Pal wrote: > On 03/24/2015 01:15 PM, Ben .T.George wrote: >> Hi >> >> current stage is AD users can able to login to solaris box. But i >> don't up to what level i can control the user. >> >> i don't think to there is much pan modules in solaris. still i cannot >> able to make home directory with pam. > > I think pam_groupdn (if available on Solaris) might help but I could not > find a clear example to share with you here. I'd suggest looking at pam_access. rob > >> >> >> >> On Tue, Mar 24, 2015 at 4:42 PM, Dmitri Pal > > wrote: >> >> On 03/24/2015 07:20 AM, Ben .T.George wrote: >>> HI >>> >>> i am using IPA 3.3 and my client is solaris 10. >>> >>> how can i give only some set of users to this client without >>> creating user group in ad? >>> >>> thanks & Regards, >>> Ben >>> >>> >> >> You can create a group in IPA and make Solaris check that group at >> the access phase of PAM if Solaris is capable of checking groups >> this way. >> >> -- >> 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 bentech4you at gmail.com Tue Mar 24 18:05:00 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Tue, 24 Mar 2015 21:05:00 +0300 Subject: [Freeipa-users] how can i give set of users to one particular host In-Reply-To: <5511A6EC.8050002@redhat.com> References: <551169C8.1030005@redhat.com> <5511A587.1040101@redhat.com> <5511A6EC.8050002@redhat.com> Message-ID: please anyone share bit more information on this like real example On Tue, Mar 24, 2015 at 9:03 PM, Rob Crittenden wrote: > Dmitri Pal wrote: > > On 03/24/2015 01:15 PM, Ben .T.George wrote: > >> Hi > >> > >> current stage is AD users can able to login to solaris box. But i > >> don't up to what level i can control the user. > >> > >> i don't think to there is much pan modules in solaris. still i cannot > >> able to make home directory with pam. > > > > I think pam_groupdn (if available on Solaris) might help but I could not > > find a clear example to share with you here. > > I'd suggest looking at pam_access. > > rob > > > > >> > >> > >> > >> On Tue, Mar 24, 2015 at 4:42 PM, Dmitri Pal >> > wrote: > >> > >> On 03/24/2015 07:20 AM, Ben .T.George wrote: > >>> HI > >>> > >>> i am using IPA 3.3 and my client is solaris 10. > >>> > >>> how can i give only some set of users to this client without > >>> creating user group in ad? > >>> > >>> thanks & Regards, > >>> Ben > >>> > >>> > >> > >> You can create a group in IPA and make Solaris check that group at > >> the access phase of PAM if Solaris is capable of checking groups > >> this way. > >> > >> -- > >> 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 rcritten at redhat.com Tue Mar 24 18:19:16 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Mar 2015 14:19:16 -0400 Subject: [Freeipa-users] how can i give set of users to one particular host In-Reply-To: References: <551169C8.1030005@redhat.com> <5511A587.1040101@redhat.com> <5511A6EC.8050002@redhat.com> Message-ID: <5511AAA4.5040408@redhat.com> Ben .T.George wrote: > please anyone share bit more information on this like real example As we've said many times before, we have very little real experience on Solaris. We do the best we can and sometimes that is going to be in the form of bread crumbs that may be usable to finding your way to a solution. Access control via PAM is a very-well understood problem on Solaris. Once you have users and groups via nss then IPA is largely out of the equation. The OS vendor or Solaris-specific groups will know how to do this far better than us. If you find a detailed answer I'd be happy to add it to the freeIPA wiki. rob > > On Tue, Mar 24, 2015 at 9:03 PM, Rob Crittenden > wrote: > > Dmitri Pal wrote: > > On 03/24/2015 01:15 PM, Ben .T.George wrote: > >> Hi > >> > >> current stage is AD users can able to login to solaris box. But i > >> don't up to what level i can control the user. > >> > >> i don't think to there is much pan modules in solaris. still i cannot > >> able to make home directory with pam. > > > > I think pam_groupdn (if available on Solaris) might help but I could not > > find a clear example to share with you here. > > I'd suggest looking at pam_access. > > rob > > > > >> > >> > >> > >> On Tue, Mar 24, 2015 at 4:42 PM, Dmitri Pal > >> >> wrote: > >> > >> On 03/24/2015 07:20 AM, Ben .T.George wrote: > >>> HI > >>> > >>> i am using IPA 3.3 and my client is solaris 10. > >>> > >>> how can i give only some set of users to this client without > >>> creating user group in ad? > >>> > >>> thanks & Regards, > >>> Ben > >>> > >>> > >> > >> You can create a group in IPA and make Solaris check that > group at > >> the access phase of PAM if Solaris is capable of checking groups > >> this way. > >> > >> -- > >> 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 bobby.prins at proxy.nl Tue Mar 24 18:52:02 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Tue, 24 Mar 2015 19:52:02 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150324174226.GW3878@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> <20150324162308.GU3878@redhat.com> <500125243.595017.1427216611557.JavaMail.zimbra@proxy.nl> <20150324174226.GW3878@redhat.com> Message-ID: <97685AA2-FA4F-4843-ADA9-B59436BA1F5A@proxy.nl> > On Mar 24, 2015, at 18:42, Alexander Bokovoy wrote: > > On Tue, 24 Mar 2015, Bobby Prins wrote: >>>> The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. >>>> >>>> I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. >>>> >>>> PAM logging on AIX: >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >>>> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate >>>> Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >>>> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed >>>> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >>>> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() >>>> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >>>> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt >>>> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user >>>> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed >>>> Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER >>>> >>>> Doing a ldapsearch with bprins at example.corp as bind user works without any problems. >>> According to the log above you get failure from pam_aix which should be >>> expected if pam_aix doesn't think that the user in question is coming >>> from LDAP. >>> >>> Can you show output of >>> >>> lsuser -R LDAP bprins at example.corp >>> lsuser -a registry SYSTEM bprins at example.corp >>> >>> The attributes 'registry' and 'SYSTEM' should be set to LDAP (or KRB5LDAP). >>> >>> Can you show how you configured the AIX client? >>> >>> -- >>> / Alexander Bokovoy >> >> lsuser -R LDAP bprins at example.corp: >> bprins at example.corp id=211623277 pgrp=bprins at example.corp groups=bprins at example.corp home=/home/example.corp/bprins shell=/bin/bash gecos=Bobby Prins login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=22 registry=LDAP SYSTEM=LDAP logintimes= loginretries=0 pwdwarntime=0 account_locked=false minage=0 maxage=0 maxexpired=-1 minalpha=0 minloweralpha=0 minupperalpha=0 minother=0 mindigit=0 minspecialchar=0 mindiff=0 maxrepeats=8 minlen=0 histexpire=0 histsize=0 pwdchecks= dictionlist= default_roles= fsize=8388604 cpu=-1 data=262144 stack=65536 core=2097151 rss=65536 nofiles=2000 roles= > I assume you have /bin/bash installed on AIX? This user has shell > defined as /bin/bash and if it is missing, login or ssh will deny its > access to the system. Yes, bash is a valid shell on this machine and also in use by local and IPA users. > >> >> lsuser -a registry SYSTEM bprins at example.corp: >> bprins at example.corp registry=LDAP SYSTEM=LDAP >> >> Contents of /etc/security/ldap/ldap.cfg: >> ldapservers:idm01.unix.example.corp >> authtype:ldap_auth >> useSSL:no >> userattrmappath:/etc/security/ldap/IPAuser.map >> groupattrmappath:/etc/security/ldap/IPAgroup.map >> userbasedn:cn=users,cn=compat,dc=unix,dc=example,dc=corp >> groupbasedn:cn=groups,cn=compat,dc=unix,dc=example,dc=corp >> userclasses:posixaccount >> groupclasses:posixgroup >> ldapport:389 >> searchmode:ALL >> defaultentrylocation:LDAP >> serverschematype:rfc2307 >> >> Map file /etc/security/ldap/IPAuser.map: >> #IPAuser.map file >> keyobjectclass SEC_CHAR posixaccount s >> >> # The following attributes are required by AIX to be functional >> username SEC_CHAR uid s >> id SEC_INT uidnumber s >> pgrp SEC_CHAR gidnumber s >> home SEC_CHAR homedirectory s >> shell SEC_CHAR loginshell s >> gecos SEC_CHAR gecos s >> spassword SEC_CHAR userpassword s >> lastupdate SEC_INT shadowlastchange s >> >> Map file /etc/security/ldap/IPAgroup.map: >> #IPAgroup.map file >> groupname SEC_CHAR cn s >> id SEC_INT gidNumber s >> users SEC_LIST member m >> >> With the current setup users created on the IPA server work, AD users not. > The rest of configuration looks fine. Given that PAM debug output > mentions pam_aix, can you show /etc/pam.conf and > /etc/security/login.cfg. I suspect that you have auth_type=PAM_AUTH in > /etc/security/login.cfg, that's why PAM authentication is in use and > pam_aix should theoretically pick up LDAP via LAM mechanism. > -- > / Alexander Bokovoy Contents of pam.conf: ... # # Authentication # authexec auth required pam_aix dtaction auth required pam_aix dtsession auth required pam_aix dtlogin auth required pam_aix ftp auth required pam_aix imap auth required pam_aix login auth required pam_aix rexec auth required pam_aix rlogin auth sufficient pam_rhosts_auth rlogin auth required pam_aix rsh auth required pam_rhosts_auth snapp auth required pam_aix su auth sufficient pam_allowroot su auth required pam_aix swrole auth required pam_aix telnet auth required pam_aix xdm auth required pam_aix sshd auth required pam_aix OTHER auth required pam_prohibit # # Account Management # authexec account required pam_aix dtlogin account required pam_aix ftp account required pam_aix login account required pam_aix rexec account required pam_aix rlogin account required pam_aix rsh account required pam_aix su account sufficient pam_allowroot su account required pam_aix swrole account required pam_aix telnet account required pam_aix xdm account required pam_aix sshd account required pam_aix OTHER account required pam_prohibit # # Password Management # authexec password required pam_aix dtlogin password required pam_aix login password required pam_aix passwd password required pam_aix rlogin password required pam_aix su password required pam_aix telnet password required pam_aix xdm password required pam_aix sshd password required pam_aix OTHER password required pam_prohibit # # Session Management # dtlogin session required pam_aix ftp session required pam_aix imap session required pam_aix login session required pam_aix rexec session required pam_aix rlogin session required pam_aix rsh session required pam_aix snapp session required pam_aix su session required pam_aix swrole session required pam_aix telnet session required pam_aix xdm session required pam_aix sshd session required pam_aix OTHER session required pam_prohibit Contents of login.cfg: ? usw: shells = /bin/sh,/bin/bsh,/bin/csh,/bin/ksh,/bin/tsh,/bin/ksh93,/usr/bin/sh,/usr/bin/bsh,/usr/bin/csh,/usr/bin/ksh,/usr/bin/tsh,/usr/bin/ksh93,/usr/bin/rksh,/usr/bin/rksh93,/usr/sbin/uucp/uucico,/usr/sbin/sliplogin,/usr/sbin/snappd,/bin/bash maxlogins = 32767 logintimeout = 60 maxroles = 8 auth_type = PAM_AUTH So you were correct about using PAM_AUTH. I?m thinking about logging a support case with IBM for this PAM behavior. From bobby.prins at proxy.nl Tue Mar 24 18:59:14 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Tue, 24 Mar 2015 19:59:14 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <55118CA8.3080507@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> <55118CA8.3080507@redhat.com> Message-ID: > On Mar 24, 2015, at 17:11, Dmitri Pal wrote: > > On 03/24/2015 11:45 AM, Bobby Prins wrote: >>> ----- Oorspronkelijk bericht ----- >>> Van: "Alexander Bokovoy" >>> Aan: "Bobby Prins" >>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>> Verzonden: Dinsdag 24 maart 2015 15:13:38 >>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>> >>> On Tue, 24 Mar 2015, Bobby Prins wrote: >>>>> ----- Oorspronkelijk bericht ----- >>>>> Van: "Alexander Bokovoy" >>>>> Aan: "Bobby Prins" >>>>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>>>> Verzonden: Maandag 23 maart 2015 16:44:47 >>>>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>>>> >>>>> ... >>>>> >>>>> Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>>> and sssd logs from IPA master (with debug_level = 10) at least in >>>>> [domain], [nss], and [pam] sections. >>>>> >>>>> You need to filter dirsrv logs by connection coming from AIX IP address >>>>> and then by conn= where number is the same number as the one >>>>> with IP address line. >>>>> >>>>> When authenticating, AIX would talk to IPA LDAP server to compat tree >>>>> and slapi-nis plugin which serves compat tree would do PAM >>>>> authentication as service system-auth where SSSD on IPA master will do >>>>> the actual authentication work. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>> Here you can see the DS connection from AIX: >>>> [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>>> [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>>> [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>>> [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >>>> >>>> As you can see it also takes quite some time to process the login. >>>> Could that be a problem? >>> 24 seconds sounds like bprins2example.com is a member of few groups with >>> big amount of members. On the other hand, BIND operation result is 0 >>> (success) and it doesn't look like AIX dropped the connection, at least >>> there is no ABANDON within the context of this connection so AIX did not >>> cancel the request by itself. >>> >>> How long does it take on AIX side to report the inability to login? Is >>> this time longer or shorter the one reported in etime= value on RESULT >>> line above? >>> >>>> The SSSD log files are a bit large with debug_level set to 10 and it >>>> will take me some time to strip all customer data from it. Any log >>>> events in particular you would like to see? >>> https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for >>> some times of issues you might find in the SSSD logs. I'd be interested >>> in "Common AD provider issues", "Troubleshooting authentication, >>> password change and access control". >>> >>> -- >>> / Alexander Bokovoy >> The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. >> >> I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. >> >> PAM logging on AIX: >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate >> Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed > > Seems like 15 sec timeout on the AIX side. > Can you try with a user that does not have that many groups and see if that works? > If it does then we should assume it is an AIX side timeout and focus on making sure the data gets over to IPA within this timeout. I?ll try that tomorrow as I was not able to contact a Windows admin who can create a test account for me. The time it takes to throw the pam_authenticate error is not always 15 seconds though. It ranges between 13 and 26 seconds doing some tests just now. > >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed >> Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER >> >> Doing a ldapsearch with bprins at example.corp as bind user works without any problems. > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. From bobby.prins at proxy.nl Tue Mar 24 19:10:43 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Tue, 24 Mar 2015 20:10:43 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <20150324161710.GS2989@hendrix.redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> <20150324161710.GS2989@hendrix.redhat.com> Message-ID: > On Mar 24, 2015, at 17:17, Jakub Hrozek wrote: > > On Tue, Mar 24, 2015 at 04:45:53PM +0100, Bobby Prins wrote: >>> ----- Oorspronkelijk bericht ----- >>> Van: "Alexander Bokovoy" >>> Aan: "Bobby Prins" >>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>> Verzonden: Dinsdag 24 maart 2015 15:13:38 >>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>> >>> On Tue, 24 Mar 2015, Bobby Prins wrote: >>>>> ----- Oorspronkelijk bericht ----- >>>>> Van: "Alexander Bokovoy" >>>>> Aan: "Bobby Prins" >>>>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>>>> Verzonden: Maandag 23 maart 2015 16:44:47 >>>>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>>>> >>>>> ... >>>>> >>>>> Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>>> and sssd logs from IPA master (with debug_level = 10) at least in >>>>> [domain], [nss], and [pam] sections. >>>>> >>>>> You need to filter dirsrv logs by connection coming from AIX IP address >>>>> and then by conn= where number is the same number as the one >>>>> with IP address line. >>>>> >>>>> When authenticating, AIX would talk to IPA LDAP server to compat tree >>>>> and slapi-nis plugin which serves compat tree would do PAM >>>>> authentication as service system-auth where SSSD on IPA master will do >>>>> the actual authentication work. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>> >>>> Here you can see the DS connection from AIX: >>>> [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>>> [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>>> [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>>> [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >>>> >>>> As you can see it also takes quite some time to process the login. >>>> Could that be a problem? >>> 24 seconds sounds like bprins2example.com is a member of few groups with >>> big amount of members. On the other hand, BIND operation result is 0 >>> (success) and it doesn't look like AIX dropped the connection, at least >>> there is no ABANDON within the context of this connection so AIX did not >>> cancel the request by itself. >>> >>> How long does it take on AIX side to report the inability to login? Is >>> this time longer or shorter the one reported in etime= value on RESULT >>> line above? >>> >>>> The SSSD log files are a bit large with debug_level set to 10 and it >>>> will take me some time to strip all customer data from it. Any log >>>> events in particular you would like to see? >>> https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for >>> some times of issues you might find in the SSSD logs. I'd be interested >>> in "Common AD provider issues", "Troubleshooting authentication, >>> password change and access control". >>> >>> -- >>> / Alexander Bokovoy >> >> The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. >> >> I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. > > I guess what Alexander meant (in a very simplified way) was that the 'id' > command could take a long time. Sumit recently fixed two nasty issues that > would make this operation take too long with POSIX attributes in effect > and also that the initgroups operation might be done too frequently with > SSH. I wonder if you might be seeing this issue, the SSSD logs capturing > the login on the server side would help. Yeah, I noticed the other thread about slow logins a couple of days ago. The ?id? command takes 5 to 10 seconds on the IPA server for a couple of accounts I tested with (50 to 60 group memberships, some with a lot of/300+ members). I?m not using 'Identity Management for UNIX? on Windows if that?s what you mean. I?ll try to clean up (read: remove customer data) the SSSD logs a bit tomorrow so I can post them. > >> >> PAM logging on AIX: >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate >> Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed >> Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER >> >> Doing a ldapsearch with bprins at example.corp as bind user works without any problems. >> >> -- >> Manage your subscription for the Freeipa-users mailing list: >> https://www.redhat.com/mailman/listinfo/freeipa-users >> Go to http://freeipa.org for more info on the project > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project From jhrozek at redhat.com Tue Mar 24 19:36:43 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Tue, 24 Mar 2015 20:36:43 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: References: <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> <20150324161710.GS2989@hendrix.redhat.com> Message-ID: <20150324193643.GX2989@hendrix.redhat.com> On Tue, Mar 24, 2015 at 08:10:43PM +0100, Bobby Prins wrote: > > I guess what Alexander meant (in a very simplified way) was that the 'id' > > command could take a long time. Sumit recently fixed two nasty issues that > > would make this operation take too long with POSIX attributes in effect > > and also that the initgroups operation might be done too frequently with > > SSH. I wonder if you might be seeing this issue, the SSSD logs capturing > > the login on the server side would help. > Yeah, I noticed the other thread about slow logins a couple of days ago. The ?id? command takes 5 to 10 seconds on the IPA server for a couple of accounts I tested with (50 to 60 group memberships, some with a lot of/300+ members). I?m not using 'Identity Management for UNIX? on Windows if that?s what you mean. I?ll try to clean up (read: remove customer data) the SSSD logs a bit tomorrow so I can post them. Ah, thank you, then it's unlikely either of the two bugs affect you. From sipazzo at yahoo.com Tue Mar 24 20:20:42 2015 From: sipazzo at yahoo.com (sipazzo) Date: Tue, 24 Mar 2015 20:20:42 +0000 (UTC) Subject: [Freeipa-users] Fw: Need to replace cert for ipa servers In-Reply-To: <499575904.4226305.1426278747223.JavaMail.yahoo@mail.yahoo.com> References: <903DF15B7B9D3B4D9137A06F63687859172CC3185D@FHDP1LUMXC7V33.us.one.verizon.com> <499575904.4226305.1426278747223.JavaMail.yahoo@mail.yahoo.com> Message-ID: <1144667114.746796.1427228442473.JavaMail.yahoo@mail.yahoo.com> Ok I finally was able to get a sandbox environment up to test the cert replacement. When I ran this stepgot to the cert request steps:ipa-getcert request -d /etc/dirsrv/slapd-IPADOMAIN-COM -n Server-Cert -p /etc/dirsrv/slapd-IPADOMAIN-COM/pwdfile.txt -C '/usr/lib64/ipa/certmonger/restart_dirsrv IPADOMAIN-COM' -N CN=idm2-corp.ipadomain.com -K ldap/ipa2-corp.ipadomain.com at IPADOMAIN.COM I got a message saying the cert at same location is already used by request with nickname "20140729215511" , same when I ran it for /etc/httpd/alias. I continued on anyway but when I get to this step: ?# certutil -V -u V -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM I get an error: certutil: could not find certificate named "Server-Cert": PR_FILE_NOT_FOUND_ERROR: File not found Although running certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM/, returns this: Certificate Nickname???????????????????????????????????????? Trust Attributes ???????????????????????????????????????????????????????????? SSL,S/MIME,JAR/XPI GD_CA??????????????????????????????????????????????????????? CT,C,C IPADOMAIN.COM IPA CA????????????????????????????????????? CT,, NWF_GD?????????????????????????????????????????????????????? u,u,u Showing that the IPA Dogtag cert is now listed whereas it was not previously.? From: sipazzo To: Rob Crittenden ; "freeipa-users at redhat.com" Sent: Friday, March 13, 2015 1:32 PM Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers This environment is over 350 servers, many of which are in production so I may have to wait a bit for change management approval to attempt to resolve this issue, particularly if you think it might break something.? I will keep you updated on my progress. Thank you much. From: sipazzo To: Rob Crittenden Cc: "freeipa-users at redhat.com" Sent: Friday, March 13, 2015 9:21 AM Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers -----Original Message----- From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Rob Crittenden Sent: Thursday, March 12, 2015 1:52 PM To: sipazzo; freeipa-users at redhat.com Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers sipazzo wrote: > I do have other CAs (just not the master but it is available offline > if > needed) To be clear, all IPA servers are masters, some just run more services than others. It sounds like you have at least one CA available which should be sufficient. > Directory server is running > The apache web server is running and I can get to the gui ipa > cert-show 1 works Ok. I guess the place to start is to get certs for Apache and 389-ds, then we can see about using these new certs. In the thread you showed that the IPA 389-ds doesn't have a Server-Cert nickname. You'll want to do the same for /etc/httpd/alias before running the following commands otherwise you could end up with non-functional server. These should get IPA certs for 389-ds and Apache. You'll need to edit these commands to match your environment: # ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p /etc/httpd/alias/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_httpd -N CN=ipa.example.com -K HTTP/ipa.example.com at EXAMPLE.COM # ipa-getcert request -d /etc/dirsrv/slapd-EXAMPLE-COM -n Server-Cert -p /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt -C '/usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM' -N CN=ipa.example.com -K ldap/ipa.example.com at EXAMPLE.COM I'd do them one at a time and wait until the cert is issued and tracked. This will restart both Apache and 389-ds but it shouldn't affect operation because the certs won't be used yet. You then need to get the old CA cert and put it into the right places. Since it is already in the PKI-IPA NSS database let's fetch it from there. For giggles you should probably save whatever the contents of /etc/ipa/ca.crt are before-hand. # certutil -L -d /etc/dirsrv/slapd-PKI-IPA -n 'IPADOMAIN.COM IPA CA' -a > /etc/ipa/ca.crt Now add that to the Apache and 389-ds databases: # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/httpd/alias -t CT,C, -a -i /etc/ipa/ca.crt # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/dirsrv/slapd-EXAMPLE-COM -t CT,, -a -i /etc/ipa/ca.crt Next add it to /etc/pki/nssdb if it isn't already there: # certutil -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i /etc/ipa/ca.crt Next, verify that the newly issued certs are trusted: # certutil -V -u V -n Server-Cert -d /etc/httpd/alias # certutil -V -u V -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM Both should return: certutil: certificate is valid Next is to configure the services to use the new certs. I'd stop IPA to do this: ipactl stop Edit /etc/httpd/conf.d/nss.conf and change the NSSNickname to Server-Cert Edit /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif and set nsSSLPersonalitySSL to Server-Cert Now try to start the world: ipactl start Run a few commands: # ipa user-show admin # ipa cert-show 1 Both should work. Assuming all has gone well to this point, copy /etc/ipa/ca.crt to /usr/share/ipa/html/ca.crt Finally run: ipa-ldap-updater --upgrade This should load the new CA certificate into LDAP. This has the potential to break a whole bunch of your clients. It is probably enough to just copy over the new CA cert to the right location(s) on the clients. The mechanics of this depend on the OS. > Are the TLS errors due to the mismatch in certs between slapd-PKI-CA > and slapd-NETWORKFLEET-COM? No, has nothing to do with the CA at all. The client doesn't have (or trust) the CA that issued the LDAP server cert. rob > > > -----Original Message----- > > > From: freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com > ] On Behalf Of Rob Crittenden > Sent: Wednesday, March 11, 2015 7:20 PM > To: sipazzo; freeipa-users at redhat.com > > Subject: Re: [Freeipa-users] Need to replace cert for ipa servers > > sipazzo wrote: >> Thanks Rob, I apologize that error was probably not helpful. This is >> what I see when running install in debug mode: >> >> Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an >> IPA server Init LDAP connection with: >> ldap://ipa2-corp.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >> server Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 >> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >> is not recognized. >> >> The certificates are very confusing to me. I don't understand how >> things are working when we have a set of GoDaddy certs in >> slapd-NETWORKFLEET-COM and a set of the Dogtag certs in slapd-PKI-CA. >> The cert in /usr/share/ipa/html/ca.crt looks like the original one >> issued by the Dogtag cert system and matches the ones on the clients. >> Not to further confuse things but the original master server that >> signed all these certs was taken offline months ago due to some >> issues it was having. I do still have access to it if necessary. >> >> As far as why the godaddy certs were swapped out for the Dogtag certs >> it was originally for something as simple as the untrusted >> certificate dialogue when accessing the ipa gui. I did not swap out >> the certs so am unsure of exactly what happened. There is no real >> need to use the GoDaddy certs as far as I am concerned. I just want >> the best solution to the issues I am seeing as I am in kind of a bind >> with the GoDaddy cert being revoked and needing to be replaced and >> the master Dogtag certificate server offline. We have a mixed >> environment with Rhel 5, 6 and Solaris clients so are not using sssd in all cases. >> >> I know this is asking a lot but appreciate any help you can give. > > What is the current state of things? Does your IPA Apache server work? > Is 389-ds up and running? Do you have a working IPA CA? > > Does ipa cert-show 1 work? > > If the answer is yes to all then we should be able to generate new > certs for all the services. > > 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 > -- 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 guertin at middlebury.edu Tue Mar 24 21:08:19 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Tue, 24 Mar 2015 21:08:19 +0000 Subject: [Freeipa-users] Clients are reading AD info inconsistently Message-ID: I have three IPA servers set up (master and two replicas) and they're all behaving normally. AD users can log in, AD group restrictions are honored, etc. Now I'm trying to set up clients, and running into problems. I have three clients set up, and all three behave differently. On one of the clients, users can log in like they can on the servers. On the other two, users can't log in, but these two behave differently from each other. Client 1 and servers (this is correct): # id 'MIDD\juser' uid=435021613(juser at middlebury.edu) gid=435021613(juser at middlebury.edu) groups=435021613(juser at middlebury.edu),435330225(computer science lab login at middlebury.edu),435231589(fmp_ms_eventschedule_users at middlebury.edu),435208664(miis labfiles everyone at middlebury.edu),435032463(mcms no rights at middlebury.edu),435000513(domain users at middlebury.edu),435286826(netoperators at middlebury.edu),435461517(ipa users at middlebury.edu) Client 2 (AD groups are not listed): # id 'MIDD\juser' uid=435021613(juser at middlebury.edu) gid=435021613(juser at middlebury.edu) groups=435021613(juser at middlebury.edu) Client 3 (user not found): # id 'MIDD\juser' id: MIDD\juser: No such user On each client I have cleared the sssd cache (rm -f /var/lib/sss/db/*) and restarted sssd, with no effect. I have also uninstalled and re-installed the client, also with no effect. What else can I try? David Guertin -------------- next part -------------- An HTML attachment was scrubbed... URL: From Steven.Jones at vuw.ac.nz Tue Mar 24 21:22:27 2015 From: Steven.Jones at vuw.ac.nz (Steven Jones) Date: Tue, 24 Mar 2015 21:22:27 +0000 Subject: [Freeipa-users] Debian 7.0.8 and REHL IPA In-Reply-To: <54E296CE.7070501@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> <1424129670344.72629@vuw.ac.nz>,<54E296CE.7070501@redhat.com> Message-ID: <1427232010574.10892@vuw.ac.nz> Hi, Anyone have experience with running the sssd client (I assume its available) on Debian 7.0.8 against a RH IPA setup? Is it painless long term or best avoided? regards Steven From mail at willsheldon.com Tue Mar 24 21:53:14 2015 From: mail at willsheldon.com (Will Sheldon) Date: Tue, 24 Mar 2015 14:53:14 -0700 Subject: [Freeipa-users] Debian 7.0.8 and REHL IPA In-Reply-To: <1427232010574.10892@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> <54E296CE.7070501@redhat.com> <1427232010574.10892@vuw.ac.nz> Message-ID: There is a ppa for ubuntu: https://code.launchpad.net/~freeipa/+archive/ubuntu/ppa and packages in the deb archives: https://packages.qa.debian.org/f/freeipa.html I?ve had mixed results using them, there seem to be frequent regressions so having a canary machine / cluster is essential.? The install script also had some issues, but I believe it?s better now? last time I tried was about 12 months ago. Will. On March 24, 2015 at 2:29:09 PM, Steven Jones (steven.jones at vuw.ac.nz) wrote: Hi, Anyone have experience with running the sssd client (I assume its available) on Debian 7.0.8 against a RH IPA setup? Is it painless long term or best avoided? regards Steven -- 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 janellenicole80 at gmail.com Tue Mar 24 22:17:22 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 24 Mar 2015 15:17:22 -0700 Subject: [Freeipa-users] ID Range question Message-ID: <5511E272.2020106@gmail.com> Hello, I have seen this pop up a few times, but no real answers - at least none that I am finding.. I have not run into it and this was a brand new server farm with about 4000 migrated users from OpenLDAP? Is there something I might be missing when migrating? ipa: ERROR: Operations error: Allocation of a new value for range cn=posix ids,cn=distributed numeric assignment plugin,cn=plugins,cn=config failed! Unable to proceed. and of course - the classic 1100 - 1101... # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config dn: cn=Posix IDs,cn=Distributed Numeric Assignment Plugin,cn=plugins,cn=config objectClass: top objectClass: extensibleObject cn: Posix IDs dnaType: uidNumber dnaType: gidNumber dnaNextValue: 1101 dnaMaxValue: 1100 dnaMagicRegen: -1 ~J From dpal at redhat.com Tue Mar 24 22:26:34 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 18:26:34 -0400 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: References: Message-ID: <5511E49A.2050101@redhat.com> On 03/24/2015 05:08 PM, Guertin, David S. wrote: > > I have three IPA servers set up (master and two replicas) and they're > all behaving normally. AD users can log in, AD group restrictions are > honored, etc. Now I'm trying to set up clients, and running into > problems. I have three clients set up, and all three behave differently. > > On one of the clients, users can log in like they can on the servers. > On the other two, users can't log in, but these two behave differently > from each other. > > Client 1 and servers (this is correct): > > # id 'MIDD\juser' > > uid=435021613(juser at middlebury.edu) > gid=435021613(juser at middlebury.edu) > groups=435021613(juser at middlebury.edu),435330225(computer science lab > login at middlebury.edu),435231589(fmp_ms_eventschedule_users at middlebury.edu),435208664(miis > labfiles everyone at middlebury.edu),435032463(mcms no > rights at middlebury.edu),435000513(domain > users at middlebury.edu),435286826(netoperators at middlebury.edu),435461517(ipausers at middlebury.edu > ) > > Client 2 (AD groups are not listed): > > # id 'MIDD\juser' > > uid=435021613(juser at middlebury.edu) > gid=435021613(juser at middlebury.edu) > groups=435021613(juser at middlebury.edu ) > > Client 3 (user not found): > > # id 'MIDD\juser' > > id: MIDD\juser: No such user > > On each client I have cleared the sssd cache (rm --f > /var/lib/sss/db/*) and restarted sssd, with no effect. I have also > uninstalled and re-installed the client, also with no effect. > > What else can I try? > > David Guertin > > > What are the platforms and package versions of SSSD on these clients? -- 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 Mar 24 22:26:58 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 24 Mar 2015 18:26:58 -0400 Subject: [Freeipa-users] ID Range question In-Reply-To: <5511E272.2020106@gmail.com> References: <5511E272.2020106@gmail.com> Message-ID: <5511E4B2.9040607@redhat.com> Janelle wrote: > Hello, > > I have seen this pop up a few times, but no real answers - at least none > that I am finding.. > > I have not run into it and this was a brand new server farm with about > 4000 migrated users from OpenLDAP? Is there something I might be missing > when migrating? > > ipa: ERROR: Operations error: Allocation of a new value for range > cn=posix ids,cn=distributed numeric assignment > plugin,cn=plugins,cn=config failed! Unable to proceed. > > and of course - the classic 1100 - 1101... > > # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config > dn: cn=Posix IDs,cn=Distributed Numeric Assignment > Plugin,cn=plugins,cn=config > objectClass: top > objectClass: extensibleObject > cn: Posix IDs > dnaType: uidNumber > dnaType: gidNumber > dnaNextValue: 1101 > dnaMaxValue: 1100 > dnaMagicRegen: -1 I'm guessing you removed the master that spawned this one. This is the initial DNA config where max < next so it should ask the master that created it for a range. See http://blog-rcritten.rhcloud.com/?p=50 rob From prasun.gera at gmail.com Tue Mar 24 22:41:51 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 24 Mar 2015 18:41:51 -0400 Subject: [Freeipa-users] Debian 7.0.8 and REHL IPA In-Reply-To: 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> <54E296CE.7070501@redhat.com> <1427232010574.10892@vuw.ac.nz> Message-ID: I tried setting up the client on an ubuntu 12.04 system, and had some initial hiccups. I used the ppa for ipa and sssd. This bug report lists some pitfalls: https://bugs.launchpad.net/ubuntu/+source/freeipa/+bug/1280215. I don't know why it is marked as won't fix, but it affects 12.04, which is LTS. I had to manually add mkdir -p /etc/pki/nssdb && certutil -N --empty-password -d /etc/pki/nssdb for the client to install. The client install script doesn't do this on ubuntu. It is possible that some of the other reported issues have been fixed. It's best to do this on system you have physical access to. A botched install could lock you out of ssh. On Tue, Mar 24, 2015 at 5:53 PM, Will Sheldon wrote: > > > There is a ppa for ubuntu: > https://code.launchpad.net/~freeipa/+archive/ubuntu/ppa > > and packages in the deb archives: > https://packages.qa.debian.org/f/freeipa.html > > > I?ve had mixed results using them, there seem to be frequent regressions > so having a canary machine / cluster is essential. > > The install script also had some issues, but I believe it?s better now? > last time I tried was about 12 months ago. > > > Will. > > > > On March 24, 2015 at 2:29:09 PM, Steven Jones (steven.jones at vuw.ac.nz) > wrote: > > Hi, > > Anyone have experience with running the sssd client (I assume its > available) on Debian 7.0.8 against a RH IPA setup? > > Is it painless long term or best avoided? > > regards > > Steven > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > > > -- > Manage your subscription for the Freeipa-users mailing list: > https://www.redhat.com/mailman/listinfo/freeipa-users > Go to http://freeipa.org for more info on the project > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Tue Mar 24 23:48:18 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 24 Mar 2015 16:48:18 -0700 Subject: [Freeipa-users] ID Range question In-Reply-To: <5511E4B2.9040607@redhat.com> References: <5511E272.2020106@gmail.com> <5511E4B2.9040607@redhat.com> Message-ID: <5511F7C2.7090406@gmail.com> That makes perfect sense. I lost a connection to the master. I can fix that. Thank you! ~J On 3/24/15 3:26 PM, Rob Crittenden wrote: > Janelle wrote: >> Hello, >> >> I have seen this pop up a few times, but no real answers - at least none >> that I am finding.. >> >> I have not run into it and this was a brand new server farm with about >> 4000 migrated users from OpenLDAP? Is there something I might be missing >> when migrating? >> >> ipa: ERROR: Operations error: Allocation of a new value for range >> cn=posix ids,cn=distributed numeric assignment >> plugin,cn=plugins,cn=config failed! Unable to proceed. >> >> and of course - the classic 1100 - 1101... >> >> # Posix IDs, Distributed Numeric Assignment Plugin, plugins, config >> dn: cn=Posix IDs,cn=Distributed Numeric Assignment >> Plugin,cn=plugins,cn=config >> objectClass: top >> objectClass: extensibleObject >> cn: Posix IDs >> dnaType: uidNumber >> dnaType: gidNumber >> dnaNextValue: 1101 >> dnaMaxValue: 1100 >> dnaMagicRegen: -1 > I'm guessing you removed the master that spawned this one. This is the > initial DNA config where max < next so it should ask the master that > created it for a range. > > See http://blog-rcritten.rhcloud.com/?p=50 > > rob > From mike at colovore.com Wed Mar 25 00:21:43 2015 From: mike at colovore.com (Michael Pawlak) Date: Tue, 24 Mar 2015 17:21:43 -0700 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: References: <550FF3E7.2090106@redhat.com> <55101409.5000505@redhat.com> <5510660C.5020709@redhat.com> <107823642.2856345.1427143008792.JavaMail.zimbra@redhat.com> Message-ID: Endi, Any word on the build? *Michael Pawlak* Web Systems Administrator | Colovore LLC E: mike at colovore.com C: 408.316.2154 On Mon, Mar 23, 2015 at 2:55 PM, Michael Pawlak wrote: > Endi, > > I could test that. > > *Michael Pawlak* > Web Systems Administrator | Colovore LLC > E: mike at colovore.com > C: 408.316.2154 > > > On Mon, Mar 23, 2015 at 1:36 PM, Endi Sukma Dewata > wrote: > >> Thanks for the info. The transaction log doesn't indicate the cause of >> the problem either. I might need to provide a custom build that generates >> more useful information. Would you be able to test that? Thanks. >> >> -- >> Endi S. Dewata >> >> ----- Original Message ----- >> > Endi, >> > >> > 1. I am currently using CentOS 6.5. >> > >> > 2. Below are the package versions. >> > >> > Former: >> > Don't have that information available >> > >> > Current: >> > pki-java-tools-9.0.3-38.el6_6.noarch >> > pki-silent-9.0.3-38.el6_6.noarch >> > ipa-pki-common-theme-9.0.3-7.el6.noarch >> > pki-ca-9.0.3-38.el6_6.noarch >> > pki-setup-9.0.3-38.el6_6.noarch >> > pki-native-tools-9.0.3-38.el6_6.x86_64 >> > pki-util-9.0.3-38.el6_6.noarch >> > pki-selinux-9.0.3-38.el6_6.noarch >> > pki-common-9.0.3-38.el6_6.noarch >> > ipa-pki-ca-theme-9.0.3-7.el6.noarch >> > pki-symkey-9.0.3-38.el6_6.x86_64 >> > >> > 3. Attached >> > >> > *Michael Pawlak* >> > Web Systems Administrator | Colovore LLC >> > E: mike at colovore.com >> > C: 408.316.2154 >> > >> > >> > On Mon, Mar 23, 2015 at 12:14 PM, Endi Sukma Dewata > > >> > wrote: >> > > >> > > Hi, >> > > >> > > Unfortunately the code doesn't log the exact cause of the problem. I >> need >> > > some additional info: >> > > >> > > 1. Which platform are you using? >> > > 2. What are the versions of the pki-* packages before and after >> upgrade? >> > > 3. Please provide the /etc/pki-ca/CS.cfg and >> /var/log/pki-ca/transactions. >> > > >> > > Thanks. >> > > >> > > -- >> > > Endi S. Dewata >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From anthony at advertise.com Wed Mar 25 01:17:46 2015 From: anthony at advertise.com (Anthony Lanni) Date: Tue, 24 Mar 2015 18:17:46 -0700 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server Message-ID: While running ipa-server-install, it's failing out at the end with an error regarding the client install on the server. This happens regardless of how I input the options, but here's the latest command: ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM -n example.com -p passwd1 -a passwd2 --hostname=ldap-server-01.example.com --forwarder=10.0.1.20 --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d Runs through the entire setup and gives me this: [...] ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain example.com --server ldap-server-01.example.com --realm EXAMPLE.COM --hostname ldap-server-01.example.com ipa : DEBUG stdout= ipa : DEBUG stderr=Hostname: ldap-server-01.example.com Realm: EXAMPLE.COM DNS Domain: example.com IPA Server: ldap-server-01.example.com BaseDN: dc=example,dc=com New SSSD config will be created Configured /etc/sssd/sssd.conf Traceback (most recent call last): File "/usr/sbin/ipa-client-install", line 2377, in sys.exit(main()) File "/usr/sbin/ipa-client-install", line 2363, in main rval = install(options, env, fstore, statestore) File "/usr/sbin/ipa-client-install", line 2135, in install delete_persistent_client_session_data(host_principal) File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in delete_persistent_client_session_data kernel_keyring.del_key(keyname) File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line 99, in del_key real_key = get_real_key(key) File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line 45, in get_real_key (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], raiseonerr=False) File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line 295, in run close_fds=True, env=env, cwd=cwd) File "/usr/lib64/python2.6/subprocess.py", line 642, in __init__ errread, errwrite) File "/usr/lib64/python2.6/subprocess.py", line 1234, in _execute_child raise child_exception OSError: [Errno 8] Exec format error ipa : 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-server-install", line 1103, in main sys.exit("Configuration of client side components failed!\nipa-client-install returned: " + str(e)) ipa : INFO The ipa-server-install command failed, exception: SystemExit: Configuration of client side components failed! ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain example.com --server ldap-server-01.example.com --realm EXAMPLE.COM --hostname ldap-server-01.advdc.com' returned non-zero exit status 1 Same details (without the debug messages, of course) in /var/log/ipaserver-install.log. From ipaclient-install.log: [...] 2015-03-24T23:15:26Z DEBUG Backing up system configuration file '/etc/sssd/sssd.conf' 2015-03-24T23:15:26Z DEBUG -> Not backing up - '/etc/sssd/sssd.conf' doesn't exist 2015-03-24T23:15:26Z INFO New SSSD config will be created 2015-03-24T23:15:26Z INFO Configured /etc/sssd/sssd.conf 2015-03-24T23:15:26Z DEBUG args=/usr/bin/certutil -A -d /etc/pki/nssdb -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt 2015-03-24T23:15:26Z DEBUG stdout= 2015-03-24T23:15:26Z DEBUG stderr= 2015-03-24T23:15:26Z DEBUG args=/usr/bin/kinit -k -t /etc/krb5.keytab host/ ldap-server-01.example.com at EXAMPLE.COM 2015-03-24T23:15:26Z DEBUG stdout= 2015-03-24T23:15:26Z DEBUG stderr= I'm running on CENTOS 6.5, freeipa 3.0.0.37 #> ipactl status Directory Service: RUNNING KDC Service: RUNNING KPASSWD Service: RUNNING DNS Service: RUNNING MEMCACHE Service: RUNNING HTTP Service: RUNNING CA Service: RUNNING I noticed that there's no host certificate for the server when I look at the host details in the web interface. thx anthony -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Wed Mar 25 03:11:49 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 24 Mar 2015 23:11:49 -0400 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: References: Message-ID: <55122775.5040406@redhat.com> On 03/24/2015 09:17 PM, Anthony Lanni wrote: > While running ipa-server-install, it's failing out at the end with an > error regarding the client install on the server. This happens > regardless of how I input the options, but here's the latest command: > > ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM > -n example.com -p passwd1 -a > passwd2 --hostname=ldap-server-01.example.com > --forwarder=10.0.1.20 > --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d > > Runs through the entire setup and gives me this: > > [...] > ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master > --unattended --domain example.com --server > ldap-server-01.example.com --realm > EXAMPLE.COM --hostname ldap-server-01.example.com > > ipa : DEBUG stdout= > > ipa : DEBUG stderr=Hostname: ldap-server-01.example.com > > Realm: EXAMPLE.COM > DNS Domain: example.com > IPA Server: ldap-server-01.example.com > BaseDN: dc=example,dc=com > New SSSD config will be created > Configured /etc/sssd/sssd.conf > Traceback (most recent call last): > File "/usr/sbin/ipa-client-install", line 2377, in > sys.exit(main()) > File "/usr/sbin/ipa-client-install", line 2363, in main > rval = install(options, env, fstore, statestore) > File "/usr/sbin/ipa-client-install", line 2135, in install > delete_persistent_client_session_data(host_principal) > File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in > delete_persistent_client_session_data > kernel_keyring.del_key(keyname) > File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > line 99, in del_key > real_key = get_real_key(key) > File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > line 45, in get_real_key > (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, > key], raiseonerr=False) Is keyctl installed? Can you run it manually? Any SELinux denials? > File "/usr/lib/python2.6/site-packages/ipapython/ipautil.py", line > 295, in run > close_fds=True, env=env, cwd=cwd) > File "/usr/lib64/python2.6/subprocess.py", line 642, in __init__ > errread, errwrite) > File "/usr/lib64/python2.6/subprocess.py", line 1234, in _execute_child > raise child_exception > OSError: [Errno 8] Exec format error > > ipa : 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-server-install", line 1103, in main > sys.exit("Configuration of client side components > failed!\nipa-client-install returned: " + str(e)) > > ipa : INFO The ipa-server-install command failed, > exception: SystemExit: Configuration of client side components failed! > ipa-client-install returned: Command '/usr/sbin/ipa-client-install > --on-master --unattended --domain example.com > --server ldap-server-01.example.com > --realm EXAMPLE.COM > --hostname ldap-server-01.advdc.com > ' returned non-zero exit status 1 > > > Same details (without the debug messages, of course) in > /var/log/ipaserver-install.log. From ipaclient-install.log: > [...] > 2015-03-24T23:15:26Z DEBUG Backing up system configuration file > '/etc/sssd/sssd.conf' > 2015-03-24T23:15:26Z DEBUG -> Not backing up - '/etc/sssd/sssd.conf' > doesn't exist > 2015-03-24T23:15:26Z INFO New SSSD config will be created > 2015-03-24T23:15:26Z INFO Configured /etc/sssd/sssd.conf > 2015-03-24T23:15:26Z DEBUG args=/usr/bin/certutil -A -d /etc/pki/nssdb > -n IPA CA -t CT,C,C -a -i /etc/ipa/ca.crt > 2015-03-24T23:15:26Z DEBUG stdout= > 2015-03-24T23:15:26Z DEBUG stderr= > 2015-03-24T23:15:26Z DEBUG args=/usr/bin/kinit -k -t /etc/krb5.keytab > host/ldap-server-01.example.com at EXAMPLE.COM > > 2015-03-24T23:15:26Z DEBUG stdout= > 2015-03-24T23:15:26Z DEBUG stderr= > > I'm running on CENTOS 6.5, freeipa 3.0.0.37 > > #> ipactl status > Directory Service: RUNNING > KDC Service: RUNNING > KPASSWD Service: RUNNING > DNS Service: RUNNING > MEMCACHE Service: RUNNING > HTTP Service: RUNNING > CA Service: RUNNING > > I noticed that there's no host certificate for the server when I look > at the host details in the web interface. > > thx > anthony > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Wed Mar 25 05:33:59 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 11:03:59 +0530 Subject: [Freeipa-users] Is it possible to Disable "BAD Password" from IPA Configs Message-ID: Hi, Is there any way that we can configure IPA server not to do Strict Checking for Password. For EG: *BAD PASSWORD: The password is too similar to the old one* *New password: * *BAD PASSWORD: The password fails the dictionary check - it is based on a dictionary word* We tried removing "use_authtok" from below but no luck. password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok system-auth "password" config: [root at cipa vagrant]# cat /etc/pam.d/system-auth | grep password | grep -v grep *password requisite pam_pwquality.so try_first_pass retry=3 type=* *password sufficient pam_unix.so sha512 shadow nullok try_first_pass use_authtok* *password sufficient pam_sss.so use_authtok* *password required pam_deny.so* [root at cipa vagrant]# *Best Regards,__________________________________________* *Yogesh Sharma* -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Wed Mar 25 05:44:56 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Wed, 25 Mar 2015 07:44:56 +0200 Subject: [Freeipa-users] Is it possible to Disable "BAD Password" from IPA Configs In-Reply-To: References: Message-ID: <20150325054456.GX3878@redhat.com> On Wed, 25 Mar 2015, Yogesh Sharma wrote: >Hi, > >Is there any way that we can configure IPA server not to do Strict Checking >for Password. >For EG: > > >*BAD PASSWORD: The password is too similar to the old one* >*New password: * >*BAD PASSWORD: The password fails the dictionary check - it is based on a >dictionary word* > >We tried removing "use_authtok" from below but no luck. > >password sufficient pam_unix.so sha512 shadow nullok try_first_pass >use_authtok You are changing *wrong* configuration. > >system-auth "password" config: > >[root at cipa vagrant]# cat /etc/pam.d/system-auth | grep password | grep -v >grep >*password requisite pam_pwquality.so try_first_pass retry=3 type=* pam_pwquality is responsible for the password strength checks in PAM stack. Read its documentation for details. P.S. This question has nothing to do with FreeIPA. -- / Alexander Bokovoy From ender at kofeina.net Wed Mar 25 06:18:11 2015 From: ender at kofeina.net (=?iso-8859-2?Q?=A3ukasz_Jaworski?=) Date: Wed, 25 Mar 2015 07:18:11 +0100 Subject: [Freeipa-users] What am I missing? ipaca? In-Reply-To: <55118C17.40807@redhat.com> References: <550F836F.7090201@gmail.com> <550FF343.3030105@redhat.com> <430C6CA9-9B64-42E5-82DE-3166EC5B443B@kofeina.net> <551127EB.8020603@redhat.com> <77B789E3-A004-4FCD-8DE6-7FEEF8C689A0@kofeina.net> <55117245.10307@redhat.com> <55118C17.40807@redhat.com> Message-ID: <69410BB8-E7A8-4F8A-BA1A-D43A5BE1BBE4@kofeina.net> Hi, Wiadomo?? napisana przez Martin Kosek w dniu 24 mar 2015, o godz. 17:08: > Right. Maybe you reinstalled IPA replica (several times) without cleaning the > RUV? With > > # ipa-replica-manage list-ruv > # ipa-replica-manage clean-ruv > > you should be able to clean the old (lower) RUVs and see if the error > disappears. More info in "man ipa-replica-manage" and on > > https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/managing-topology.html#cleanruv > > Martin After cleanruv looks better. But I had some problems with ipa-replica-manage 1. loks like ipa-replica-manage works only with dc=xxxxx replicas, not o=ipaca 2. There is no option clean-ruv in ipa-csreplica-manage Best regards, Ender From yks0000 at gmail.com Wed Mar 25 06:46:16 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 12:16:16 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server Message-ID: Hi, We are getting below error while we are installing IPA Server (ipa-server-install --no-ntp). ** *Configuration of client side components failed!* *ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain sd.int --server ldap-inf-stg-sg1-01.sd.int --realm SD.INT --hostname ldap-inf-stg-sg1-01.sd.int ' returned non-zero exit status 1* **Logs indicate below errors: *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h ldap-inf-stg-sg1-01.sd.int -ZZ -x -D cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn uid=admin,cn=users,cn=accounts,dc=sd,dc=int* *2015-03-25T06:39:59Z DEBUG stdout=* *2015-03-25T06:39:59Z DEBUG stderr=* *2015-03-25T06:39:59Z DEBUG ldappasswd done* *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install --on-master --unattended --domain sd.int --server ldap-inf-stg-sg1-01.sd.int --realm SD.INT --hostname ldap-inf-stg-sg1-01.sd.int * *2015-03-25T06:40:10Z DEBUG stdout=* *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that ldap-inf-stg-sg1-01.sd.int 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.* *Unconfigured automount client failed: Command 'ipa-client-automount --uninstall --debug' returned non-zero exit status 1* *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* *nscd daemon is not installed, skip configuration* *nslcd daemon is not installed, skip configuration* *Client uninstall complete.* *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* * sys.exit("Configuration of client side components failed!\nipa-client-install returned: " + str(e))* *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, exception: SystemExit: Configuration of client side components failed!* *ipa-client-install returned: Command '/usr/sbin/ipa-client-install --on-master --unattended --domain sd.int --server ldap-inf-stg-sg1-01.sd.int --realm SD.INT --hostname ldap-inf-stg-sg1-01.sd.int ' returned non-zero exit status 1* ** This server is on AWS and I can confirm that all above ports are opened. Also as it is installing on same server where IPA Server is being installed, Port should not be an issue. Am I missing anything here. *Best Regards,__________________________________________* *Yogesh Sharma* -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Wed Mar 25 06:59:11 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 12:29:11 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: References: Message-ID: I have checked , there is no default.conf. Please suggest. [root at ldap-inf-stg-sg1-01 ipa]# ls -lrth /etc/ipa/ total 8.0K drwxr-xr-x 2 root root 4.0K Mar 24 13:29 html -r--r--r-- 1 root root 1.3K Mar 25 06:36 ca.crt [root at ldap-inf-stg-sg1-01 ipa]# ls -lrth /etc/ipa/html/ total 28K -rw-r--r-- 1 root root 1.4K Oct 16 15:03 unauthorized.html -rw-r--r-- 1 root root 3.9K Oct 16 15:03 ssbrowser.html -rw-r--r-- 1 root root 521 Oct 16 15:03 ipa_error.css -rw-r--r-- 1 root root 4.5K Oct 16 15:03 ffconfig_page.js -rw-r--r-- 1 root root 2.9K Oct 16 15:03 ffconfig.js -rw-r--r-- 1 root root 3.9K Oct 16 15:03 browserconfig.html [root at ldap-inf-stg-sg1-01 ipa]# *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Wed, Mar 25, 2015 at 12:16 PM, Yogesh Sharma wrote: > Hi, > > We are getting below error while we are installing IPA Server > (ipa-server-install --no-ntp). > > > *Configuration of client side components failed!* > *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > --on-master --unattended --domain sd.int --server > ldap-inf-stg-sg1-01.sd.int --realm > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > ' returned non-zero exit status 1* > > Logs indicate below errors: > > *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h > ldap-inf-stg-sg1-01.sd.int -ZZ -x -D > cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn > uid=admin,cn=users,cn=accounts,dc=sd,dc=int* > *2015-03-25T06:39:59Z DEBUG stdout=* > *2015-03-25T06:39:59Z DEBUG stderr=* > *2015-03-25T06:39:59Z DEBUG ldappasswd done* > *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install --on-master > --unattended --domain sd.int --server > ldap-inf-stg-sg1-01.sd.int --realm > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > * > *2015-03-25T06:40:10Z DEBUG stdout=* > *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that > ldap-inf-stg-sg1-01.sd.int 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.* > *Unconfigured automount client failed: Command 'ipa-client-automount > --uninstall --debug' returned non-zero exit status 1* > *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* > *nscd daemon is not installed, skip configuration* > *nslcd daemon is not installed, skip configuration* > *Client uninstall complete.* > > *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* > * sys.exit("Configuration of client side components > failed!\nipa-client-install returned: " + str(e))* > > *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, > exception: SystemExit: Configuration of client side components failed!* > *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > --on-master --unattended --domain sd.int --server > ldap-inf-stg-sg1-01.sd.int --realm > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > ' returned non-zero exit status 1* > > > > This server is on AWS and I can confirm that all above ports are opened. > Also as it is installing on same server where IPA Server is being > installed, Port should not be an issue. > > Am I missing anything here. > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Wed Mar 25 07:50:11 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 13:20:11 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: References: Message-ID: While restarting using ipactl . It is stopping. Any suggestion. [root at ldap-inf-stg-sg1-01 ys7673]# ipactl stop Starting dirsrv: PKI-IPA... [ OK ] SD-INT... [ OK ] Stopping CA Service pki-tomcatd: unrecognized service Failed to stop CA Service Stopping HTTP Service Stopping httpd: [FAILED] Stopping MEMCACHE Service Stopping KPASSWD Service Stopping Kerberos 5 Admin Server: [FAILED] Stopping KDC Service Stopping Kerberos 5 KDC: [FAILED] Stopping Directory Service Shutting down dirsrv: PKI-IPA... [ OK ] SD-INT... [ OK ] [root at ldap-inf-stg-sg1-01 ys7673]# ipactl start Starting Directory Service Starting dirsrv: PKI-IPA... [ OK ] SD-INT... [ OK ] Starting KDC Service Starting Kerberos 5 KDC: [ OK ] Starting KPASSWD Service Starting Kerberos 5 Admin Server: [ OK ] Starting MEMCACHE Service Starting ipa_memcached: [ OK ] Starting HTTP Service Starting httpd: [ OK ] Starting CA Service pki-tomcatd: unrecognized service Failed to start CA Service *Shutting down* *Stopping Kerberos 5 KDC: [ OK ]* *Stopping Kerberos 5 Admin Server: [ OK ]* *Stopping ipa_memcached: [ OK ]* *Stopping httpd: [ OK ]* *pki-tomcatd: unrecognized service* *Shutting down dirsrv: * * PKI-IPA... [ OK ]* * SD-INT... [ OK ]* *Aborting ipactl* [root at ldap-inf-stg-sg1-01 ys7673] *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Wed, Mar 25, 2015 at 12:29 PM, Yogesh Sharma wrote: > I have checked , there is no default.conf. Please suggest. > > [root at ldap-inf-stg-sg1-01 ipa]# ls -lrth /etc/ipa/ > total 8.0K > drwxr-xr-x 2 root root 4.0K Mar 24 13:29 html > -r--r--r-- 1 root root 1.3K Mar 25 06:36 ca.crt > > [root at ldap-inf-stg-sg1-01 ipa]# ls -lrth /etc/ipa/html/ > total 28K > -rw-r--r-- 1 root root 1.4K Oct 16 15:03 unauthorized.html > -rw-r--r-- 1 root root 3.9K Oct 16 15:03 ssbrowser.html > -rw-r--r-- 1 root root 521 Oct 16 15:03 ipa_error.css > -rw-r--r-- 1 root root 4.5K Oct 16 15:03 ffconfig_page.js > -rw-r--r-- 1 root root 2.9K Oct 16 15:03 ffconfig.js > -rw-r--r-- 1 root root 3.9K Oct 16 15:03 browserconfig.html > [root at ldap-inf-stg-sg1-01 ipa]# > > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Wed, Mar 25, 2015 at 12:16 PM, Yogesh Sharma wrote: > >> Hi, >> >> We are getting below error while we are installing IPA Server >> (ipa-server-install --no-ntp). >> >> >> *Configuration of client side components failed!* >> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >> --on-master --unattended --domain sd.int --server >> ldap-inf-stg-sg1-01.sd.int --realm >> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >> ' returned non-zero exit status 1* >> >> Logs indicate below errors: >> >> *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h >> ldap-inf-stg-sg1-01.sd.int -ZZ -x -D >> cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn >> uid=admin,cn=users,cn=accounts,dc=sd,dc=int* >> *2015-03-25T06:39:59Z DEBUG stdout=* >> *2015-03-25T06:39:59Z DEBUG stderr=* >> *2015-03-25T06:39:59Z DEBUG ldappasswd done* >> *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install --on-master >> --unattended --domain sd.int --server >> ldap-inf-stg-sg1-01.sd.int --realm >> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >> * >> *2015-03-25T06:40:10Z DEBUG stdout=* >> *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that >> ldap-inf-stg-sg1-01.sd.int 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.* >> *Unconfigured automount client failed: Command 'ipa-client-automount >> --uninstall --debug' returned non-zero exit status 1* >> *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* >> *nscd daemon is not installed, skip configuration* >> *nslcd daemon is not installed, skip configuration* >> *Client uninstall complete.* >> >> *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* >> * sys.exit("Configuration of client side components >> failed!\nipa-client-install returned: " + str(e))* >> >> *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, >> exception: SystemExit: Configuration of client side components failed!* >> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >> --on-master --unattended --domain sd.int --server >> ldap-inf-stg-sg1-01.sd.int --realm >> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >> ' returned non-zero exit status 1* >> >> >> >> This server is on AWS and I can confirm that all above ports are opened. >> Also as it is installing on same server where IPA Server is being >> installed, Port should not be an issue. >> >> Am I missing anything here. >> >> >> >> >> *Best Regards,__________________________________________* >> >> *Yogesh Sharma* >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Wed Mar 25 10:12:37 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 15:42:37 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: References: Message-ID: Any suggestion Please. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Wed, Mar 25, 2015 at 1:20 PM, Yogesh Sharma wrote: > While restarting using ipactl . It is stopping. Any suggestion. > > [root at ldap-inf-stg-sg1-01 ys7673]# ipactl stop > Starting dirsrv: > PKI-IPA... [ OK ] > SD-INT... [ OK ] > Stopping CA Service > pki-tomcatd: unrecognized service > Failed to stop CA Service > Stopping HTTP Service > Stopping httpd: [FAILED] > Stopping MEMCACHE Service > Stopping KPASSWD Service > Stopping Kerberos 5 Admin Server: [FAILED] > Stopping KDC Service > Stopping Kerberos 5 KDC: [FAILED] > Stopping Directory Service > Shutting down dirsrv: > PKI-IPA... [ OK ] > SD-INT... [ OK ] > [root at ldap-inf-stg-sg1-01 ys7673]# ipactl start > Starting Directory Service > Starting dirsrv: > PKI-IPA... [ OK ] > SD-INT... [ OK ] > Starting KDC Service > Starting Kerberos 5 KDC: [ OK ] > Starting KPASSWD Service > Starting Kerberos 5 Admin Server: [ OK ] > Starting MEMCACHE Service > Starting ipa_memcached: [ OK ] > Starting HTTP Service > Starting httpd: [ OK ] > Starting CA Service > pki-tomcatd: unrecognized service > Failed to start CA Service > *Shutting down* > *Stopping Kerberos 5 KDC: [ OK ]* > *Stopping Kerberos 5 Admin Server: [ OK ]* > *Stopping ipa_memcached: [ OK ]* > *Stopping httpd: [ OK ]* > *pki-tomcatd: unrecognized service* > *Shutting down dirsrv: * > * PKI-IPA... [ OK ]* > * SD-INT... [ OK ]* > *Aborting ipactl* > [root at ldap-inf-stg-sg1-01 ys7673] > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Wed, Mar 25, 2015 at 12:29 PM, Yogesh Sharma wrote: > >> I have checked , there is no default.conf. Please suggest. >> >> [root at ldap-inf-stg-sg1-01 ipa]# ls -lrth /etc/ipa/ >> total 8.0K >> drwxr-xr-x 2 root root 4.0K Mar 24 13:29 html >> -r--r--r-- 1 root root 1.3K Mar 25 06:36 ca.crt >> >> [root at ldap-inf-stg-sg1-01 ipa]# ls -lrth /etc/ipa/html/ >> total 28K >> -rw-r--r-- 1 root root 1.4K Oct 16 15:03 unauthorized.html >> -rw-r--r-- 1 root root 3.9K Oct 16 15:03 ssbrowser.html >> -rw-r--r-- 1 root root 521 Oct 16 15:03 ipa_error.css >> -rw-r--r-- 1 root root 4.5K Oct 16 15:03 ffconfig_page.js >> -rw-r--r-- 1 root root 2.9K Oct 16 15:03 ffconfig.js >> -rw-r--r-- 1 root root 3.9K Oct 16 15:03 browserconfig.html >> [root at ldap-inf-stg-sg1-01 ipa]# >> >> >> >> >> >> *Best Regards,__________________________________________* >> >> *Yogesh Sharma* >> *Email: yks0000 at gmail.com | Web: www.initd.in >> * >> >> RHCE, VCE-CIA, RackSpace Cloud U >> [image: My LinkedIn Profile] >> >> >> On Wed, Mar 25, 2015 at 12:16 PM, Yogesh Sharma >> wrote: >> >>> Hi, >>> >>> We are getting below error while we are installing IPA Server >>> (ipa-server-install --no-ntp). >>> >>> >>> *Configuration of client side components failed!* >>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >>> --on-master --unattended --domain sd.int --server >>> ldap-inf-stg-sg1-01.sd.int --realm >>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>> ' returned non-zero exit status 1* >>> >>> Logs indicate below errors: >>> >>> *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h >>> ldap-inf-stg-sg1-01.sd.int -ZZ -x -D >>> cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn >>> uid=admin,cn=users,cn=accounts,dc=sd,dc=int* >>> *2015-03-25T06:39:59Z DEBUG stdout=* >>> *2015-03-25T06:39:59Z DEBUG stderr=* >>> *2015-03-25T06:39:59Z DEBUG ldappasswd done* >>> *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install >>> --on-master --unattended --domain sd.int --server >>> ldap-inf-stg-sg1-01.sd.int --realm >>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>> * >>> *2015-03-25T06:40:10Z DEBUG stdout=* >>> *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that >>> ldap-inf-stg-sg1-01.sd.int 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.* >>> *Unconfigured automount client failed: Command 'ipa-client-automount >>> --uninstall --debug' returned non-zero exit status 1* >>> *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* >>> *nscd daemon is not installed, skip configuration* >>> *nslcd daemon is not installed, skip configuration* >>> *Client uninstall complete.* >>> >>> *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* >>> * sys.exit("Configuration of client side components >>> failed!\nipa-client-install returned: " + str(e))* >>> >>> *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, >>> exception: SystemExit: Configuration of client side components failed!* >>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >>> --on-master --unattended --domain sd.int --server >>> ldap-inf-stg-sg1-01.sd.int --realm >>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>> ' returned non-zero exit status 1* >>> >>> >>> >>> This server is on AWS and I can confirm that all above ports are opened. >>> Also as it is installing on same server where IPA Server is being >>> installed, Port should not be an issue. >>> >>> Am I missing anything here. >>> >>> >>> >>> >>> *Best Regards,__________________________________________* >>> >>> *Yogesh Sharma* >>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.obaterspok at gmail.com Wed Mar 25 10:46:28 2015 From: john.obaterspok at gmail.com (John Obaterspok) Date: Wed, 25 Mar 2015 11:46:28 +0100 Subject: [Freeipa-users] Fedora 20 upstream repo ipa-server-install fails In-Reply-To: <20150324165822.GA17848@redhat.com> References: <20150324165822.GA17848@redhat.com> Message-ID: Hi Jan, See: https://www.redhat.com/archives/freeipa-users/2015-February/msg00131.html https://www.redhat.com/archives/freeipa-users/2014-October/msg00362.html -- john 2015-03-24 17:58 GMT+01:00 Jan Pazdziora : > > Hello, > > after enabling > > > https://copr.fedoraproject.org/coprs/mkosek/freeipa/repo/fedora-20/mkosek-freeipa-fedora-20.repo > > I've installed > > freeipa-server bind bind-dyndb-ldap > > and run > > ipa-server-install --domain example.test > > The process failed at > > [3/7]: setting up kerberos principal > [4/7]: setting up SoftHSM > [error] CalledProcessError: Command ''/usr/bin/softhsm2-util' > '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX > '--so-pin' XXXXXXXX' returned non-zero exit status 1 > Unexpected error - see /var/log/ipaserver-install.log for details: > CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' > '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' > returned non-zero exit status 1 > > and the log file ends with > > 2015-03-24T16:49:51Z DEBUG Saving SO PIN to /etc/ipa/dnssec/softhsm_pin_so > 2015-03-24T16:49:51Z DEBUG Initializing tokens > 2015-03-24T16:49:51Z DEBUG Starting external process > 2015-03-24T16:49:51Z DEBUG args='/usr/bin/softhsm2-util' '--init-token' > '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX > 2015-03-24T16:49:51Z DEBUG Process finished, return code=1 > 2015-03-24T16:49:51Z DEBUG stdout= > 2015-03-24T16:49:51Z DEBUG stderr=ERROR: Could not load the library. > > 2015-03-24T16:49:51Z 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/dnskeysyncinstance.py", > line 293, in __setup_softhsm > ipautil.run(command, nolog=(pin, pin_so,)) > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, > in run > raise CalledProcessError(p.returncode, arg_string, stdout) > CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' > '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' > returned non-zero exit status 1 > > 2015-03-24T16:49:51Z DEBUG [error] CalledProcessError: Command > ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' > '--pin' XXXXXXXX '--so-pin' XXXXXXXX' returned non-zero exit status 1 > 2015-03-24T16:49:51Z DEBUG File > "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line > 642, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1302, in main > dnskeysyncd.create_instance(api.env.host, api.env.realm) > > File > "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", > line 146, in create_instance > self.start_creation() > > 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/dnskeysyncinstance.py", > line 293, in __setup_softhsm > ipautil.run(command, nolog=(pin, pin_so,)) > > File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, > in run > raise CalledProcessError(p.returncode, arg_string, stdout) > > 2015-03-24T16:49:51Z DEBUG The ipa-server-install command failed, > exception: CalledProcessError: Command ''/usr/bin/softhsm2-util' > '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX > '--so-pin' XXXXXXXX' returned non-zero exit status 1 > > I've found discussion at > > > https://www.redhat.com/archives/freeipa-users/2014-October/msg00362.html > > which seems related but it seems the issue is back or was never > properly addressed. > > Attempt to run the command manually fails as well: > > # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf /usr/bin/softhsm2-util > '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX > '--so-pin' XXXXXXXX > ERROR: Could not load the library. > > I see the same bug both on host and in container. > > -- > Jan Pazdziora > Principal Software Engineer, Identity Management Engineering, Red Hat > > -- > 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 guertin at middlebury.edu Wed Mar 25 12:17:34 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Wed, 25 Mar 2015 12:17:34 +0000 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <5511E49A.2050101@redhat.com> References: <5511E49A.2050101@redhat.com> Message-ID: >What are the platforms and package versions of SSSD on these clients? Client 1: RHEL 6.6 sssd-1.11.6 Client 2: RHEL 6.6 sssd-1.11.6 Client 3: RHEL 5.11 sssd-1.5.1 David Guertin From yks0000 at gmail.com Wed Mar 25 12:23:40 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 17:53:40 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: References: Message-ID: I have tried on multiple Platform. Setup the nisdomain and it is resolving, though it is getting the same error. Any help would be helpful. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Wed, Mar 25, 2015 at 3:42 PM, Yogesh Sharma wrote: > Any suggestion Please. > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Wed, Mar 25, 2015 at 1:20 PM, Yogesh Sharma wrote: > >> While restarting using ipactl . It is stopping. Any suggestion. >> >> [root at ldap-inf-stg-sg1-01 ys7673]# ipactl stop >> Starting dirsrv: >> PKI-IPA... [ OK ] >> SD-INT... [ OK ] >> Stopping CA Service >> pki-tomcatd: unrecognized service >> Failed to stop CA Service >> Stopping HTTP Service >> Stopping httpd: [FAILED] >> Stopping MEMCACHE Service >> Stopping KPASSWD Service >> Stopping Kerberos 5 Admin Server: [FAILED] >> Stopping KDC Service >> Stopping Kerberos 5 KDC: [FAILED] >> Stopping Directory Service >> Shutting down dirsrv: >> PKI-IPA... [ OK ] >> SD-INT... [ OK ] >> [root at ldap-inf-stg-sg1-01 ys7673]# ipactl start >> Starting Directory Service >> Starting dirsrv: >> PKI-IPA... [ OK ] >> SD-INT... [ OK ] >> Starting KDC Service >> Starting Kerberos 5 KDC: [ OK ] >> Starting KPASSWD Service >> Starting Kerberos 5 Admin Server: [ OK ] >> Starting MEMCACHE Service >> Starting ipa_memcached: [ OK ] >> Starting HTTP Service >> Starting httpd: [ OK ] >> Starting CA Service >> pki-tomcatd: unrecognized service >> Failed to start CA Service >> *Shutting down* >> *Stopping Kerberos 5 KDC: [ OK ]* >> *Stopping Kerberos 5 Admin Server: [ OK ]* >> *Stopping ipa_memcached: [ OK ]* >> *Stopping httpd: [ OK ]* >> *pki-tomcatd: unrecognized service* >> *Shutting down dirsrv: * >> * PKI-IPA... [ OK ]* >> * SD-INT... [ OK ]* >> *Aborting ipactl* >> [root at ldap-inf-stg-sg1-01 ys7673] >> >> >> >> >> *Best Regards,__________________________________________* >> >> *Yogesh Sharma* >> *Email: yks0000 at gmail.com | Web: www.initd.in >> * >> >> RHCE, VCE-CIA, RackSpace Cloud U >> [image: My LinkedIn Profile] >> >> >> On Wed, Mar 25, 2015 at 12:29 PM, Yogesh Sharma >> wrote: >> >>> I have checked , there is no default.conf. Please suggest. >>> >>> [root at ldap-inf-stg-sg1-01 ipa]# ls -lrth /etc/ipa/ >>> total 8.0K >>> drwxr-xr-x 2 root root 4.0K Mar 24 13:29 html >>> -r--r--r-- 1 root root 1.3K Mar 25 06:36 ca.crt >>> >>> [root at ldap-inf-stg-sg1-01 ipa]# ls -lrth /etc/ipa/html/ >>> total 28K >>> -rw-r--r-- 1 root root 1.4K Oct 16 15:03 unauthorized.html >>> -rw-r--r-- 1 root root 3.9K Oct 16 15:03 ssbrowser.html >>> -rw-r--r-- 1 root root 521 Oct 16 15:03 ipa_error.css >>> -rw-r--r-- 1 root root 4.5K Oct 16 15:03 ffconfig_page.js >>> -rw-r--r-- 1 root root 2.9K Oct 16 15:03 ffconfig.js >>> -rw-r--r-- 1 root root 3.9K Oct 16 15:03 browserconfig.html >>> [root at ldap-inf-stg-sg1-01 ipa]# >>> >>> >>> >>> >>> >>> *Best Regards,__________________________________________* >>> >>> *Yogesh Sharma* >>> *Email: yks0000 at gmail.com | Web: www.initd.in >>> * >>> >>> RHCE, VCE-CIA, RackSpace Cloud U >>> [image: My LinkedIn Profile] >>> >>> >>> On Wed, Mar 25, 2015 at 12:16 PM, Yogesh Sharma >>> wrote: >>> >>>> Hi, >>>> >>>> We are getting below error while we are installing IPA Server >>>> (ipa-server-install --no-ntp). >>>> >>>> >>>> *Configuration of client side components failed!* >>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >>>> --on-master --unattended --domain sd.int --server >>>> ldap-inf-stg-sg1-01.sd.int --realm >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>> ' returned non-zero exit status 1* >>>> >>>> Logs indicate below errors: >>>> >>>> *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h >>>> ldap-inf-stg-sg1-01.sd.int -ZZ -x -D >>>> cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn >>>> uid=admin,cn=users,cn=accounts,dc=sd,dc=int* >>>> *2015-03-25T06:39:59Z DEBUG stdout=* >>>> *2015-03-25T06:39:59Z DEBUG stderr=* >>>> *2015-03-25T06:39:59Z DEBUG ldappasswd done* >>>> *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install >>>> --on-master --unattended --domain sd.int --server >>>> ldap-inf-stg-sg1-01.sd.int --realm >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>> * >>>> *2015-03-25T06:40:10Z DEBUG stdout=* >>>> *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that >>>> ldap-inf-stg-sg1-01.sd.int 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.* >>>> *Unconfigured automount client failed: Command 'ipa-client-automount >>>> --uninstall --debug' returned non-zero exit status 1* >>>> *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* >>>> *nscd daemon is not installed, skip configuration* >>>> *nslcd daemon is not installed, skip configuration* >>>> *Client uninstall complete.* >>>> >>>> *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* >>>> * sys.exit("Configuration of client side components >>>> failed!\nipa-client-install returned: " + str(e))* >>>> >>>> *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, >>>> exception: SystemExit: Configuration of client side components failed!* >>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >>>> --on-master --unattended --domain sd.int --server >>>> ldap-inf-stg-sg1-01.sd.int --realm >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>> ' returned non-zero exit status 1* >>>> >>>> >>>> >>>> This server is on AWS and I can confirm that all above ports are >>>> opened. Also as it is installing on same server where IPA Server is being >>>> installed, Port should not be an issue. >>>> >>>> Am I missing anything here. >>>> >>>> >>>> >>>> >>>> *Best Regards,__________________________________________* >>>> >>>> *Yogesh Sharma* >>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Mar 25 12:26:25 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Mar 2015 13:26:25 +0100 Subject: [Freeipa-users] ipa-client-install failure In-Reply-To: <55116B50.7040508@redhat.com> References: <550C9305.90900@redhat.com> <550C9927.1040308@redhat.com> <550CB4D5.6010303@redhat.com> <550D96AC.2070308@redhat.com> <550D9BC2.5010604@redhat.com> <20150322200440.GE9374@Jakubs-MacBook-Pro.local> <55116B50.7040508@redhat.com> Message-ID: <5512A971.1000702@redhat.com> On 03/24/2015 02:49 PM, Dmitri Pal wrote: > On 03/24/2015 09:43 AM, Roberto Cornacchia wrote: >> Hi there, >> >> All the issues I reported in this long thread are SOLVED. > > Thanks for closing the loop. Indeed! > >> For completeness, I'm posting here the conclusions. >> >> ipa-client-install did enroll the client but failed in several points: >> >> $ ipa-client-install --mkhomedir --ssh-trust-dns --force-ntpd >> [...] >> Synchronizing time with KDC... >> Unable to sync time with IPA NTP server, assuming the time is in sync. Please >> check that 123 UDP port is opened. >> [...] >> Failed to update DNS records. >> [...] >> Could not update DNS SSHFP records. >> [...] >> Unable to find 'admin' user with 'getent passwd admin at hq.example.com >> '! >> Unable to reliably detect configuration. Check NSS setup manually. >> [...] >> Client configuration complete. >> >> There were two distinct problems: >> >> 1) NTP sync failed because despite using --force-ntp, chronyd wasn't stopped >> beforehand. Stopping it manually solved the issue. I believe >> ipa-client-install stopping chronyd was the intended behaviour, in which case >> this is perhaps a bug. If it needs to be stopped manually, then it should be >> documented clearly. >> The failed NTP sync caused Kerberos to fail, which explains "Unable to find >> 'admin' user with 'getent passwd admin at hq.example.com >> '". > > We should probably file a ticket about this. I am just not sure what exactly it > should be. This is a bug, yes. I filed https://fedorahosted.org/freeipa/ticket/4963, it can be fixed together with other related chronyd changes that David is working on. >> 2) DNS update failed because for some obscure reason I forgot to open port >> 53/tcp on the server's firewall. Only 53/udp was open. This fooled me, >> because with 53/udp open, the DNS was almost completely functional. However, >> updates also require 53/tcp. I added this as a troubleshooting tip to http://www.freeipa.org/page/Troubleshooting#Failed_to_update_DNS_records If you have other ideas how to extend the guide to help your followers, please feel free to edit it directly or propose improvements. >> All in all, it was a full 2day digging and debugging. Bright side is, I >> learned a lot. Good! freeipa-users mission was successful :-) From mkosek at redhat.com Wed Mar 25 12:34:58 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Mar 2015 13:34:58 +0100 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: <55122775.5040406@redhat.com> References: <55122775.5040406@redhat.com> Message-ID: <5512AB72.6090201@redhat.com> On 03/25/2015 04:11 AM, Dmitri Pal wrote: > On 03/24/2015 09:17 PM, Anthony Lanni wrote: >> While running ipa-server-install, it's failing out at the end with an error >> regarding the client install on the server. This happens regardless of how I >> input the options, but here's the latest command: >> >> ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM >> -n example.com -p passwd1 -a >> passwd2 --hostname=ldap-server-01.example.com >> --forwarder=10.0.1.20 >> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d >> >> Runs through the entire setup and gives me this: >> >> [...] >> ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master >> --unattended --domain example.com --server >> ldap-server-01.example.com --realm >> EXAMPLE.COM --hostname ldap-server-01.example.com >> >> ipa : DEBUG stdout= >> >> ipa : DEBUG stderr=Hostname: ldap-server-01.example.com >> >> Realm: EXAMPLE.COM >> DNS Domain: example.com >> IPA Server: ldap-server-01.example.com >> BaseDN: dc=example,dc=com >> New SSSD config will be created >> Configured /etc/sssd/sssd.conf >> Traceback (most recent call last): >> File "/usr/sbin/ipa-client-install", line 2377, in >> sys.exit(main()) >> File "/usr/sbin/ipa-client-install", line 2363, in main >> rval = install(options, env, fstore, statestore) >> File "/usr/sbin/ipa-client-install", line 2135, in install >> delete_persistent_client_session_data(host_principal) >> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in >> delete_persistent_client_session_data >> kernel_keyring.del_key(keyname) >> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line >> 99, in del_key >> real_key = get_real_key(key) >> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", line >> 45, in get_real_key >> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, key], >> raiseonerr=False) > > Is keyctl installed? Can you run it manually? > Any SELinux denials? You are likely hitting https://fedorahosted.org/freeipa/ticket/3808 Please try installing keyutils before running ipa-server-install. It is fixed in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: https://bugzilla.redhat.com/show_bug.cgi?id=1205660 Martin From mkosek at redhat.com Wed Mar 25 12:38:12 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Mar 2015 13:38:12 +0100 Subject: [Freeipa-users] Fedora 20 upstream repo ipa-server-install fails In-Reply-To: References: <20150324165822.GA17848@redhat.com> Message-ID: <5512AC34.1050602@redhat.com> Good ones. Also Ccing PetrS and MartinB, who were directly involved in these features and original thread, for reference On 03/25/2015 11:46 AM, John Obaterspok wrote: > Hi Jan, > > See: > https://www.redhat.com/archives/freeipa-users/2015-February/msg00131.html > https://www.redhat.com/archives/freeipa-users/2014-October/msg00362.html > > -- john > > 2015-03-24 17:58 GMT+01:00 Jan Pazdziora : > >> >> Hello, >> >> after enabling >> >> >> https://copr.fedoraproject.org/coprs/mkosek/freeipa/repo/fedora-20/mkosek-freeipa-fedora-20.repo >> >> I've installed >> >> freeipa-server bind bind-dyndb-ldap >> >> and run >> >> ipa-server-install --domain example.test >> >> The process failed at >> >> [3/7]: setting up kerberos principal >> [4/7]: setting up SoftHSM >> [error] CalledProcessError: Command ''/usr/bin/softhsm2-util' >> '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX >> '--so-pin' XXXXXXXX' returned non-zero exit status 1 >> Unexpected error - see /var/log/ipaserver-install.log for details: >> CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' >> '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' >> returned non-zero exit status 1 >> >> and the log file ends with >> >> 2015-03-24T16:49:51Z DEBUG Saving SO PIN to /etc/ipa/dnssec/softhsm_pin_so >> 2015-03-24T16:49:51Z DEBUG Initializing tokens >> 2015-03-24T16:49:51Z DEBUG Starting external process >> 2015-03-24T16:49:51Z DEBUG args='/usr/bin/softhsm2-util' '--init-token' >> '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX >> 2015-03-24T16:49:51Z DEBUG Process finished, return code=1 >> 2015-03-24T16:49:51Z DEBUG stdout= >> 2015-03-24T16:49:51Z DEBUG stderr=ERROR: Could not load the library. >> >> 2015-03-24T16:49:51Z 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/dnskeysyncinstance.py", >> line 293, in __setup_softhsm >> ipautil.run(command, nolog=(pin, pin_so,)) >> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, >> in run >> raise CalledProcessError(p.returncode, arg_string, stdout) >> CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' >> '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' >> returned non-zero exit status 1 >> >> 2015-03-24T16:49:51Z DEBUG [error] CalledProcessError: Command >> ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' >> '--pin' XXXXXXXX '--so-pin' XXXXXXXX' returned non-zero exit status 1 >> 2015-03-24T16:49:51Z DEBUG File >> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line >> 642, in run_script >> return_value = main_function() >> >> File "/usr/sbin/ipa-server-install", line 1302, in main >> dnskeysyncd.create_instance(api.env.host, api.env.realm) >> >> File >> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >> line 146, in create_instance >> self.start_creation() >> >> 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/dnskeysyncinstance.py", >> line 293, in __setup_softhsm >> ipautil.run(command, nolog=(pin, pin_so,)) >> >> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, >> in run >> raise CalledProcessError(p.returncode, arg_string, stdout) >> >> 2015-03-24T16:49:51Z DEBUG The ipa-server-install command failed, >> exception: CalledProcessError: Command ''/usr/bin/softhsm2-util' >> '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX >> '--so-pin' XXXXXXXX' returned non-zero exit status 1 >> >> I've found discussion at >> >> >> https://www.redhat.com/archives/freeipa-users/2014-October/msg00362.html >> >> which seems related but it seems the issue is back or was never >> properly addressed. >> >> Attempt to run the command manually fails as well: >> >> # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf /usr/bin/softhsm2-util >> '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX >> '--so-pin' XXXXXXXX >> ERROR: Could not load the library. >> >> I see the same bug both on host and in container. >> >> -- >> Jan Pazdziora >> Principal Software Engineer, Identity Management Engineering, Red Hat >> >> -- >> 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 Mar 25 12:40:44 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Mar 2015 13:40:44 +0100 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: References: Message-ID: <5512ACCC.9000608@redhat.com> On 03/25/2015 07:46 AM, Yogesh Sharma wrote: > Hi, > > We are getting below error while we are installing IPA Server > (ipa-server-install --no-ntp). > > > ** > *Configuration of client side components failed!* > *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > --on-master --unattended --domain sd.int --server > ldap-inf-stg-sg1-01.sd.int --realm > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > ' returned non-zero exit status 1* > > **Logs indicate below errors: > > *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h > ldap-inf-stg-sg1-01.sd.int -ZZ -x -D > cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn > uid=admin,cn=users,cn=accounts,dc=sd,dc=int* > *2015-03-25T06:39:59Z DEBUG stdout=* > *2015-03-25T06:39:59Z DEBUG stderr=* > *2015-03-25T06:39:59Z DEBUG ldappasswd done* > *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install --on-master > --unattended --domain sd.int --server > ldap-inf-stg-sg1-01.sd.int --realm > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > * > *2015-03-25T06:40:10Z DEBUG stdout=* > *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that > ldap-inf-stg-sg1-01.sd.int 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.* > *Unconfigured automount client failed: Command 'ipa-client-automount > --uninstall --debug' returned non-zero exit status 1* > *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* > *nscd daemon is not installed, skip configuration* > *nslcd daemon is not installed, skip configuration* > *Client uninstall complete.* > > *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* > * sys.exit("Configuration of client side components > failed!\nipa-client-install returned: " + str(e))* > > *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, > exception: SystemExit: Configuration of client side components failed!* > *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > --on-master --unattended --domain sd.int --server > ldap-inf-stg-sg1-01.sd.int --realm > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > ' returned non-zero exit status 1* > > ** > > > This server is on AWS and I can confirm that all above ports are opened. > Also as it is installing on same server where IPA Server is being > installed, Port should not be an issue. > > Am I missing anything here. Please also share ipaclient-install.log, it should show what is the exact problem in the client component installation. From yks0000 at gmail.com Wed Mar 25 12:43:11 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 18:13:11 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: <5512ACCC.9000608@redhat.com> References: <5512ACCC.9000608@redhat.com> Message-ID: Hi Martin, Please find the client logs: 2015-03-25T12:29:49Z DEBUG /usr/sbin/ipa-client-install was invoked with options: {'domain': 'sd.int', 'force': False, 'krb5_offline_passwords': True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, 'conf_sshd': True, 'conf_ntp': True, 'on_master': True, 'ntp_server': None, 'server': ['ldap-inf-stg-sg1-01.sd.int'], 'no_nisdomain': False, 'principal': None, 'hostname': 'ldap-inf-stg-sg1-01.sd.int', 'no_ac': False, 'unattended': True, 'sssd': True, 'trust_sshfp': False, 'realm_name': 'SD.INT', 'dns_updates': False, 'conf_sudo': True, 'conf_ssh': True, 'force_join': False, 'ca_cert_file': None, 'nisdomain': None, 'prompt_password': False, 'permit': False, 'debug': False, 'preserve_sssd': False, 'uninstall': False} 2015-03-25T12:29:49Z DEBUG missing options might be asked for interactively later 2015-03-25T12:29:49Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' 2015-03-25T12:29:49Z DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' 2015-03-25T12:29:49Z DEBUG [IPA Discovery] 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, servers=['ldap-inf-stg-sg1-01.sd.int'], hostname=ldap-inf-stg-sg1-01.sd.int 2015-03-25T12:29:49Z DEBUG Server and domain forced 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _kerberos.sd.int. 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ udp.sd.int. 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ udp.sd.int.,type:33,class:1,rdata={priority:0,port:88,weight:100,server: ldap-inf-stg-sg1-01.sd.int.} 2015-03-25T12:29:49Z DEBUG [LDAP server check] 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int (realm sd.int) is an IPA server 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// ldap-inf-stg-sg1-01.sd.int:389 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for IPA 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA context 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in dc=sd,dc=int (sub) 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int 2015-03-25T12:29:49Z DEBUG Validated servers: 2015-03-25T12:29:49Z DEBUG will use discovered domain: sd.int 2015-03-25T12:29:49Z DEBUG IPA Server not found 2015-03-25T12:29:49Z DEBUG [IPA Discovery] 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, servers=['ldap-inf-stg-sg1-01.sd.int'], hostname=ldap-inf-stg-sg1-01.sd.int 2015-03-25T12:29:49Z DEBUG Server and domain forced 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _kerberos.sd.int. 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ udp.sd.int. 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ udp.sd.int.,type:33,class:1,rdata={priority:0,port:88,weight:100,server: ldap-inf-stg-sg1-01.sd.int.} 2015-03-25T12:29:49Z DEBUG [LDAP server check] 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int (realm sd.int) is an IPA server 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// ldap-inf-stg-sg1-01.sd.int:389 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for IPA 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA context 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in dc=sd,dc=int (sub) 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int 2015-03-25T12:29:49Z DEBUG Validated servers: 2015-03-25T12:29:49Z ERROR Failed to verify that ldap-inf-stg-sg1-01.sd.int is an IPA Server. 2015-03-25T12:29:49Z ERROR This may mean that the remote server is not up or is not reachable due to network or firewall settings. 2015-03-25T12:29:49Z INFO Please make sure the following ports are opened in the firewall settings: TCP: 80, 88, 389 UDP: 88 (at least one of TCP/UDP ports 88 has to be open) Also note that following ports are necessary for ipa-client working properly after enrollment: TCP: 464 UDP: 464, 123 (if NTP enabled) 2015-03-25T12:29:49Z DEBUG (ldap-inf-stg-sg1-01.sd.int: Provided as option) 2015-03-25T12:29:49Z ERROR Installation failed. Rolling back changes. 2015-03-25T12:29:49Z DEBUG Loading Index file from '/var/lib/ipa/sysrestore/sysrestore.index' 2015-03-25T12:29:49Z DEBUG args=ipa-client-automount --uninstall --debug 2015-03-25T12:29:49Z DEBUG stdout= 2015-03-25T12:29:49Z DEBUG stderr=IPA client is not configured on this system. 2015-03-25T12:29:49Z ERROR Unconfigured automount client failed: Command 'ipa-client-automount --uninstall --debug' returned non-zero exit status 1 2015-03-25T12:29:49Z DEBUG Loading Index file from '/var/lib/ipa-client/sysrestore/sysrestore.index' 2015-03-25T12:29:49Z DEBUG Loading StateFile from '/var/lib/ipa-client/sysrestore/sysrestore.state' 2015-03-25T12:29:49Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb -n IPA CA 2015-03-25T12:29:49Z DEBUG stdout= 2015-03-25T12:29:49Z DEBUG stderr=certutil: Could not find cert: IPA CA : PR_FILE_NOT_FOUND_ERROR: File not found 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus start 2015-03-25T12:29:49Z DEBUG stdout=Starting system message bus: 2015-03-25T12:29:49Z DEBUG stderr= 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus status 2015-03-25T12:29:49Z DEBUG stdout=messagebus (pid 1151) is running... 2015-03-25T12:29:49Z DEBUG stderr= 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger start 2015-03-25T12:29:49Z DEBUG stdout= 2015-03-25T12:29:49Z DEBUG stderr= 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger status 2015-03-25T12:29:49Z DEBUG stdout=certmonger (pid 13244) is running... 2015-03-25T12:29:49Z DEBUG stderr= 2015-03-25T12:29:57Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb -n IPA Machine Certificate - ldap-inf-stg-sg1-01.sd.int 2015-03-25T12:29:57Z DEBUG stdout= 2015-03-25T12:29:57Z DEBUG stderr=certutil: Could not find cert: IPA Machine Certificate - ldap-inf-stg-sg1-01.sd.int : PR_FILE_NOT_FOUND_ERROR: File not found 2015-03-25T12:29:57Z DEBUG args=/sbin/service certmonger stop 2015-03-25T12:29:57Z DEBUG stdout=Stopping certmonger: [ OK ] 2015-03-25T12:29:57Z DEBUG stderr= 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig certmonger off 2015-03-25T12:29:59Z DEBUG stdout= 2015-03-25T12:29:59Z DEBUG stderr= 2015-03-25T12:29:59Z INFO Removing Kerberos service principals from /etc/krb5.keytab 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab -r SD.INT 2015-03-25T12:29:59Z DEBUG stdout= 2015-03-25T12:29:59Z DEBUG stderr=Removing principal host/ ldap-inf-stg-sg1-01.sd.int at SD.INT 2015-03-25T12:29:59Z INFO Disabling client Kerberos and LDAP configurations 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/authconfig --disablekrb5 --disablesssd --update --disablemkhomedir --disableldap --disablesssdauth 2015-03-25T12:29:59Z DEBUG stdout= 2015-03-25T12:29:59Z DEBUG stderr= 2015-03-25T12:29:59Z DEBUG Error while moving /etc/sssd/sssd.conf to /etc/sssd/sssd.conf.deleted 2015-03-25T12:29:59Z INFO Redundant SSSD configuration file /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted 2015-03-25T12:29:59Z DEBUG args=/sbin/service sssd stop 2015-03-25T12:29:59Z DEBUG stdout= 2015-03-25T12:29:59Z DEBUG stderr= 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig sssd off 2015-03-25T12:29:59Z DEBUG stdout= 2015-03-25T12:29:59Z DEBUG stderr= 2015-03-25T12:29:59Z DEBUG args=/sbin/service nscd status 2015-03-25T12:29:59Z DEBUG stdout= 2015-03-25T12:29:59Z DEBUG stderr=nscd: unrecognized service 2015-03-25T12:29:59Z INFO nscd daemon is not installed, skip configuration 2015-03-25T12:29:59Z DEBUG args=/sbin/service nslcd status 2015-03-25T12:29:59Z DEBUG stdout= 2015-03-25T12:29:59Z DEBUG stderr=nslcd: unrecognized service 2015-03-25T12:29:59Z INFO nslcd daemon is not installed, skip configuration 2015-03-25T12:29:59Z INFO Client uninstall complete. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Wed, Mar 25, 2015 at 6:10 PM, Martin Kosek wrote: > On 03/25/2015 07:46 AM, Yogesh Sharma wrote: > > Hi, > > > > We are getting below error while we are installing IPA Server > > (ipa-server-install --no-ntp). > > > > > > ** > > *Configuration of client side components failed!* > > *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > > --on-master --unattended --domain sd.int --server > > ldap-inf-stg-sg1-01.sd.int --realm > > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > > ' returned non-zero exit status 1* > > > > **Logs indicate below errors: > > > > *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h > > ldap-inf-stg-sg1-01.sd.int -ZZ -x -D > > cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn > > uid=admin,cn=users,cn=accounts,dc=sd,dc=int* > > *2015-03-25T06:39:59Z DEBUG stdout=* > > *2015-03-25T06:39:59Z DEBUG stderr=* > > *2015-03-25T06:39:59Z DEBUG ldappasswd done* > > *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install --on-master > > --unattended --domain sd.int --server > > ldap-inf-stg-sg1-01.sd.int --realm > > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > > * > > *2015-03-25T06:40:10Z DEBUG stdout=* > > *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that > > ldap-inf-stg-sg1-01.sd.int 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.* > > *Unconfigured automount client failed: Command 'ipa-client-automount > > --uninstall --debug' returned non-zero exit status 1* > > *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* > > *nscd daemon is not installed, skip configuration* > > *nslcd daemon is not installed, skip configuration* > > *Client uninstall complete.* > > > > *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* > > * sys.exit("Configuration of client side components > > failed!\nipa-client-install returned: " + str(e))* > > > > *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, > > exception: SystemExit: Configuration of client side components failed!* > > *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > > --on-master --unattended --domain sd.int --server > > ldap-inf-stg-sg1-01.sd.int --realm > > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > > ' returned non-zero exit status 1* > > > > ** > > > > > > This server is on AWS and I can confirm that all above ports are opened. > > Also as it is installing on same server where IPA Server is being > > installed, Port should not be an issue. > > > > Am I missing anything here. > > Please also share ipaclient-install.log, it should show what is the exact > problem in the client component installation. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Wed Mar 25 12:45:41 2015 From: pspacek at redhat.com (Petr Spacek) Date: Wed, 25 Mar 2015 13:45:41 +0100 Subject: [Freeipa-users] Fedora 20 upstream repo ipa-server-install fails In-Reply-To: <5512AC34.1050602@redhat.com> References: <20150324165822.GA17848@redhat.com> <5512AC34.1050602@redhat.com> Message-ID: <5512ADF5.3040708@redhat.com> Hello, On 25.3.2015 13:38, Martin Kosek wrote: > Good ones. Also Ccing PetrS and MartinB, who were directly involved in these > features and original thread, for reference In meanwhile I have fixed this. As usual, new OpenSSL package in F20 prevented installation of our custom build OpenSSL from COPR repo. It should work now, please upgrade your openssl to get this package from COPR: http://copr.fedoraproject.org/coprs/mkosek/freeipa/build/83148/ Petr^2 Spacek > On 03/25/2015 11:46 AM, John Obaterspok wrote: >> Hi Jan, >> >> See: >> https://www.redhat.com/archives/freeipa-users/2015-February/msg00131.html >> https://www.redhat.com/archives/freeipa-users/2014-October/msg00362.html >> >> -- john >> >> 2015-03-24 17:58 GMT+01:00 Jan Pazdziora : >> >>> >>> Hello, >>> >>> after enabling >>> >>> >>> https://copr.fedoraproject.org/coprs/mkosek/freeipa/repo/fedora-20/mkosek-freeipa-fedora-20.repo >>> >>> I've installed >>> >>> freeipa-server bind bind-dyndb-ldap >>> >>> and run >>> >>> ipa-server-install --domain example.test >>> >>> The process failed at >>> >>> [3/7]: setting up kerberos principal >>> [4/7]: setting up SoftHSM >>> [error] CalledProcessError: Command ''/usr/bin/softhsm2-util' >>> '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX >>> '--so-pin' XXXXXXXX' returned non-zero exit status 1 >>> Unexpected error - see /var/log/ipaserver-install.log for details: >>> CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' >>> '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' >>> returned non-zero exit status 1 >>> >>> and the log file ends with >>> >>> 2015-03-24T16:49:51Z DEBUG Saving SO PIN to /etc/ipa/dnssec/softhsm_pin_so >>> 2015-03-24T16:49:51Z DEBUG Initializing tokens >>> 2015-03-24T16:49:51Z DEBUG Starting external process >>> 2015-03-24T16:49:51Z DEBUG args='/usr/bin/softhsm2-util' '--init-token' >>> '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX >>> 2015-03-24T16:49:51Z DEBUG Process finished, return code=1 >>> 2015-03-24T16:49:51Z DEBUG stdout= >>> 2015-03-24T16:49:51Z DEBUG stderr=ERROR: Could not load the library. >>> >>> 2015-03-24T16:49:51Z 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/dnskeysyncinstance.py", >>> line 293, in __setup_softhsm >>> ipautil.run(command, nolog=(pin, pin_so,)) >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, >>> in run >>> raise CalledProcessError(p.returncode, arg_string, stdout) >>> CalledProcessError: Command ''/usr/bin/softhsm2-util' '--init-token' >>> '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX '--so-pin' XXXXXXXX' >>> returned non-zero exit status 1 >>> >>> 2015-03-24T16:49:51Z DEBUG [error] CalledProcessError: Command >>> ''/usr/bin/softhsm2-util' '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' >>> '--pin' XXXXXXXX '--so-pin' XXXXXXXX' returned non-zero exit status 1 >>> 2015-03-24T16:49:51Z DEBUG File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/installutils.py", line >>> 642, in run_script >>> return_value = main_function() >>> >>> File "/usr/sbin/ipa-server-install", line 1302, in main >>> dnskeysyncd.create_instance(api.env.host, api.env.realm) >>> >>> File >>> "/usr/lib/python2.7/site-packages/ipaserver/install/dnskeysyncinstance.py", >>> line 146, in create_instance >>> self.start_creation() >>> >>> 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/dnskeysyncinstance.py", >>> line 293, in __setup_softhsm >>> ipautil.run(command, nolog=(pin, pin_so,)) >>> >>> File "/usr/lib/python2.7/site-packages/ipapython/ipautil.py", line 346, >>> in run >>> raise CalledProcessError(p.returncode, arg_string, stdout) >>> >>> 2015-03-24T16:49:51Z DEBUG The ipa-server-install command failed, >>> exception: CalledProcessError: Command ''/usr/bin/softhsm2-util' >>> '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX >>> '--so-pin' XXXXXXXX' returned non-zero exit status 1 >>> >>> I've found discussion at >>> >>> >>> https://www.redhat.com/archives/freeipa-users/2014-October/msg00362.html >>> >>> which seems related but it seems the issue is back or was never >>> properly addressed. >>> >>> Attempt to run the command manually fails as well: >>> >>> # SOFTHSM2_CONF=/etc/ipa/dnssec/softhsm2.conf /usr/bin/softhsm2-util >>> '--init-token' '--slot' '0' '--label' 'ipaDNSSEC' '--pin' XXXXXXXX >>> '--so-pin' XXXXXXXX >>> ERROR: Could not load the library. >>> >>> I see the same bug both on host and in container. >>> >>> -- >>> Jan Pazdziora >>> Principal Software Engineer, Identity Management Engineering, Red Hat >>> >>> -- >>> 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 steve.neuharth at gmail.com Wed Mar 25 11:56:55 2015 From: steve.neuharth at gmail.com (Steve (st33v) Neuharth) Date: Wed, 25 Mar 2015 06:56:55 -0500 Subject: [Freeipa-users] Requesting a cert for a user as opposed to a service. Message-ID: Hello, I hope this is an easy question to answer and forgive me if it has been answered before. I?ve read through the documentation on how to request an ssl cert and I cannot seem to find a process to request a client cert for a user. It seems that all certificates are linked to a kerberos service principal. If I?m creating a cert for a user entity, for a VPN client for example, how to I link the cert to an actual user account? thanks for your help, ?steve From rcritten at redhat.com Wed Mar 25 13:03:25 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Mar 2015 09:03:25 -0400 Subject: [Freeipa-users] Requesting a cert for a user as opposed to a service. In-Reply-To: References: Message-ID: <5512B21D.9000702@redhat.com> Steve (st33v) Neuharth wrote: > Hello, > > I hope this is an easy question to answer and forgive me if it has been answered before. I?ve read through the documentation on how to request an ssl cert and I cannot seem to find a process to request a client cert for a user. > > It seems that all certificates are linked to a kerberos service principal. If I?m creating a cert for a user entity, for a VPN client for example, how to I link the cert to an actual user account? > > thanks for your help, > ?steve > IPA doesn't currently support certificates for users. Policies for service certificates are easy. Policies for user certificates are often more complex. It is being worked on. rob From mkosek at redhat.com Wed Mar 25 13:10:31 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Mar 2015 14:10:31 +0100 Subject: [Freeipa-users] Requesting a cert for a user as opposed to a service. In-Reply-To: <5512B21D.9000702@redhat.com> References: <5512B21D.9000702@redhat.com> Message-ID: <5512B3C7.90701@redhat.com> On 03/25/2015 02:03 PM, Rob Crittenden wrote: > Steve (st33v) Neuharth wrote: >> Hello, >> >> I hope this is an easy question to answer and forgive me if it has been answered before. I?ve read through the documentation on how to request an ssl cert and I cannot seem to find a process to request a client cert for a user. >> >> It seems that all certificates are linked to a kerberos service principal. If I?m creating a cert for a user entity, for a VPN client for example, how to I link the cert to an actual user account? >> >> thanks for your help, >> ?steve >> > > IPA doesn't currently support certificates for users. Policies for > service certificates are easy. Policies for user certificates are often > more complex. > > It is being worked on. Yup, it should be a FreeIPA 4.2 feature. Please feel free to track https://fedorahosted.org/freeipa/ticket/4938 Would you be interested to eventually trying some Alpha/Beta version of this functionality, to warn us about any potential problems of this feature in this setup? (We are not there yet, just looking if there is an interest) From yks0000 at gmail.com Wed Mar 25 13:11:10 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 18:41:10 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: References: <5512ACCC.9000608@redhat.com> Message-ID: I think I got the issue. Realm Name Entry in DNS is added in lower case rather than UPPER. 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT ,cn=kerberos,dc=sd,dc=int 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int Will try changing the Realm and see if it resovled. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Wed, Mar 25, 2015 at 6:13 PM, Yogesh Sharma wrote: > Hi Martin, > > Please find the client logs: > > > > 2015-03-25T12:29:49Z DEBUG /usr/sbin/ipa-client-install was invoked with > options: {'domain': 'sd.int', 'force': False, 'krb5_offline_passwords': > True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, > 'conf_sshd': True, 'conf_ntp': True, 'on_master': True, 'ntp_server': None, > 'server': ['ldap-inf-stg-sg1-01.sd.int'], 'no_nisdomain': False, > 'principal': None, 'hostname': 'ldap-inf-stg-sg1-01.sd.int', 'no_ac': > False, 'unattended': True, 'sssd': True, 'trust_sshfp': False, > 'realm_name': 'SD.INT', 'dns_updates': False, 'conf_sudo': True, > 'conf_ssh': True, 'force_join': False, 'ca_cert_file': None, 'nisdomain': > None, 'prompt_password': False, 'permit': False, 'debug': False, > 'preserve_sssd': False, 'uninstall': False} > 2015-03-25T12:29:49Z DEBUG missing options might be asked for > interactively later > 2015-03-25T12:29:49Z DEBUG Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2015-03-25T12:29:49Z DEBUG Loading StateFile from > '/var/lib/ipa-client/sysrestore/sysrestore.state' > 2015-03-25T12:29:49Z DEBUG [IPA Discovery] > 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, > servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= > ldap-inf-stg-sg1-01.sd.int > 2015-03-25T12:29:49Z DEBUG Server and domain forced > 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] > 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _kerberos.sd.int. > 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ > kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} > 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ > udp.sd.int. > 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ > udp.sd.int.,type:33,class:1,rdata={priority:0,port:88,weight:100,server: > ldap-inf-stg-sg1-01.sd.int.} > 2015-03-25T12:29:49Z DEBUG [LDAP server check] > 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int > (realm sd.int) is an IPA server > 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// > ldap-inf-stg-sg1-01.sd.int:389 > 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN > 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for > IPA > 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA > context > 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in > dc=sd,dc=int (sub) > 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int > 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, > domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > 2015-03-25T12:29:49Z DEBUG Validated servers: > 2015-03-25T12:29:49Z DEBUG will use discovered domain: sd.int > 2015-03-25T12:29:49Z DEBUG IPA Server not found > 2015-03-25T12:29:49Z DEBUG [IPA Discovery] > 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, > servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= > ldap-inf-stg-sg1-01.sd.int > 2015-03-25T12:29:49Z DEBUG Server and domain forced > 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] > 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _kerberos.sd.int. > 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ > kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} > 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ > udp.sd.int. > 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ > udp.sd.int.,type:33,class:1,rdata={priority:0,port:88,weight:100,server: > ldap-inf-stg-sg1-01.sd.int.} > 2015-03-25T12:29:49Z DEBUG [LDAP server check] > 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int > (realm sd.int) is an IPA server > 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// > ldap-inf-stg-sg1-01.sd.int:389 > 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN > 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for > IPA > 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA > context > 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in > dc=sd,dc=int (sub) > 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int > 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, > domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > 2015-03-25T12:29:49Z DEBUG Validated servers: > 2015-03-25T12:29:49Z ERROR Failed to verify that > ldap-inf-stg-sg1-01.sd.int is an IPA Server. > 2015-03-25T12:29:49Z ERROR This may mean that the remote server is not up > or is not reachable due to network or firewall settings. > 2015-03-25T12:29:49Z INFO Please make sure the following ports are opened > in the firewall settings: > TCP: 80, 88, 389 > UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > Also note that following ports are necessary for ipa-client working > properly after enrollment: > TCP: 464 > UDP: 464, 123 (if NTP enabled) > 2015-03-25T12:29:49Z DEBUG (ldap-inf-stg-sg1-01.sd.int: Provided as > option) > 2015-03-25T12:29:49Z ERROR Installation failed. Rolling back changes. > 2015-03-25T12:29:49Z DEBUG Loading Index file from > '/var/lib/ipa/sysrestore/sysrestore.index' > 2015-03-25T12:29:49Z DEBUG args=ipa-client-automount --uninstall --debug > 2015-03-25T12:29:49Z DEBUG stdout= > 2015-03-25T12:29:49Z DEBUG stderr=IPA client is not configured on this > system. > > > 2015-03-25T12:29:49Z ERROR Unconfigured automount client failed: Command > 'ipa-client-automount --uninstall --debug' returned non-zero exit status 1 > 2015-03-25T12:29:49Z DEBUG Loading Index file from > '/var/lib/ipa-client/sysrestore/sysrestore.index' > 2015-03-25T12:29:49Z DEBUG Loading StateFile from > '/var/lib/ipa-client/sysrestore/sysrestore.state' > 2015-03-25T12:29:49Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb -n > IPA CA > 2015-03-25T12:29:49Z DEBUG stdout= > 2015-03-25T12:29:49Z DEBUG stderr=certutil: Could not find cert: IPA CA > : PR_FILE_NOT_FOUND_ERROR: File not found > > 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus start > 2015-03-25T12:29:49Z DEBUG stdout=Starting system message bus: > > 2015-03-25T12:29:49Z DEBUG stderr= > 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus status > 2015-03-25T12:29:49Z DEBUG stdout=messagebus (pid 1151) is running... > > 2015-03-25T12:29:49Z DEBUG stderr= > 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger start > 2015-03-25T12:29:49Z DEBUG stdout= > 2015-03-25T12:29:49Z DEBUG stderr= > 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger status > 2015-03-25T12:29:49Z DEBUG stdout=certmonger (pid 13244) is running... > > 2015-03-25T12:29:49Z DEBUG stderr= > 2015-03-25T12:29:57Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb -n > IPA Machine Certificate - ldap-inf-stg-sg1-01.sd.int > 2015-03-25T12:29:57Z DEBUG stdout= > 2015-03-25T12:29:57Z DEBUG stderr=certutil: Could not find cert: IPA > Machine Certificate - ldap-inf-stg-sg1-01.sd.int > : PR_FILE_NOT_FOUND_ERROR: File not found > > 2015-03-25T12:29:57Z DEBUG args=/sbin/service certmonger stop > 2015-03-25T12:29:57Z DEBUG stdout=Stopping certmonger: [ OK ] > > 2015-03-25T12:29:57Z DEBUG stderr= > 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig certmonger off > 2015-03-25T12:29:59Z DEBUG stdout= > 2015-03-25T12:29:59Z DEBUG stderr= > 2015-03-25T12:29:59Z INFO Removing Kerberos service principals from > /etc/krb5.keytab > 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab > -r SD.INT > 2015-03-25T12:29:59Z DEBUG stdout= > 2015-03-25T12:29:59Z DEBUG stderr=Removing principal host/ > ldap-inf-stg-sg1-01.sd.int at SD.INT > > 2015-03-25T12:29:59Z INFO Disabling client Kerberos and LDAP configurations > 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/authconfig --disablekrb5 > --disablesssd --update --disablemkhomedir --disableldap --disablesssdauth > 2015-03-25T12:29:59Z DEBUG stdout= > 2015-03-25T12:29:59Z DEBUG stderr= > 2015-03-25T12:29:59Z DEBUG Error while moving /etc/sssd/sssd.conf to > /etc/sssd/sssd.conf.deleted > 2015-03-25T12:29:59Z INFO Redundant SSSD configuration file > /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted > 2015-03-25T12:29:59Z DEBUG args=/sbin/service sssd stop > 2015-03-25T12:29:59Z DEBUG stdout= > 2015-03-25T12:29:59Z DEBUG stderr= > 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig sssd off > 2015-03-25T12:29:59Z DEBUG stdout= > 2015-03-25T12:29:59Z DEBUG stderr= > 2015-03-25T12:29:59Z DEBUG args=/sbin/service nscd status > 2015-03-25T12:29:59Z DEBUG stdout= > 2015-03-25T12:29:59Z DEBUG stderr=nscd: unrecognized service > > 2015-03-25T12:29:59Z INFO nscd daemon is not installed, skip configuration > 2015-03-25T12:29:59Z DEBUG args=/sbin/service nslcd status > 2015-03-25T12:29:59Z DEBUG stdout= > 2015-03-25T12:29:59Z DEBUG stderr=nslcd: unrecognized service > > 2015-03-25T12:29:59Z INFO nslcd daemon is not installed, skip configuration > 2015-03-25T12:29:59Z INFO Client uninstall complete. > > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Wed, Mar 25, 2015 at 6:10 PM, Martin Kosek wrote: > >> On 03/25/2015 07:46 AM, Yogesh Sharma wrote: >> > Hi, >> > >> > We are getting below error while we are installing IPA Server >> > (ipa-server-install --no-ntp). >> > >> > >> > ** >> > *Configuration of client side components failed!* >> > *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >> > --on-master --unattended --domain sd.int --server >> > ldap-inf-stg-sg1-01.sd.int --realm >> > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >> > ' returned non-zero exit status 1* >> > >> > **Logs indicate below errors: >> > >> > *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h >> > ldap-inf-stg-sg1-01.sd.int -ZZ -x >> -D >> > cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn >> > uid=admin,cn=users,cn=accounts,dc=sd,dc=int* >> > *2015-03-25T06:39:59Z DEBUG stdout=* >> > *2015-03-25T06:39:59Z DEBUG stderr=* >> > *2015-03-25T06:39:59Z DEBUG ldappasswd done* >> > *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install >> --on-master >> > --unattended --domain sd.int --server >> > ldap-inf-stg-sg1-01.sd.int --realm >> > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >> > * >> > *2015-03-25T06:40:10Z DEBUG stdout=* >> > *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that >> > ldap-inf-stg-sg1-01.sd.int 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.* >> > *Unconfigured automount client failed: Command 'ipa-client-automount >> > --uninstall --debug' returned non-zero exit status 1* >> > *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* >> > *nscd daemon is not installed, skip configuration* >> > *nslcd daemon is not installed, skip configuration* >> > *Client uninstall complete.* >> > >> > *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* >> > * sys.exit("Configuration of client side components >> > failed!\nipa-client-install returned: " + str(e))* >> > >> > *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, >> > exception: SystemExit: Configuration of client side components failed!* >> > *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >> > --on-master --unattended --domain sd.int --server >> > ldap-inf-stg-sg1-01.sd.int --realm >> > SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >> > ' returned non-zero exit status 1* >> > >> > ** >> > >> > >> > This server is on AWS and I can confirm that all above ports are opened. >> > Also as it is installing on same server where IPA Server is being >> > installed, Port should not be an issue. >> > >> > Am I missing anything here. >> >> Please also share ipaclient-install.log, it should show what is the exact >> problem in the client component installation. >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Mar 25 13:13:36 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Mar 2015 14:13:36 +0100 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: References: <5512ACCC.9000608@redhat.com> Message-ID: <5512B480.7030508@redhat.com> Ah, may be. This is an issue we fixed in FreeIPA 4.0.2. Upstream ticket: https://fedorahosted.org/freeipa/ticket/4444 Please let us know if the DNS update fixed the error. Martin On 03/25/2015 02:11 PM, Yogesh Sharma wrote: > I think I got the issue. Realm Name Entry in DNS is added in lower case > rather than UPPER. > > 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT > ,cn=kerberos,dc=sd,dc=int > 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, > domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > > Will try changing the Realm and see if it resovled. > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Wed, Mar 25, 2015 at 6:13 PM, Yogesh Sharma wrote: > >> Hi Martin, >> >> Please find the client logs: >> >> >> >> 2015-03-25T12:29:49Z DEBUG /usr/sbin/ipa-client-install was invoked with >> options: {'domain': 'sd.int', 'force': False, 'krb5_offline_passwords': >> True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, >> 'conf_sshd': True, 'conf_ntp': True, 'on_master': True, 'ntp_server': None, >> 'server': ['ldap-inf-stg-sg1-01.sd.int'], 'no_nisdomain': False, >> 'principal': None, 'hostname': 'ldap-inf-stg-sg1-01.sd.int', 'no_ac': >> False, 'unattended': True, 'sssd': True, 'trust_sshfp': False, >> 'realm_name': 'SD.INT', 'dns_updates': False, 'conf_sudo': True, >> 'conf_ssh': True, 'force_join': False, 'ca_cert_file': None, 'nisdomain': >> None, 'prompt_password': False, 'permit': False, 'debug': False, >> 'preserve_sssd': False, 'uninstall': False} >> 2015-03-25T12:29:49Z DEBUG missing options might be asked for >> interactively later >> 2015-03-25T12:29:49Z DEBUG Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> 2015-03-25T12:29:49Z DEBUG Loading StateFile from >> '/var/lib/ipa-client/sysrestore/sysrestore.state' >> 2015-03-25T12:29:49Z DEBUG [IPA Discovery] >> 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, >> servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= >> ldap-inf-stg-sg1-01.sd.int >> 2015-03-25T12:29:49Z DEBUG Server and domain forced >> 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] >> 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _kerberos.sd.int. >> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ >> kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} >> 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ >> udp.sd.int. >> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ >> udp.sd.int.,type:33,class:1,rdata={priority:0,port:88,weight:100,server: >> ldap-inf-stg-sg1-01.sd.int.} >> 2015-03-25T12:29:49Z DEBUG [LDAP server check] >> 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int >> (realm sd.int) is an IPA server >> 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// >> ldap-inf-stg-sg1-01.sd.int:389 >> 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN >> 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for >> IPA >> 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA >> context >> 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in >> dc=sd,dc=int (sub) >> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int >> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, >> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int >> 2015-03-25T12:29:49Z DEBUG Validated servers: >> 2015-03-25T12:29:49Z DEBUG will use discovered domain: sd.int >> 2015-03-25T12:29:49Z DEBUG IPA Server not found >> 2015-03-25T12:29:49Z DEBUG [IPA Discovery] >> 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, >> servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= >> ldap-inf-stg-sg1-01.sd.int >> 2015-03-25T12:29:49Z DEBUG Server and domain forced >> 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] >> 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _kerberos.sd.int. >> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ >> kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} >> 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ >> udp.sd.int. >> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ >> udp.sd.int.,type:33,class:1,rdata={priority:0,port:88,weight:100,server: >> ldap-inf-stg-sg1-01.sd.int.} >> 2015-03-25T12:29:49Z DEBUG [LDAP server check] >> 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int >> (realm sd.int) is an IPA server >> 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// >> ldap-inf-stg-sg1-01.sd.int:389 >> 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN >> 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for >> IPA >> 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA >> context >> 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in >> dc=sd,dc=int (sub) >> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int >> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; server=None, >> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int >> 2015-03-25T12:29:49Z DEBUG Validated servers: >> 2015-03-25T12:29:49Z ERROR Failed to verify that >> ldap-inf-stg-sg1-01.sd.int is an IPA Server. >> 2015-03-25T12:29:49Z ERROR This may mean that the remote server is not up >> or is not reachable due to network or firewall settings. >> 2015-03-25T12:29:49Z INFO Please make sure the following ports are opened >> in the firewall settings: >> TCP: 80, 88, 389 >> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) >> Also note that following ports are necessary for ipa-client working >> properly after enrollment: >> TCP: 464 >> UDP: 464, 123 (if NTP enabled) >> 2015-03-25T12:29:49Z DEBUG (ldap-inf-stg-sg1-01.sd.int: Provided as >> option) >> 2015-03-25T12:29:49Z ERROR Installation failed. Rolling back changes. >> 2015-03-25T12:29:49Z DEBUG Loading Index file from >> '/var/lib/ipa/sysrestore/sysrestore.index' >> 2015-03-25T12:29:49Z DEBUG args=ipa-client-automount --uninstall --debug >> 2015-03-25T12:29:49Z DEBUG stdout= >> 2015-03-25T12:29:49Z DEBUG stderr=IPA client is not configured on this >> system. >> >> >> 2015-03-25T12:29:49Z ERROR Unconfigured automount client failed: Command >> 'ipa-client-automount --uninstall --debug' returned non-zero exit status 1 >> 2015-03-25T12:29:49Z DEBUG Loading Index file from >> '/var/lib/ipa-client/sysrestore/sysrestore.index' >> 2015-03-25T12:29:49Z DEBUG Loading StateFile from >> '/var/lib/ipa-client/sysrestore/sysrestore.state' >> 2015-03-25T12:29:49Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb -n >> IPA CA >> 2015-03-25T12:29:49Z DEBUG stdout= >> 2015-03-25T12:29:49Z DEBUG stderr=certutil: Could not find cert: IPA CA >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus start >> 2015-03-25T12:29:49Z DEBUG stdout=Starting system message bus: >> >> 2015-03-25T12:29:49Z DEBUG stderr= >> 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus status >> 2015-03-25T12:29:49Z DEBUG stdout=messagebus (pid 1151) is running... >> >> 2015-03-25T12:29:49Z DEBUG stderr= >> 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger start >> 2015-03-25T12:29:49Z DEBUG stdout= >> 2015-03-25T12:29:49Z DEBUG stderr= >> 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger status >> 2015-03-25T12:29:49Z DEBUG stdout=certmonger (pid 13244) is running... >> >> 2015-03-25T12:29:49Z DEBUG stderr= >> 2015-03-25T12:29:57Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb -n >> IPA Machine Certificate - ldap-inf-stg-sg1-01.sd.int >> 2015-03-25T12:29:57Z DEBUG stdout= >> 2015-03-25T12:29:57Z DEBUG stderr=certutil: Could not find cert: IPA >> Machine Certificate - ldap-inf-stg-sg1-01.sd.int >> : PR_FILE_NOT_FOUND_ERROR: File not found >> >> 2015-03-25T12:29:57Z DEBUG args=/sbin/service certmonger stop >> 2015-03-25T12:29:57Z DEBUG stdout=Stopping certmonger: [ OK ] >> >> 2015-03-25T12:29:57Z DEBUG stderr= >> 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig certmonger off >> 2015-03-25T12:29:59Z DEBUG stdout= >> 2015-03-25T12:29:59Z DEBUG stderr= >> 2015-03-25T12:29:59Z INFO Removing Kerberos service principals from >> /etc/krb5.keytab >> 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/ipa-rmkeytab -k /etc/krb5.keytab >> -r SD.INT >> 2015-03-25T12:29:59Z DEBUG stdout= >> 2015-03-25T12:29:59Z DEBUG stderr=Removing principal host/ >> ldap-inf-stg-sg1-01.sd.int at SD.INT >> >> 2015-03-25T12:29:59Z INFO Disabling client Kerberos and LDAP configurations >> 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/authconfig --disablekrb5 >> --disablesssd --update --disablemkhomedir --disableldap --disablesssdauth >> 2015-03-25T12:29:59Z DEBUG stdout= >> 2015-03-25T12:29:59Z DEBUG stderr= >> 2015-03-25T12:29:59Z DEBUG Error while moving /etc/sssd/sssd.conf to >> /etc/sssd/sssd.conf.deleted >> 2015-03-25T12:29:59Z INFO Redundant SSSD configuration file >> /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted >> 2015-03-25T12:29:59Z DEBUG args=/sbin/service sssd stop >> 2015-03-25T12:29:59Z DEBUG stdout= >> 2015-03-25T12:29:59Z DEBUG stderr= >> 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig sssd off >> 2015-03-25T12:29:59Z DEBUG stdout= >> 2015-03-25T12:29:59Z DEBUG stderr= >> 2015-03-25T12:29:59Z DEBUG args=/sbin/service nscd status >> 2015-03-25T12:29:59Z DEBUG stdout= >> 2015-03-25T12:29:59Z DEBUG stderr=nscd: unrecognized service >> >> 2015-03-25T12:29:59Z INFO nscd daemon is not installed, skip configuration >> 2015-03-25T12:29:59Z DEBUG args=/sbin/service nslcd status >> 2015-03-25T12:29:59Z DEBUG stdout= >> 2015-03-25T12:29:59Z DEBUG stderr=nslcd: unrecognized service >> >> 2015-03-25T12:29:59Z INFO nslcd daemon is not installed, skip configuration >> 2015-03-25T12:29:59Z INFO Client uninstall complete. >> >> >> >> >> >> *Best Regards,__________________________________________* >> >> *Yogesh Sharma* >> *Email: yks0000 at gmail.com | Web: www.initd.in >> * >> >> RHCE, VCE-CIA, RackSpace Cloud U >> [image: My LinkedIn Profile] >> >> >> On Wed, Mar 25, 2015 at 6:10 PM, Martin Kosek wrote: >> >>> On 03/25/2015 07:46 AM, Yogesh Sharma wrote: >>>> Hi, >>>> >>>> We are getting below error while we are installing IPA Server >>>> (ipa-server-install --no-ntp). >>>> >>>> >>>> ** >>>> *Configuration of client side components failed!* >>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >>>> --on-master --unattended --domain sd.int --server >>>> ldap-inf-stg-sg1-01.sd.int --realm >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>> ' returned non-zero exit status 1* >>>> >>>> **Logs indicate below errors: >>>> >>>> *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h >>>> ldap-inf-stg-sg1-01.sd.int -ZZ -x >>> -D >>>> cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T /var/lib/ipa/tmp0iYpzn >>>> uid=admin,cn=users,cn=accounts,dc=sd,dc=int* >>>> *2015-03-25T06:39:59Z DEBUG stdout=* >>>> *2015-03-25T06:39:59Z DEBUG stderr=* >>>> *2015-03-25T06:39:59Z DEBUG ldappasswd done* >>>> *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install >>> --on-master >>>> --unattended --domain sd.int --server >>>> ldap-inf-stg-sg1-01.sd.int --realm >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>> * >>>> *2015-03-25T06:40:10Z DEBUG stdout=* >>>> *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that >>>> ldap-inf-stg-sg1-01.sd.int 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.* >>>> *Unconfigured automount client failed: Command 'ipa-client-automount >>>> --uninstall --debug' returned non-zero exit status 1* >>>> *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* >>>> *nscd daemon is not installed, skip configuration* >>>> *nslcd daemon is not installed, skip configuration* >>>> *Client uninstall complete.* >>>> >>>> *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* >>>> * sys.exit("Configuration of client side components >>>> failed!\nipa-client-install returned: " + str(e))* >>>> >>>> *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, >>>> exception: SystemExit: Configuration of client side components failed!* >>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >>>> --on-master --unattended --domain sd.int --server >>>> ldap-inf-stg-sg1-01.sd.int --realm >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>> ' returned non-zero exit status 1* >>>> >>>> ** >>>> >>>> >>>> This server is on AWS and I can confirm that all above ports are opened. >>>> Also as it is installing on same server where IPA Server is being >>>> installed, Port should not be an issue. >>>> >>>> Am I missing anything here. >>> >>> Please also share ipaclient-install.log, it should show what is the exact >>> problem in the client component installation. >>> >>> >> > From yks0000 at gmail.com Wed Mar 25 13:30:06 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 19:00:06 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: <5512B480.7030508@redhat.com> References: <5512ACCC.9000608@redhat.com> <5512B480.7030508@redhat.com> Message-ID: Hi Martin, Finally, the issue has resolved. :) Is there RPM available to install latest IPA version in CentOS or at least 4.0.2 version. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Wed, Mar 25, 2015 at 6:43 PM, Martin Kosek wrote: > Ah, may be. This is an issue we fixed in FreeIPA 4.0.2. Upstream ticket: > > https://fedorahosted.org/freeipa/ticket/4444 > > Please let us know if the DNS update fixed the error. > > Martin > > On 03/25/2015 02:11 PM, Yogesh Sharma wrote: > > I think I got the issue. Realm Name Entry in DNS is added in lower case > > rather than UPPER. > > > > 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT > > ,cn=kerberos,dc=sd,dc=int > > 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; > server=None, > > domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > > > > Will try changing the Realm and see if it resovled. > > > > > > > > > > *Best Regards,__________________________________________* > > > > *Yogesh Sharma* > > *Email: yks0000 at gmail.com | Web: www.initd.in > > * > > > > RHCE, VCE-CIA, RackSpace Cloud U > > [image: My LinkedIn Profile] > > > > > > On Wed, Mar 25, 2015 at 6:13 PM, Yogesh Sharma > wrote: > > > >> Hi Martin, > >> > >> Please find the client logs: > >> > >> > >> > >> 2015-03-25T12:29:49Z DEBUG /usr/sbin/ipa-client-install was invoked with > >> options: {'domain': 'sd.int', 'force': False, 'krb5_offline_passwords': > >> True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, > >> 'conf_sshd': True, 'conf_ntp': True, 'on_master': True, 'ntp_server': > None, > >> 'server': ['ldap-inf-stg-sg1-01.sd.int'], 'no_nisdomain': False, > >> 'principal': None, 'hostname': 'ldap-inf-stg-sg1-01.sd.int', 'no_ac': > >> False, 'unattended': True, 'sssd': True, 'trust_sshfp': False, > >> 'realm_name': 'SD.INT', 'dns_updates': False, 'conf_sudo': True, > >> 'conf_ssh': True, 'force_join': False, 'ca_cert_file': None, > 'nisdomain': > >> None, 'prompt_password': False, 'permit': False, 'debug': False, > >> 'preserve_sssd': False, 'uninstall': False} > >> 2015-03-25T12:29:49Z DEBUG missing options might be asked for > >> interactively later > >> 2015-03-25T12:29:49Z DEBUG Loading Index file from > >> '/var/lib/ipa-client/sysrestore/sysrestore.index' > >> 2015-03-25T12:29:49Z DEBUG Loading StateFile from > >> '/var/lib/ipa-client/sysrestore/sysrestore.state' > >> 2015-03-25T12:29:49Z DEBUG [IPA Discovery] > >> 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, > >> servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= > >> ldap-inf-stg-sg1-01.sd.int > >> 2015-03-25T12:29:49Z DEBUG Server and domain forced > >> 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] > >> 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _ > kerberos.sd.int. > >> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ > >> kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} > >> 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ > >> udp.sd.int. > >> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ > >> udp.sd.int > .,type:33,class:1,rdata={priority:0,port:88,weight:100,server: > >> ldap-inf-stg-sg1-01.sd.int.} > >> 2015-03-25T12:29:49Z DEBUG [LDAP server check] > >> 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int > >> (realm sd.int) is an IPA server > >> 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// > >> ldap-inf-stg-sg1-01.sd.int:389 > >> 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN > >> 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for > >> IPA > >> 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA > >> context > >> 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in > >> dc=sd,dc=int (sub) > >> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int > >> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; > server=None, > >> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > >> 2015-03-25T12:29:49Z DEBUG Validated servers: > >> 2015-03-25T12:29:49Z DEBUG will use discovered domain: sd.int > >> 2015-03-25T12:29:49Z DEBUG IPA Server not found > >> 2015-03-25T12:29:49Z DEBUG [IPA Discovery] > >> 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, > >> servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= > >> ldap-inf-stg-sg1-01.sd.int > >> 2015-03-25T12:29:49Z DEBUG Server and domain forced > >> 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] > >> 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _ > kerberos.sd.int. > >> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ > >> kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} > >> 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ > >> udp.sd.int. > >> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ > >> udp.sd.int > .,type:33,class:1,rdata={priority:0,port:88,weight:100,server: > >> ldap-inf-stg-sg1-01.sd.int.} > >> 2015-03-25T12:29:49Z DEBUG [LDAP server check] > >> 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int > >> (realm sd.int) is an IPA server > >> 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// > >> ldap-inf-stg-sg1-01.sd.int:389 > >> 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN > >> 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for > >> IPA > >> 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA > >> context > >> 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in > >> dc=sd,dc=int (sub) > >> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int > >> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; > server=None, > >> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > >> 2015-03-25T12:29:49Z DEBUG Validated servers: > >> 2015-03-25T12:29:49Z ERROR Failed to verify that > >> ldap-inf-stg-sg1-01.sd.int is an IPA Server. > >> 2015-03-25T12:29:49Z ERROR This may mean that the remote server is not > up > >> or is not reachable due to network or firewall settings. > >> 2015-03-25T12:29:49Z INFO Please make sure the following ports are > opened > >> in the firewall settings: > >> TCP: 80, 88, 389 > >> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > >> Also note that following ports are necessary for ipa-client working > >> properly after enrollment: > >> TCP: 464 > >> UDP: 464, 123 (if NTP enabled) > >> 2015-03-25T12:29:49Z DEBUG (ldap-inf-stg-sg1-01.sd.int: Provided as > >> option) > >> 2015-03-25T12:29:49Z ERROR Installation failed. Rolling back changes. > >> 2015-03-25T12:29:49Z DEBUG Loading Index file from > >> '/var/lib/ipa/sysrestore/sysrestore.index' > >> 2015-03-25T12:29:49Z DEBUG args=ipa-client-automount --uninstall --debug > >> 2015-03-25T12:29:49Z DEBUG stdout= > >> 2015-03-25T12:29:49Z DEBUG stderr=IPA client is not configured on this > >> system. > >> > >> > >> 2015-03-25T12:29:49Z ERROR Unconfigured automount client failed: Command > >> 'ipa-client-automount --uninstall --debug' returned non-zero exit > status 1 > >> 2015-03-25T12:29:49Z DEBUG Loading Index file from > >> '/var/lib/ipa-client/sysrestore/sysrestore.index' > >> 2015-03-25T12:29:49Z DEBUG Loading StateFile from > >> '/var/lib/ipa-client/sysrestore/sysrestore.state' > >> 2015-03-25T12:29:49Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb > -n > >> IPA CA > >> 2015-03-25T12:29:49Z DEBUG stdout= > >> 2015-03-25T12:29:49Z DEBUG stderr=certutil: Could not find cert: IPA CA > >> : PR_FILE_NOT_FOUND_ERROR: File not found > >> > >> 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus start > >> 2015-03-25T12:29:49Z DEBUG stdout=Starting system message bus: > >> > >> 2015-03-25T12:29:49Z DEBUG stderr= > >> 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus status > >> 2015-03-25T12:29:49Z DEBUG stdout=messagebus (pid 1151) is running... > >> > >> 2015-03-25T12:29:49Z DEBUG stderr= > >> 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger start > >> 2015-03-25T12:29:49Z DEBUG stdout= > >> 2015-03-25T12:29:49Z DEBUG stderr= > >> 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger status > >> 2015-03-25T12:29:49Z DEBUG stdout=certmonger (pid 13244) is running... > >> > >> 2015-03-25T12:29:49Z DEBUG stderr= > >> 2015-03-25T12:29:57Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb > -n > >> IPA Machine Certificate - ldap-inf-stg-sg1-01.sd.int > >> 2015-03-25T12:29:57Z DEBUG stdout= > >> 2015-03-25T12:29:57Z DEBUG stderr=certutil: Could not find cert: IPA > >> Machine Certificate - ldap-inf-stg-sg1-01.sd.int > >> : PR_FILE_NOT_FOUND_ERROR: File not found > >> > >> 2015-03-25T12:29:57Z DEBUG args=/sbin/service certmonger stop > >> 2015-03-25T12:29:57Z DEBUG stdout=Stopping certmonger: [ OK ] > >> > >> 2015-03-25T12:29:57Z DEBUG stderr= > >> 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig certmonger off > >> 2015-03-25T12:29:59Z DEBUG stdout= > >> 2015-03-25T12:29:59Z DEBUG stderr= > >> 2015-03-25T12:29:59Z INFO Removing Kerberos service principals from > >> /etc/krb5.keytab > >> 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/ipa-rmkeytab -k > /etc/krb5.keytab > >> -r SD.INT > >> 2015-03-25T12:29:59Z DEBUG stdout= > >> 2015-03-25T12:29:59Z DEBUG stderr=Removing principal host/ > >> ldap-inf-stg-sg1-01.sd.int at SD.INT > >> > >> 2015-03-25T12:29:59Z INFO Disabling client Kerberos and LDAP > configurations > >> 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/authconfig --disablekrb5 > >> --disablesssd --update --disablemkhomedir --disableldap > --disablesssdauth > >> 2015-03-25T12:29:59Z DEBUG stdout= > >> 2015-03-25T12:29:59Z DEBUG stderr= > >> 2015-03-25T12:29:59Z DEBUG Error while moving /etc/sssd/sssd.conf to > >> /etc/sssd/sssd.conf.deleted > >> 2015-03-25T12:29:59Z INFO Redundant SSSD configuration file > >> /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted > >> 2015-03-25T12:29:59Z DEBUG args=/sbin/service sssd stop > >> 2015-03-25T12:29:59Z DEBUG stdout= > >> 2015-03-25T12:29:59Z DEBUG stderr= > >> 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig sssd off > >> 2015-03-25T12:29:59Z DEBUG stdout= > >> 2015-03-25T12:29:59Z DEBUG stderr= > >> 2015-03-25T12:29:59Z DEBUG args=/sbin/service nscd status > >> 2015-03-25T12:29:59Z DEBUG stdout= > >> 2015-03-25T12:29:59Z DEBUG stderr=nscd: unrecognized service > >> > >> 2015-03-25T12:29:59Z INFO nscd daemon is not installed, skip > configuration > >> 2015-03-25T12:29:59Z DEBUG args=/sbin/service nslcd status > >> 2015-03-25T12:29:59Z DEBUG stdout= > >> 2015-03-25T12:29:59Z DEBUG stderr=nslcd: unrecognized service > >> > >> 2015-03-25T12:29:59Z INFO nslcd daemon is not installed, skip > configuration > >> 2015-03-25T12:29:59Z INFO Client uninstall complete. > >> > >> > >> > >> > >> > >> *Best Regards,__________________________________________* > >> > >> *Yogesh Sharma* > >> *Email: yks0000 at gmail.com | Web: www.initd.in > >> * > >> > >> RHCE, VCE-CIA, RackSpace Cloud U > >> [image: My LinkedIn Profile] > >> > >> > >> On Wed, Mar 25, 2015 at 6:10 PM, Martin Kosek > wrote: > >> > >>> On 03/25/2015 07:46 AM, Yogesh Sharma wrote: > >>>> Hi, > >>>> > >>>> We are getting below error while we are installing IPA Server > >>>> (ipa-server-install --no-ntp). > >>>> > >>>> > >>>> ** > >>>> *Configuration of client side components failed!* > >>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > >>>> --on-master --unattended --domain sd.int --server > >>>> ldap-inf-stg-sg1-01.sd.int > --realm > >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > >>>> ' returned non-zero exit status 1* > >>>> > >>>> **Logs indicate below errors: > >>>> > >>>> *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h > >>>> ldap-inf-stg-sg1-01.sd.int -ZZ -x > >>> -D > >>>> cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T > /var/lib/ipa/tmp0iYpzn > >>>> uid=admin,cn=users,cn=accounts,dc=sd,dc=int* > >>>> *2015-03-25T06:39:59Z DEBUG stdout=* > >>>> *2015-03-25T06:39:59Z DEBUG stderr=* > >>>> *2015-03-25T06:39:59Z DEBUG ldappasswd done* > >>>> *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install > >>> --on-master > >>>> --unattended --domain sd.int --server > >>>> ldap-inf-stg-sg1-01.sd.int > --realm > >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > >>>> * > >>>> *2015-03-25T06:40:10Z DEBUG stdout=* > >>>> *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that > >>>> ldap-inf-stg-sg1-01.sd.int 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.* > >>>> *Unconfigured automount client failed: Command 'ipa-client-automount > >>>> --uninstall --debug' returned non-zero exit status 1* > >>>> *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* > >>>> *nscd daemon is not installed, skip configuration* > >>>> *nslcd daemon is not installed, skip configuration* > >>>> *Client uninstall complete.* > >>>> > >>>> *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* > >>>> * sys.exit("Configuration of client side components > >>>> failed!\nipa-client-install returned: " + str(e))* > >>>> > >>>> *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, > >>>> exception: SystemExit: Configuration of client side components > failed!* > >>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > >>>> --on-master --unattended --domain sd.int --server > >>>> ldap-inf-stg-sg1-01.sd.int > --realm > >>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > >>>> ' returned non-zero exit status 1* > >>>> > >>>> ** > >>>> > >>>> > >>>> This server is on AWS and I can confirm that all above ports are > opened. > >>>> Also as it is installing on same server where IPA Server is being > >>>> installed, Port should not be an issue. > >>>> > >>>> Am I missing anything here. > >>> > >>> Please also share ipaclient-install.log, it should show what is the > exact > >>> problem in the client component installation. > >>> > >>> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Wed Mar 25 13:37:22 2015 From: mkosek at redhat.com (Martin Kosek) Date: Wed, 25 Mar 2015 14:37:22 +0100 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: References: <5512ACCC.9000608@redhat.com> <5512B480.7030508@redhat.com> Message-ID: <5512BA12.9020008@redhat.com> This should be in the official RHEL-7.1/CentOS-7.1 repos. Or you can try our upstream CentOS-7 based Copr repo: https://copr.fedoraproject.org/coprs/mkosek/freeipa/ On 03/25/2015 02:30 PM, Yogesh Sharma wrote: > Hi Martin, > > Finally, the issue has resolved. :) > > Is there RPM available to install latest IPA version in CentOS or at least > 4.0.2 version. > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Wed, Mar 25, 2015 at 6:43 PM, Martin Kosek wrote: > >> Ah, may be. This is an issue we fixed in FreeIPA 4.0.2. Upstream ticket: >> >> https://fedorahosted.org/freeipa/ticket/4444 >> >> Please let us know if the DNS update fixed the error. >> >> Martin >> >> On 03/25/2015 02:11 PM, Yogesh Sharma wrote: >>> I think I got the issue. Realm Name Entry in DNS is added in lower case >>> rather than UPPER. >>> >>> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT >>> ,cn=kerberos,dc=sd,dc=int >>> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; >> server=None, >>> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int >>> >>> Will try changing the Realm and see if it resovled. >>> >>> >>> >>> >>> *Best Regards,__________________________________________* >>> >>> *Yogesh Sharma* >>> *Email: yks0000 at gmail.com | Web: www.initd.in >>> * >>> >>> RHCE, VCE-CIA, RackSpace Cloud U >>> [image: My LinkedIn Profile] >>> >>> >>> On Wed, Mar 25, 2015 at 6:13 PM, Yogesh Sharma >> wrote: >>> >>>> Hi Martin, >>>> >>>> Please find the client logs: >>>> >>>> >>>> >>>> 2015-03-25T12:29:49Z DEBUG /usr/sbin/ipa-client-install was invoked with >>>> options: {'domain': 'sd.int', 'force': False, 'krb5_offline_passwords': >>>> True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, >>>> 'conf_sshd': True, 'conf_ntp': True, 'on_master': True, 'ntp_server': >> None, >>>> 'server': ['ldap-inf-stg-sg1-01.sd.int'], 'no_nisdomain': False, >>>> 'principal': None, 'hostname': 'ldap-inf-stg-sg1-01.sd.int', 'no_ac': >>>> False, 'unattended': True, 'sssd': True, 'trust_sshfp': False, >>>> 'realm_name': 'SD.INT', 'dns_updates': False, 'conf_sudo': True, >>>> 'conf_ssh': True, 'force_join': False, 'ca_cert_file': None, >> 'nisdomain': >>>> None, 'prompt_password': False, 'permit': False, 'debug': False, >>>> 'preserve_sssd': False, 'uninstall': False} >>>> 2015-03-25T12:29:49Z DEBUG missing options might be asked for >>>> interactively later >>>> 2015-03-25T12:29:49Z DEBUG Loading Index file from >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>> 2015-03-25T12:29:49Z DEBUG Loading StateFile from >>>> '/var/lib/ipa-client/sysrestore/sysrestore.state' >>>> 2015-03-25T12:29:49Z DEBUG [IPA Discovery] >>>> 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, >>>> servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= >>>> ldap-inf-stg-sg1-01.sd.int >>>> 2015-03-25T12:29:49Z DEBUG Server and domain forced >>>> 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] >>>> 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _ >> kerberos.sd.int. >>>> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ >>>> kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} >>>> 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ >>>> udp.sd.int. >>>> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ >>>> udp.sd.int >> .,type:33,class:1,rdata={priority:0,port:88,weight:100,server: >>>> ldap-inf-stg-sg1-01.sd.int.} >>>> 2015-03-25T12:29:49Z DEBUG [LDAP server check] >>>> 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int >>>> (realm sd.int) is an IPA server >>>> 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// >>>> ldap-inf-stg-sg1-01.sd.int:389 >>>> 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN >>>> 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for >>>> IPA >>>> 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA >>>> context >>>> 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in >>>> dc=sd,dc=int (sub) >>>> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int >>>> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; >> server=None, >>>> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int >>>> 2015-03-25T12:29:49Z DEBUG Validated servers: >>>> 2015-03-25T12:29:49Z DEBUG will use discovered domain: sd.int >>>> 2015-03-25T12:29:49Z DEBUG IPA Server not found >>>> 2015-03-25T12:29:49Z DEBUG [IPA Discovery] >>>> 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, >>>> servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= >>>> ldap-inf-stg-sg1-01.sd.int >>>> 2015-03-25T12:29:49Z DEBUG Server and domain forced >>>> 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] >>>> 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _ >> kerberos.sd.int. >>>> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ >>>> kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} >>>> 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ >>>> udp.sd.int. >>>> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_kerberos._ >>>> udp.sd.int >> .,type:33,class:1,rdata={priority:0,port:88,weight:100,server: >>>> ldap-inf-stg-sg1-01.sd.int.} >>>> 2015-03-25T12:29:49Z DEBUG [LDAP server check] >>>> 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int >>>> (realm sd.int) is an IPA server >>>> 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// >>>> ldap-inf-stg-sg1-01.sd.int:389 >>>> 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN >>>> 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is for >>>> IPA >>>> 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid IPA >>>> context >>>> 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) in >>>> dc=sd,dc=int (sub) >>>> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int >>>> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; >> server=None, >>>> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int >>>> 2015-03-25T12:29:49Z DEBUG Validated servers: >>>> 2015-03-25T12:29:49Z ERROR Failed to verify that >>>> ldap-inf-stg-sg1-01.sd.int is an IPA Server. >>>> 2015-03-25T12:29:49Z ERROR This may mean that the remote server is not >> up >>>> or is not reachable due to network or firewall settings. >>>> 2015-03-25T12:29:49Z INFO Please make sure the following ports are >> opened >>>> in the firewall settings: >>>> TCP: 80, 88, 389 >>>> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) >>>> Also note that following ports are necessary for ipa-client working >>>> properly after enrollment: >>>> TCP: 464 >>>> UDP: 464, 123 (if NTP enabled) >>>> 2015-03-25T12:29:49Z DEBUG (ldap-inf-stg-sg1-01.sd.int: Provided as >>>> option) >>>> 2015-03-25T12:29:49Z ERROR Installation failed. Rolling back changes. >>>> 2015-03-25T12:29:49Z DEBUG Loading Index file from >>>> '/var/lib/ipa/sysrestore/sysrestore.index' >>>> 2015-03-25T12:29:49Z DEBUG args=ipa-client-automount --uninstall --debug >>>> 2015-03-25T12:29:49Z DEBUG stdout= >>>> 2015-03-25T12:29:49Z DEBUG stderr=IPA client is not configured on this >>>> system. >>>> >>>> >>>> 2015-03-25T12:29:49Z ERROR Unconfigured automount client failed: Command >>>> 'ipa-client-automount --uninstall --debug' returned non-zero exit >> status 1 >>>> 2015-03-25T12:29:49Z DEBUG Loading Index file from >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' >>>> 2015-03-25T12:29:49Z DEBUG Loading StateFile from >>>> '/var/lib/ipa-client/sysrestore/sysrestore.state' >>>> 2015-03-25T12:29:49Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb >> -n >>>> IPA CA >>>> 2015-03-25T12:29:49Z DEBUG stdout= >>>> 2015-03-25T12:29:49Z DEBUG stderr=certutil: Could not find cert: IPA CA >>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus start >>>> 2015-03-25T12:29:49Z DEBUG stdout=Starting system message bus: >>>> >>>> 2015-03-25T12:29:49Z DEBUG stderr= >>>> 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus status >>>> 2015-03-25T12:29:49Z DEBUG stdout=messagebus (pid 1151) is running... >>>> >>>> 2015-03-25T12:29:49Z DEBUG stderr= >>>> 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger start >>>> 2015-03-25T12:29:49Z DEBUG stdout= >>>> 2015-03-25T12:29:49Z DEBUG stderr= >>>> 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger status >>>> 2015-03-25T12:29:49Z DEBUG stdout=certmonger (pid 13244) is running... >>>> >>>> 2015-03-25T12:29:49Z DEBUG stderr= >>>> 2015-03-25T12:29:57Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb >> -n >>>> IPA Machine Certificate - ldap-inf-stg-sg1-01.sd.int >>>> 2015-03-25T12:29:57Z DEBUG stdout= >>>> 2015-03-25T12:29:57Z DEBUG stderr=certutil: Could not find cert: IPA >>>> Machine Certificate - ldap-inf-stg-sg1-01.sd.int >>>> : PR_FILE_NOT_FOUND_ERROR: File not found >>>> >>>> 2015-03-25T12:29:57Z DEBUG args=/sbin/service certmonger stop >>>> 2015-03-25T12:29:57Z DEBUG stdout=Stopping certmonger: [ OK ] >>>> >>>> 2015-03-25T12:29:57Z DEBUG stderr= >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig certmonger off >>>> 2015-03-25T12:29:59Z DEBUG stdout= >>>> 2015-03-25T12:29:59Z DEBUG stderr= >>>> 2015-03-25T12:29:59Z INFO Removing Kerberos service principals from >>>> /etc/krb5.keytab >>>> 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/ipa-rmkeytab -k >> /etc/krb5.keytab >>>> -r SD.INT >>>> 2015-03-25T12:29:59Z DEBUG stdout= >>>> 2015-03-25T12:29:59Z DEBUG stderr=Removing principal host/ >>>> ldap-inf-stg-sg1-01.sd.int at SD.INT >>>> >>>> 2015-03-25T12:29:59Z INFO Disabling client Kerberos and LDAP >> configurations >>>> 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/authconfig --disablekrb5 >>>> --disablesssd --update --disablemkhomedir --disableldap >> --disablesssdauth >>>> 2015-03-25T12:29:59Z DEBUG stdout= >>>> 2015-03-25T12:29:59Z DEBUG stderr= >>>> 2015-03-25T12:29:59Z DEBUG Error while moving /etc/sssd/sssd.conf to >>>> /etc/sssd/sssd.conf.deleted >>>> 2015-03-25T12:29:59Z INFO Redundant SSSD configuration file >>>> /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/service sssd stop >>>> 2015-03-25T12:29:59Z DEBUG stdout= >>>> 2015-03-25T12:29:59Z DEBUG stderr= >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig sssd off >>>> 2015-03-25T12:29:59Z DEBUG stdout= >>>> 2015-03-25T12:29:59Z DEBUG stderr= >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/service nscd status >>>> 2015-03-25T12:29:59Z DEBUG stdout= >>>> 2015-03-25T12:29:59Z DEBUG stderr=nscd: unrecognized service >>>> >>>> 2015-03-25T12:29:59Z INFO nscd daemon is not installed, skip >> configuration >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/service nslcd status >>>> 2015-03-25T12:29:59Z DEBUG stdout= >>>> 2015-03-25T12:29:59Z DEBUG stderr=nslcd: unrecognized service >>>> >>>> 2015-03-25T12:29:59Z INFO nslcd daemon is not installed, skip >> configuration >>>> 2015-03-25T12:29:59Z INFO Client uninstall complete. >>>> >>>> >>>> >>>> >>>> >>>> *Best Regards,__________________________________________* >>>> >>>> *Yogesh Sharma* >>>> *Email: yks0000 at gmail.com | Web: www.initd.in >>>> * >>>> >>>> RHCE, VCE-CIA, RackSpace Cloud U >>>> [image: My LinkedIn Profile] >>>> >>>> >>>> On Wed, Mar 25, 2015 at 6:10 PM, Martin Kosek >> wrote: >>>> >>>>> On 03/25/2015 07:46 AM, Yogesh Sharma wrote: >>>>>> Hi, >>>>>> >>>>>> We are getting below error while we are installing IPA Server >>>>>> (ipa-server-install --no-ntp). >>>>>> >>>>>> >>>>>> ** >>>>>> *Configuration of client side components failed!* >>>>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >>>>>> --on-master --unattended --domain sd.int --server >>>>>> ldap-inf-stg-sg1-01.sd.int >> --realm >>>>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>>>> ' returned non-zero exit status 1* >>>>>> >>>>>> **Logs indicate below errors: >>>>>> >>>>>> *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h >>>>>> ldap-inf-stg-sg1-01.sd.int -ZZ -x >>>>> -D >>>>>> cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T >> /var/lib/ipa/tmp0iYpzn >>>>>> uid=admin,cn=users,cn=accounts,dc=sd,dc=int* >>>>>> *2015-03-25T06:39:59Z DEBUG stdout=* >>>>>> *2015-03-25T06:39:59Z DEBUG stderr=* >>>>>> *2015-03-25T06:39:59Z DEBUG ldappasswd done* >>>>>> *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install >>>>> --on-master >>>>>> --unattended --domain sd.int --server >>>>>> ldap-inf-stg-sg1-01.sd.int >> --realm >>>>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>>>> * >>>>>> *2015-03-25T06:40:10Z DEBUG stdout=* >>>>>> *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that >>>>>> ldap-inf-stg-sg1-01.sd.int 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.* >>>>>> *Unconfigured automount client failed: Command 'ipa-client-automount >>>>>> --uninstall --debug' returned non-zero exit status 1* >>>>>> *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* >>>>>> *nscd daemon is not installed, skip configuration* >>>>>> *nslcd daemon is not installed, skip configuration* >>>>>> *Client uninstall complete.* >>>>>> >>>>>> *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* >>>>>> * sys.exit("Configuration of client side components >>>>>> failed!\nipa-client-install returned: " + str(e))* >>>>>> >>>>>> *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, >>>>>> exception: SystemExit: Configuration of client side components >> failed!* >>>>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install >>>>>> --on-master --unattended --domain sd.int --server >>>>>> ldap-inf-stg-sg1-01.sd.int >> --realm >>>>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int >>>>>> ' returned non-zero exit status 1* >>>>>> >>>>>> ** >>>>>> >>>>>> >>>>>> This server is on AWS and I can confirm that all above ports are >> opened. >>>>>> Also as it is installing on same server where IPA Server is being >>>>>> installed, Port should not be an issue. >>>>>> >>>>>> Am I missing anything here. >>>>> >>>>> Please also share ipaclient-install.log, it should show what is the >> exact >>>>> problem in the client component installation. >>>>> >>>>> >>>> >>> >> >> > From yks0000 at gmail.com Wed Mar 25 13:43:53 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Wed, 25 Mar 2015 19:13:53 +0530 Subject: [Freeipa-users] Configuration of client side components failed! on IPA Server In-Reply-To: <5512BA12.9020008@redhat.com> References: <5512ACCC.9000608@redhat.com> <5512B480.7030508@redhat.com> <5512BA12.9020008@redhat.com> Message-ID: Thanks Martin for the help. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Wed, Mar 25, 2015 at 7:07 PM, Martin Kosek wrote: > This should be in the official RHEL-7.1/CentOS-7.1 repos. > > Or you can try our upstream CentOS-7 based Copr repo: > > https://copr.fedoraproject.org/coprs/mkosek/freeipa/ > > On 03/25/2015 02:30 PM, Yogesh Sharma wrote: > > Hi Martin, > > > > Finally, the issue has resolved. :) > > > > Is there RPM available to install latest IPA version in CentOS or at > least > > 4.0.2 version. > > > > > > > > > > *Best Regards,__________________________________________* > > > > *Yogesh Sharma* > > *Email: yks0000 at gmail.com | Web: www.initd.in > > * > > > > RHCE, VCE-CIA, RackSpace Cloud U > > [image: My LinkedIn Profile] > > > > > > On Wed, Mar 25, 2015 at 6:43 PM, Martin Kosek wrote: > > > >> Ah, may be. This is an issue we fixed in FreeIPA 4.0.2. Upstream ticket: > >> > >> https://fedorahosted.org/freeipa/ticket/4444 > >> > >> Please let us know if the DNS update fixed the error. > >> > >> Martin > >> > >> On 03/25/2015 02:11 PM, Yogesh Sharma wrote: > >>> I think I got the issue. Realm Name Entry in DNS is added in lower case > >>> rather than UPPER. > >>> > >>> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT > >>> ,cn=kerberos,dc=sd,dc=int > >>> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; > >> server=None, > >>> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > >>> > >>> Will try changing the Realm and see if it resovled. > >>> > >>> > >>> > >>> > >>> *Best Regards,__________________________________________* > >>> > >>> *Yogesh Sharma* > >>> *Email: yks0000 at gmail.com | Web: www.initd.in > >>> * > >>> > >>> RHCE, VCE-CIA, RackSpace Cloud U > >>> [image: My LinkedIn Profile] > >>> > >>> > >>> On Wed, Mar 25, 2015 at 6:13 PM, Yogesh Sharma > >> wrote: > >>> > >>>> Hi Martin, > >>>> > >>>> Please find the client logs: > >>>> > >>>> > >>>> > >>>> 2015-03-25T12:29:49Z DEBUG /usr/sbin/ipa-client-install was invoked > with > >>>> options: {'domain': 'sd.int', 'force': False, > 'krb5_offline_passwords': > >>>> True, 'primary': False, 'mkhomedir': False, 'create_sshfp': True, > >>>> 'conf_sshd': True, 'conf_ntp': True, 'on_master': True, 'ntp_server': > >> None, > >>>> 'server': ['ldap-inf-stg-sg1-01.sd.int'], 'no_nisdomain': False, > >>>> 'principal': None, 'hostname': 'ldap-inf-stg-sg1-01.sd.int', 'no_ac': > >>>> False, 'unattended': True, 'sssd': True, 'trust_sshfp': False, > >>>> 'realm_name': 'SD.INT', 'dns_updates': False, 'conf_sudo': True, > >>>> 'conf_ssh': True, 'force_join': False, 'ca_cert_file': None, > >> 'nisdomain': > >>>> None, 'prompt_password': False, 'permit': False, 'debug': False, > >>>> 'preserve_sssd': False, 'uninstall': False} > >>>> 2015-03-25T12:29:49Z DEBUG missing options might be asked for > >>>> interactively later > >>>> 2015-03-25T12:29:49Z DEBUG Loading Index file from > >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' > >>>> 2015-03-25T12:29:49Z DEBUG Loading StateFile from > >>>> '/var/lib/ipa-client/sysrestore/sysrestore.state' > >>>> 2015-03-25T12:29:49Z DEBUG [IPA Discovery] > >>>> 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, > >>>> servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= > >>>> ldap-inf-stg-sg1-01.sd.int > >>>> 2015-03-25T12:29:49Z DEBUG Server and domain forced > >>>> 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] > >>>> 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _ > >> kerberos.sd.int. > >>>> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ > >>>> kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} > >>>> 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ > >>>> udp.sd.int. > >>>> 2015-03-25T12:29:49Z DEBUG DNS record found: > DNSResult::name:_kerberos._ > >>>> udp.sd.int > >> .,type:33,class:1,rdata={priority:0,port:88,weight:100,server: > >>>> ldap-inf-stg-sg1-01.sd.int.} > >>>> 2015-03-25T12:29:49Z DEBUG [LDAP server check] > >>>> 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int > >>>> (realm sd.int) is an IPA server > >>>> 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// > >>>> ldap-inf-stg-sg1-01.sd.int:389 > >>>> 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN > >>>> 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is > for > >>>> IPA > >>>> 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid > IPA > >>>> context > >>>> 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) > in > >>>> dc=sd,dc=int (sub) > >>>> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int > >>>> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; > >> server=None, > >>>> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > >>>> 2015-03-25T12:29:49Z DEBUG Validated servers: > >>>> 2015-03-25T12:29:49Z DEBUG will use discovered domain: sd.int > >>>> 2015-03-25T12:29:49Z DEBUG IPA Server not found > >>>> 2015-03-25T12:29:49Z DEBUG [IPA Discovery] > >>>> 2015-03-25T12:29:49Z DEBUG Starting IPA discovery with domain=sd.int, > >>>> servers=['ldap-inf-stg-sg1-01.sd.int'], hostname= > >>>> ldap-inf-stg-sg1-01.sd.int > >>>> 2015-03-25T12:29:49Z DEBUG Server and domain forced > >>>> 2015-03-25T12:29:49Z DEBUG [Kerberos realm search] > >>>> 2015-03-25T12:29:49Z DEBUG Search DNS for TXT record of _ > >> kerberos.sd.int. > >>>> 2015-03-25T12:29:49Z DEBUG DNS record found: DNSResult::name:_ > >>>> kerberos.sd.int.,type:16,class:1,rdata={data:sd.int} > >>>> 2015-03-25T12:29:49Z DEBUG Search DNS for SRV record of _kerberos._ > >>>> udp.sd.int. > >>>> 2015-03-25T12:29:49Z DEBUG DNS record found: > DNSResult::name:_kerberos._ > >>>> udp.sd.int > >> .,type:33,class:1,rdata={priority:0,port:88,weight:100,server: > >>>> ldap-inf-stg-sg1-01.sd.int.} > >>>> 2015-03-25T12:29:49Z DEBUG [LDAP server check] > >>>> 2015-03-25T12:29:49Z DEBUG Verifying that ldap-inf-stg-sg1-01.sd.int > >>>> (realm sd.int) is an IPA server > >>>> 2015-03-25T12:29:49Z DEBUG Init LDAP connection with: ldap:// > >>>> ldap-inf-stg-sg1-01.sd.int:389 > >>>> 2015-03-25T12:29:49Z DEBUG Search LDAP server for IPA base DN > >>>> 2015-03-25T12:29:49Z DEBUG Check if naming context 'dc=sd,dc=int' is > for > >>>> IPA > >>>> 2015-03-25T12:29:49Z DEBUG Naming context 'dc=sd,dc=int' is a valid > IPA > >>>> context > >>>> 2015-03-25T12:29:49Z DEBUG Search for (objectClass=krbRealmContainer) > in > >>>> dc=sd,dc=int (sub) > >>>> 2015-03-25T12:29:49Z DEBUG Found: cn=SD.INT,cn=kerberos,dc=sd,dc=int > >>>> 2015-03-25T12:29:49Z DEBUG Discovery result: REALM_NOT_FOUND; > >> server=None, > >>>> domain=sd.int, kdc=ldap-inf-stg-sg1-01.sd.int, basedn=dc=sd,dc=int > >>>> 2015-03-25T12:29:49Z DEBUG Validated servers: > >>>> 2015-03-25T12:29:49Z ERROR Failed to verify that > >>>> ldap-inf-stg-sg1-01.sd.int is an IPA Server. > >>>> 2015-03-25T12:29:49Z ERROR This may mean that the remote server is not > >> up > >>>> or is not reachable due to network or firewall settings. > >>>> 2015-03-25T12:29:49Z INFO Please make sure the following ports are > >> opened > >>>> in the firewall settings: > >>>> TCP: 80, 88, 389 > >>>> UDP: 88 (at least one of TCP/UDP ports 88 has to be open) > >>>> Also note that following ports are necessary for ipa-client working > >>>> properly after enrollment: > >>>> TCP: 464 > >>>> UDP: 464, 123 (if NTP enabled) > >>>> 2015-03-25T12:29:49Z DEBUG (ldap-inf-stg-sg1-01.sd.int: Provided as > >>>> option) > >>>> 2015-03-25T12:29:49Z ERROR Installation failed. Rolling back changes. > >>>> 2015-03-25T12:29:49Z DEBUG Loading Index file from > >>>> '/var/lib/ipa/sysrestore/sysrestore.index' > >>>> 2015-03-25T12:29:49Z DEBUG args=ipa-client-automount --uninstall > --debug > >>>> 2015-03-25T12:29:49Z DEBUG stdout= > >>>> 2015-03-25T12:29:49Z DEBUG stderr=IPA client is not configured on this > >>>> system. > >>>> > >>>> > >>>> 2015-03-25T12:29:49Z ERROR Unconfigured automount client failed: > Command > >>>> 'ipa-client-automount --uninstall --debug' returned non-zero exit > >> status 1 > >>>> 2015-03-25T12:29:49Z DEBUG Loading Index file from > >>>> '/var/lib/ipa-client/sysrestore/sysrestore.index' > >>>> 2015-03-25T12:29:49Z DEBUG Loading StateFile from > >>>> '/var/lib/ipa-client/sysrestore/sysrestore.state' > >>>> 2015-03-25T12:29:49Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb > >> -n > >>>> IPA CA > >>>> 2015-03-25T12:29:49Z DEBUG stdout= > >>>> 2015-03-25T12:29:49Z DEBUG stderr=certutil: Could not find cert: IPA > CA > >>>> : PR_FILE_NOT_FOUND_ERROR: File not found > >>>> > >>>> 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus start > >>>> 2015-03-25T12:29:49Z DEBUG stdout=Starting system message bus: > >>>> > >>>> 2015-03-25T12:29:49Z DEBUG stderr= > >>>> 2015-03-25T12:29:49Z DEBUG args=/sbin/service messagebus status > >>>> 2015-03-25T12:29:49Z DEBUG stdout=messagebus (pid 1151) is running... > >>>> > >>>> 2015-03-25T12:29:49Z DEBUG stderr= > >>>> 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger start > >>>> 2015-03-25T12:29:49Z DEBUG stdout= > >>>> 2015-03-25T12:29:49Z DEBUG stderr= > >>>> 2015-03-25T12:29:49Z DEBUG args=/sbin/service certmonger status > >>>> 2015-03-25T12:29:49Z DEBUG stdout=certmonger (pid 13244) is > running... > >>>> > >>>> 2015-03-25T12:29:49Z DEBUG stderr= > >>>> 2015-03-25T12:29:57Z DEBUG args=/usr/bin/certutil -L -d /etc/pki/nssdb > >> -n > >>>> IPA Machine Certificate - ldap-inf-stg-sg1-01.sd.int > >>>> 2015-03-25T12:29:57Z DEBUG stdout= > >>>> 2015-03-25T12:29:57Z DEBUG stderr=certutil: Could not find cert: IPA > >>>> Machine Certificate - ldap-inf-stg-sg1-01.sd.int > >>>> : PR_FILE_NOT_FOUND_ERROR: File not found > >>>> > >>>> 2015-03-25T12:29:57Z DEBUG args=/sbin/service certmonger stop > >>>> 2015-03-25T12:29:57Z DEBUG stdout=Stopping certmonger: [ OK ] > >>>> > >>>> 2015-03-25T12:29:57Z DEBUG stderr= > >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig certmonger off > >>>> 2015-03-25T12:29:59Z DEBUG stdout= > >>>> 2015-03-25T12:29:59Z DEBUG stderr= > >>>> 2015-03-25T12:29:59Z INFO Removing Kerberos service principals from > >>>> /etc/krb5.keytab > >>>> 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/ipa-rmkeytab -k > >> /etc/krb5.keytab > >>>> -r SD.INT > >>>> 2015-03-25T12:29:59Z DEBUG stdout= > >>>> 2015-03-25T12:29:59Z DEBUG stderr=Removing principal host/ > >>>> ldap-inf-stg-sg1-01.sd.int at SD.INT > >>>> > >>>> 2015-03-25T12:29:59Z INFO Disabling client Kerberos and LDAP > >> configurations > >>>> 2015-03-25T12:29:59Z DEBUG args=/usr/sbin/authconfig --disablekrb5 > >>>> --disablesssd --update --disablemkhomedir --disableldap > >> --disablesssdauth > >>>> 2015-03-25T12:29:59Z DEBUG stdout= > >>>> 2015-03-25T12:29:59Z DEBUG stderr= > >>>> 2015-03-25T12:29:59Z DEBUG Error while moving /etc/sssd/sssd.conf to > >>>> /etc/sssd/sssd.conf.deleted > >>>> 2015-03-25T12:29:59Z INFO Redundant SSSD configuration file > >>>> /etc/sssd/sssd.conf was moved to /etc/sssd/sssd.conf.deleted > >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/service sssd stop > >>>> 2015-03-25T12:29:59Z DEBUG stdout= > >>>> 2015-03-25T12:29:59Z DEBUG stderr= > >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/chkconfig sssd off > >>>> 2015-03-25T12:29:59Z DEBUG stdout= > >>>> 2015-03-25T12:29:59Z DEBUG stderr= > >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/service nscd status > >>>> 2015-03-25T12:29:59Z DEBUG stdout= > >>>> 2015-03-25T12:29:59Z DEBUG stderr=nscd: unrecognized service > >>>> > >>>> 2015-03-25T12:29:59Z INFO nscd daemon is not installed, skip > >> configuration > >>>> 2015-03-25T12:29:59Z DEBUG args=/sbin/service nslcd status > >>>> 2015-03-25T12:29:59Z DEBUG stdout= > >>>> 2015-03-25T12:29:59Z DEBUG stderr=nslcd: unrecognized service > >>>> > >>>> 2015-03-25T12:29:59Z INFO nslcd daemon is not installed, skip > >> configuration > >>>> 2015-03-25T12:29:59Z INFO Client uninstall complete. > >>>> > >>>> > >>>> > >>>> > >>>> > >>>> *Best Regards,__________________________________________* > >>>> > >>>> *Yogesh Sharma* > >>>> *Email: yks0000 at gmail.com | Web: www.initd.in > >>>> * > >>>> > >>>> RHCE, VCE-CIA, RackSpace Cloud U > >>>> [image: My LinkedIn Profile] > >>>> > >>>> > >>>> On Wed, Mar 25, 2015 at 6:10 PM, Martin Kosek > >> wrote: > >>>> > >>>>> On 03/25/2015 07:46 AM, Yogesh Sharma wrote: > >>>>>> Hi, > >>>>>> > >>>>>> We are getting below error while we are installing IPA Server > >>>>>> (ipa-server-install --no-ntp). > >>>>>> > >>>>>> > >>>>>> ** > >>>>>> *Configuration of client side components failed!* > >>>>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > >>>>>> --on-master --unattended --domain sd.int --server > >>>>>> ldap-inf-stg-sg1-01.sd.int > >> --realm > >>>>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > >>>>>> ' returned non-zero exit status > 1* > >>>>>> > >>>>>> **Logs indicate below errors: > >>>>>> > >>>>>> *2015-03-25T06:39:59Z DEBUG args=/usr/bin/ldappasswd -h > >>>>>> ldap-inf-stg-sg1-01.sd.int -ZZ > -x > >>>>> -D > >>>>>> cn=Directory Manager -y /var/lib/ipa/tmpiI0qCS -T > >> /var/lib/ipa/tmp0iYpzn > >>>>>> uid=admin,cn=users,cn=accounts,dc=sd,dc=int* > >>>>>> *2015-03-25T06:39:59Z DEBUG stdout=* > >>>>>> *2015-03-25T06:39:59Z DEBUG stderr=* > >>>>>> *2015-03-25T06:39:59Z DEBUG ldappasswd done* > >>>>>> *2015-03-25T06:40:10Z DEBUG args=/usr/sbin/ipa-client-install > >>>>> --on-master > >>>>>> --unattended --domain sd.int --server > >>>>>> ldap-inf-stg-sg1-01.sd.int > >> --realm > >>>>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > >>>>>> * > >>>>>> *2015-03-25T06:40:10Z DEBUG stdout=* > >>>>>> *2015-03-25T06:40:10Z DEBUG stderr=Failed to verify that > >>>>>> ldap-inf-stg-sg1-01.sd.int 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.* > >>>>>> *Unconfigured automount client failed: Command 'ipa-client-automount > >>>>>> --uninstall --debug' returned non-zero exit status 1* > >>>>>> *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* > >>>>>> *nscd daemon is not installed, skip configuration* > >>>>>> *nslcd daemon is not installed, skip configuration* > >>>>>> *Client uninstall complete.* > >>>>>> > >>>>>> *2015-03-25T06:40:10Z 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-server-install", line 1103, in main* > >>>>>> * sys.exit("Configuration of client side components > >>>>>> failed!\nipa-client-install returned: " + str(e))* > >>>>>> > >>>>>> *2015-03-25T06:40:10Z INFO The ipa-server-install command failed, > >>>>>> exception: SystemExit: Configuration of client side components > >> failed!* > >>>>>> *ipa-client-install returned: Command '/usr/sbin/ipa-client-install > >>>>>> --on-master --unattended --domain sd.int --server > >>>>>> ldap-inf-stg-sg1-01.sd.int > >> --realm > >>>>>> SD.INT --hostname ldap-inf-stg-sg1-01.sd.int > >>>>>> ' returned non-zero exit status > 1* > >>>>>> > >>>>>> ** > >>>>>> > >>>>>> > >>>>>> This server is on AWS and I can confirm that all above ports are > >> opened. > >>>>>> Also as it is installing on same server where IPA Server is being > >>>>>> installed, Port should not be an issue. > >>>>>> > >>>>>> Am I missing anything here. > >>>>> > >>>>> Please also share ipaclient-install.log, it should show what is the > >> exact > >>>>> problem in the client component installation. > >>>>> > >>>>> > >>>> > >>> > >> > >> > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From guertin at middlebury.edu Wed Mar 25 14:46:33 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Wed, 25 Mar 2015 14:46:33 +0000 Subject: [Freeipa-users] Clients are reading AD info inconsistently References: <5511E49A.2050101@redhat.com> Message-ID: <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> Follow-up: today I tried clearing the sssd cache and restarting sssd on all three clients, and all three lost their AD users: # rm -f /var/lib/sss/db/* # service sssd restart Stopping sssd: [ OK ] Starting sssd: [ OK ] # id 'MIDD\juser' id: MIDD\juser: No such user David Guertin From jpazdziora at redhat.com Wed Mar 25 15:30:50 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Wed, 25 Mar 2015 16:30:50 +0100 Subject: [Freeipa-users] Fedora 20 upstream repo ipa-server-install fails In-Reply-To: <5512ADF5.3040708@redhat.com> References: <20150324165822.GA17848@redhat.com> <5512AC34.1050602@redhat.com> <5512ADF5.3040708@redhat.com> Message-ID: <20150325153050.GD17619@redhat.com> On Wed, Mar 25, 2015 at 01:45:41PM +0100, Petr Spacek wrote: > > On 25.3.2015 13:38, Martin Kosek wrote: > > Good ones. Also Ccing PetrS and MartinB, who were directly involved in these > > features and original thread, for reference > > In meanwhile I have fixed this. As usual, new OpenSSL package in F20 prevented > installation of our custom build OpenSSL from COPR repo. > > It should work now, please upgrade your openssl to get this package from COPR: > http://copr.fedoraproject.org/coprs/mkosek/freeipa/build/83148/ I confirm that my containers with Fedora 20 upstream IPA now work. Thank you for the prompt fix! -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From simo at redhat.com Wed Mar 25 15:44:41 2015 From: simo at redhat.com (Simo Sorce) Date: Wed, 25 Mar 2015 11:44:41 -0400 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> Message-ID: <1427298281.8302.62.camel@willson.usersys.redhat.com> On Wed, 2015-03-25 at 14:46 +0000, Guertin, David S. wrote: > Follow-up: today I tried clearing the sssd cache and restarting sssd on all three clients, and all three lost their AD users: > > # rm -f /var/lib/sss/db/* > # service sssd restart > Stopping sssd: [ OK ] > Starting sssd: [ OK ] > # id 'MIDD\juser' > id: MIDD\juser: No such user > > David Guertin > This is normal, users are "loaded in" when they actually try to Log In. Simo. -- Simo Sorce * Red Hat, Inc * New York From edewata at redhat.com Wed Mar 25 16:00:49 2015 From: edewata at redhat.com (Endi Sukma Dewata) Date: Wed, 25 Mar 2015 11:00:49 -0500 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: References: <550FF3E7.2090106@redhat.com> <55101409.5000505@redhat.com> <5510660C.5020709@redhat.com> <107823642.2856345.1427143008792.JavaMail.zimbra@redhat.com> Message-ID: <5512DBB1.7070104@redhat.com> Hi Michael, It took longer than expected, but I finally managed to create the build: https://edewata.fedorapeople.org/files/pki-common-9.0.3-39.el6_6.noarch.rpm Please install it and retry the operation. I have not tried this myself, but it should generate more useful information. Please let me know the exception that you see in /var/log/pki-ca/debug. Thanks. -- Endi S. Dewata On 3/24/2015 7:21 PM, Michael Pawlak wrote: > Endi, > > Any word on the build? > > *Michael Pawlak* > Web Systems Administrator | Colovore LLC > E: mike at colovore.com > C: 408.316.2154 > > > On Mon, Mar 23, 2015 at 2:55 PM, Michael Pawlak > wrote: > > Endi, > > I could test that. > > *Michael Pawlak* > Web Systems Administrator | Colovore LLC > E: mike at colovore.com > C: 408.316.2154 > > > On Mon, Mar 23, 2015 at 1:36 PM, Endi Sukma Dewata > > wrote: > > Thanks for the info. The transaction log doesn't indicate the > cause of the problem either. I might need to provide a custom > build that generates more useful information. Would you be able > to test that? Thanks. > > -- > Endi S. Dewata > > ----- Original Message ----- > > Endi, > > > > 1. I am currently using CentOS 6.5. > > > > 2. Below are the package versions. > > > > Former: > > Don't have that information available > > > > Current: > > pki-java-tools-9.0.3-38.el6_6.noarch > > pki-silent-9.0.3-38.el6_6.noarch > > ipa-pki-common-theme-9.0.3-7.el6.noarch > > pki-ca-9.0.3-38.el6_6.noarch > > pki-setup-9.0.3-38.el6_6.noarch > > pki-native-tools-9.0.3-38.el6_6.x86_64 > > pki-util-9.0.3-38.el6_6.noarch > > pki-selinux-9.0.3-38.el6_6.noarch > > pki-common-9.0.3-38.el6_6.noarch > > ipa-pki-ca-theme-9.0.3-7.el6.noarch > > pki-symkey-9.0.3-38.el6_6.x86_64 > > > > 3. Attached > > > > *Michael Pawlak* > > Web Systems Administrator | Colovore LLC > > E: mike at colovore.com > > C: 408.316.2154 > > > > > > On Mon, Mar 23, 2015 at 12:14 PM, Endi Sukma Dewata > > > > wrote: > > > > > > Hi, > > > > > > Unfortunately the code doesn't log the exact cause of the > problem. I need > > > some additional info: > > > > > > 1. Which platform are you using? > > > 2. What are the versions of the pki-* packages before and > after upgrade? > > > 3. Please provide the /etc/pki-ca/CS.cfg and > /var/log/pki-ca/transactions. > > > > > > Thanks. > > > > > > -- > > > Endi S. Dewata > > > From coy.hile at coyhile.com Wed Mar 25 16:22:05 2015 From: coy.hile at coyhile.com (Coy Hile) Date: Wed, 25 Mar 2015 16:22:05 +0000 Subject: [Freeipa-users] Is systemd really a requirement for freeipa 4.x? Message-ID: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> When I look at the SPEC file for freeipa-4.1.3, I see requirements around Systemd. Is that really a hard requirement, or is it possible to run newer FreeIPA (that is to say 4.x) on a host that hasn't been infested by systemd (such as CentOS 6, for example)? At the moment, I'm speaking completely of the server components. thanks, -c -- Coy Hile coy.hile at coyhile.com From rcritten at redhat.com Wed Mar 25 17:41:08 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Mar 2015 13:41:08 -0400 Subject: [Freeipa-users] Is systemd really a requirement for freeipa 4.x? In-Reply-To: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> References: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> Message-ID: <5512F334.5050000@redhat.com> Coy Hile wrote: > When I look at the SPEC file for freeipa-4.1.3, I see requirements > around Systemd. Is that really a hard requirement, or is it possible to > run newer FreeIPA (that is to say 4.x) on a host that hasn't been > infested by systemd (such as CentOS 6, for example)? At the moment, I'm > speaking completely of the server components. There are a slew of major dependencies that prevent IPA 4.x from working in RHEL/CentOS 6. It would be quite non-trivial to try to backport everything needed. rob From anthony at advertise.com Wed Mar 25 17:59:34 2015 From: anthony at advertise.com (Anthony Lanni) Date: Wed, 25 Mar 2015 10:59:34 -0700 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: <5512AB72.6090201@redhat.com> References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> Message-ID: keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I reinstalled keyutils and then ran the ipa-server-install again, and this time it completed without error. Thanks very much, Martin and Dmitri! thx anthony On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek wrote: > On 03/25/2015 04:11 AM, Dmitri Pal wrote: > > On 03/24/2015 09:17 PM, Anthony Lanni wrote: > >> While running ipa-server-install, it's failing out at the end with an > error > >> regarding the client install on the server. This happens regardless of > how I > >> input the options, but here's the latest command: > >> > >> ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM > >> -n example.com -p passwd1 -a > >> passwd2 --hostname=ldap-server-01.example.com > >> --forwarder=10.0.1.20 > >> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d > >> > >> Runs through the entire setup and gives me this: > >> > >> [...] > >> ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master > >> --unattended --domain example.com --server > >> ldap-server-01.example.com --realm > >> EXAMPLE.COM --hostname ldap-server-01.example.com > >> > >> ipa : DEBUG stdout= > >> > >> ipa : DEBUG stderr=Hostname: ldap-server-01.example.com > >> > >> Realm: EXAMPLE.COM > >> DNS Domain: example.com > >> IPA Server: ldap-server-01.example.com < > http://ldap-server-01.example.com> > >> BaseDN: dc=example,dc=com > >> New SSSD config will be created > >> Configured /etc/sssd/sssd.conf > >> Traceback (most recent call last): > >> File "/usr/sbin/ipa-client-install", line 2377, in > >> sys.exit(main()) > >> File "/usr/sbin/ipa-client-install", line 2363, in main > >> rval = install(options, env, fstore, statestore) > >> File "/usr/sbin/ipa-client-install", line 2135, in install > >> delete_persistent_client_session_data(host_principal) > >> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in > >> delete_persistent_client_session_data > >> kernel_keyring.del_key(keyname) > >> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > line > >> 99, in del_key > >> real_key = get_real_key(key) > >> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > line > >> 45, in get_real_key > >> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, > key], > >> raiseonerr=False) > > > > Is keyctl installed? Can you run it manually? > > Any SELinux denials? > > You are likely hitting > https://fedorahosted.org/freeipa/ticket/3808 > > Please try installing keyutils before running ipa-server-install. It is > fixed > in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: > https://bugzilla.redhat.com/show_bug.cgi?id=1205660 > > 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 mike at colovore.com Wed Mar 25 18:11:44 2015 From: mike at colovore.com (Michael Pawlak) Date: Wed, 25 Mar 2015 11:11:44 -0700 Subject: [Freeipa-users] Having Issues with Dogtag After Updating IPA and Rebooting In-Reply-To: <5512DBB1.7070104@redhat.com> References: <550FF3E7.2090106@redhat.com> <55101409.5000505@redhat.com> <5510660C.5020709@redhat.com> <107823642.2856345.1427143008792.JavaMail.zimbra@redhat.com> <5512DBB1.7070104@redhat.com> Message-ID: Endi, Due to time constraints, we turned up another IPA server, migrated all DNS and users and turned down this host. So, I think at this point installing the package would be moot. Thanks for your help anyways. *Michael Pawlak* Web Systems Administrator | Colovore LLC E: mike at colovore.com C: 408.316.2154 On Wed, Mar 25, 2015 at 9:00 AM, Endi Sukma Dewata wrote: > Hi Michael, > > It took longer than expected, but I finally managed to create the build: > > https://edewata.fedorapeople.org/files/pki-common-9.0.3-39. > el6_6.noarch.rpm > > Please install it and retry the operation. I have not tried this myself, > but it should generate more useful information. > > Please let me know the exception that you see in /var/log/pki-ca/debug. > Thanks. > > -- > Endi S. Dewata > > On 3/24/2015 7:21 PM, Michael Pawlak wrote: > >> Endi, >> >> Any word on the build? >> >> *Michael Pawlak* >> Web Systems Administrator | Colovore LLC >> E: mike at colovore.com >> C: 408.316.2154 >> >> >> On Mon, Mar 23, 2015 at 2:55 PM, Michael Pawlak > > wrote: >> >> Endi, >> >> I could test that. >> >> *Michael Pawlak* >> Web Systems Administrator | Colovore LLC >> E: mike at colovore.com >> C: 408.316.2154 >> >> >> On Mon, Mar 23, 2015 at 1:36 PM, Endi Sukma Dewata >> > wrote: >> >> Thanks for the info. The transaction log doesn't indicate the >> cause of the problem either. I might need to provide a custom >> build that generates more useful information. Would you be able >> to test that? Thanks. >> >> -- >> Endi S. Dewata >> >> ----- Original Message ----- >> > Endi, >> > >> > 1. I am currently using CentOS 6.5. >> > >> > 2. Below are the package versions. >> > >> > Former: >> > Don't have that information available >> > >> > Current: >> > pki-java-tools-9.0.3-38.el6_6.noarch >> > pki-silent-9.0.3-38.el6_6.noarch >> > ipa-pki-common-theme-9.0.3-7.el6.noarch >> > pki-ca-9.0.3-38.el6_6.noarch >> > pki-setup-9.0.3-38.el6_6.noarch >> > pki-native-tools-9.0.3-38.el6_6.x86_64 >> > pki-util-9.0.3-38.el6_6.noarch >> > pki-selinux-9.0.3-38.el6_6.noarch >> > pki-common-9.0.3-38.el6_6.noarch >> > ipa-pki-ca-theme-9.0.3-7.el6.noarch >> > pki-symkey-9.0.3-38.el6_6.x86_64 >> > >> > 3. Attached >> > >> > *Michael Pawlak* >> > Web Systems Administrator | Colovore LLC >> > E: mike at colovore.com >> > C: 408.316.2154 >> > >> > >> > On Mon, Mar 23, 2015 at 12:14 PM, Endi Sukma Dewata >> > >> > wrote: >> > > >> > > Hi, >> > > >> > > Unfortunately the code doesn't log the exact cause of the >> problem. I need >> > > some additional info: >> > > >> > > 1. Which platform are you using? >> > > 2. What are the versions of the pki-* packages before and >> after upgrade? >> > > 3. Please provide the /etc/pki-ca/CS.cfg and >> /var/log/pki-ca/transactions. >> > > >> > > Thanks. >> > > >> > > -- >> > > Endi S. Dewata >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bobby.prins at proxy.nl Wed Mar 25 20:20:10 2015 From: bobby.prins at proxy.nl (Bobby Prins) Date: Wed, 25 Mar 2015 21:20:10 +0100 Subject: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode In-Reply-To: <55118CA8.3080507@redhat.com> References: <1233558204.521669.1426778523088.JavaMail.zimbra@proxy.nl> <1465921859.529091.1426851527081.JavaMail.zimbra@proxy.nl> <20150320120500.GO3878@redhat.com> <550C218F.2000907@redhat.com> <659115330.573607.1427125054781.JavaMail.zimbra@proxy.nl> <20150323154447.GR3878@redhat.com> <310050850.588679.1427202097917.JavaMail.zimbra@proxy.nl> <20150324141338.GT3878@redhat.com> <286451019.593771.1427211953268.JavaMail.zimbra@proxy.nl> <55118CA8.3080507@redhat.com> Message-ID: <69137159-8386-47E2-ABB4-A3E415D77582@proxy.nl> > On Mar 24, 2015, at 17:11, Dmitri Pal wrote: > > On 03/24/2015 11:45 AM, Bobby Prins wrote: >>> ----- Oorspronkelijk bericht ----- >>> Van: "Alexander Bokovoy" >>> Aan: "Bobby Prins" >>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>> Verzonden: Dinsdag 24 maart 2015 15:13:38 >>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>> >>> On Tue, 24 Mar 2015, Bobby Prins wrote: >>>>> ----- Oorspronkelijk bericht ----- >>>>> Van: "Alexander Bokovoy" >>>>> Aan: "Bobby Prins" >>>>> Cc: dpal at redhat.com, freeipa-users at redhat.com >>>>> Verzonden: Maandag 23 maart 2015 16:44:47 >>>>> Onderwerp: Re: [Freeipa-users] 'Preauthentication failed' with SSSD in ipa_server_mode >>>>> >>>>> ... >>>>> >>>>> Can you show relevant parts of /var/log/dirsrv/slapd-EXAMPLE-CORP/access >>>>> and sssd logs from IPA master (with debug_level = 10) at least in >>>>> [domain], [nss], and [pam] sections. >>>>> >>>>> You need to filter dirsrv logs by connection coming from AIX IP address >>>>> and then by conn= where number is the same number as the one >>>>> with IP address line. >>>>> >>>>> When authenticating, AIX would talk to IPA LDAP server to compat tree >>>>> and slapi-nis plugin which serves compat tree would do PAM >>>>> authentication as service system-auth where SSSD on IPA master will do >>>>> the actual authentication work. >>>>> >>>>> -- >>>>> / Alexander Bokovoy >>>> Here you can see the DS connection from AIX: >>>> [24/Mar/2015:12:53:19 +0100] conn=96 fd=110 slot=110 connection from 192.168.140.107 to 192.168.140.133 >>>> [24/Mar/2015:12:53:20 +0100] conn=96 op=0 BIND dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" method=128 version=3 >>>> [24/Mar/2015:12:53:43 +0100] conn=96 op=0 RESULT err=0 tag=97 nentries=0 etime=24 dn="uid=bprins at example.corp,cn=users,cn=compat,dc=unix,dc=example,dc=corp" >>>> [24/Mar/2015:12:53:43 +0100] conn=96 op=-1 fd=110 closed - B1 >>>> >>>> As you can see it also takes quite some time to process the login. >>>> Could that be a problem? >>> 24 seconds sounds like bprins2example.com is a member of few groups with >>> big amount of members. On the other hand, BIND operation result is 0 >>> (success) and it doesn't look like AIX dropped the connection, at least >>> there is no ABANDON within the context of this connection so AIX did not >>> cancel the request by itself. >>> >>> How long does it take on AIX side to report the inability to login? Is >>> this time longer or shorter the one reported in etime= value on RESULT >>> line above? >>> >>>> The SSSD log files are a bit large with debug_level set to 10 and it >>>> will take me some time to strip all customer data from it. Any log >>>> events in particular you would like to see? >>> https://fedorahosted.org/sssd/wiki/Troubleshooting has explanation for >>> some times of issues you might find in the SSSD logs. I'd be interested >>> in "Common AD provider issues", "Troubleshooting authentication, >>> password change and access control". >>> >>> -- >>> / Alexander Bokovoy >> The inability to login is reported in about the same time as the number of seconds you would find in the etime= field of the RESULT line. >> >> I checked the "Common AD provider issues" and "Troubleshooting authentication, password change and access control" sections on the SSSD Troubleshooting page. None of the issues reported there seem to be applicable in my situation. >> >> PAM logging on AIX: >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_start(login bprins at example.corp) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(1) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(2) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(5) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(3) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(4) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(8) >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate() >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >> Mar 24 16:23:10 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_authenticate >> Mar 24 16:23:22 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_authenticate: error Authentication failed > > Seems like 15 sec timeout on the AIX side. > Can you try with a user that does not have that many groups and see if that works? > If it does then we should assume it is an AIX side timeout and focus on making sure the data gets over to IPA within this timeout. I need to do some more testing.. Did not have a lot of time today, but I tried to authenticate with an AD user against the compact tree using a Linux client with pam_ldap. I was able to log in but this would take up to a minute or so. I?m still waiting for my AD test account with lesser group memberships. > >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_set_item(6) >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt() >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_modules: /usr/lib/security/pam_aix >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: load_function: successful load of pam_sm_acct_mgmt >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_acct_mgmt: error No account present for user >> Mar 24 16:23:37 tst01 auth|security:debug /usr/sbin/getty PAM: pam_end(): status = Authentication failed >> Mar 24 16:23:37 tst01 auth|security:info syslog: vty0: failed login attempt for UNKNOWN_USER >> >> Doing a ldapsearch with bprins at example.corp as bind user works without any problems. > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > From rcritten at redhat.com Wed Mar 25 21:43:52 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Mar 2015 17:43:52 -0400 Subject: [Freeipa-users] Fw: Need to replace cert for ipa servers In-Reply-To: <1144667114.746796.1427228442473.JavaMail.yahoo@mail.yahoo.com> References: <903DF15B7B9D3B4D9137A06F63687859172CC3185D@FHDP1LUMXC7V33.us.one.verizon.com> <499575904.4226305.1426278747223.JavaMail.yahoo@mail.yahoo.com> <1144667114.746796.1427228442473.JavaMail.yahoo@mail.yahoo.com> Message-ID: <55132C18.8050406@redhat.com> sipazzo wrote: > Ok I finally was able to get a sandbox environment up to test the cert > replacement. When I ran this stepgot to the cert request steps: > ipa-getcert request -d /etc/dirsrv/slapd-IPADOMAIN-COM -n Server-Cert -p > /etc/dirsrv/slapd-IPADOMAIN-COM/pwdfile.txt -C > '/usr/lib64/ipa/certmonger/restart_dirsrv IPADOMAIN-COM' -N > CN=idm2-corp.ipadomain.com -K ldap/ipa2-corp.ipadomain.com at IPADOMAIN.COM > > I got a message saying the cert at same location is already used by > request with nickname "20140729215511" , same when I ran it for > /etc/httpd/alias. I continued on anyway but when I get to this step: You need to tell certmonger to stop tracking the existing GoDaddy certs, not that they would have been renewable anyway. You may also need to remove them from the NSS database(s) using something like: # certutil -D -n 'nickname' -d /path/to/db I think the subject will be different enough that it may be ok as-is. The other errors are due to the fact that no certificate was issued. rob > > # certutil -V -u V -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM > > I get an error: > certutil: could not find certificate named "Server-Cert": > PR_FILE_NOT_FOUND_ERROR: File not found > > Although running certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM/, > returns this: > > Certificate Nickname Trust > Attributes > > SSL,S/MIME,JAR/XPI > > GD_CA CT,C,C > IPADOMAIN.COM IPA CA CT,, > NWF_GD u,u,u > > > Showing that the IPA Dogtag cert is now listed whereas it was not > previously. > > > ------------------------------------------------------------------------ > *From:* sipazzo > *To:* Rob Crittenden ; "freeipa-users at redhat.com" > > *Sent:* Friday, March 13, 2015 1:32 PM > *Subject:* Re: [Freeipa-users] Fw: Need to replace cert for ipa servers > > This environment is over 350 servers, many of which are in production so > I may have to wait a bit for change management approval to attempt to > resolve this issue, particularly if you think it might break something. > I will keep you updated on my progress. Thank you much. > > > > ------------------------------------------------------------------------ > *From:* sipazzo > *To:* Rob Crittenden > *Cc:* "freeipa-users at redhat.com" > *Sent:* Friday, March 13, 2015 9:21 AM > *Subject:* Re: [Freeipa-users] Fw: Need to replace cert for ipa servers > > > > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com > ] On Behalf Of Rob Crittenden > Sent: Thursday, March 12, 2015 1:52 PM > To: sipazzo; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers > > sipazzo wrote: >> I do have other CAs (just not the master but it is available offline >> if >> needed) > > To be clear, all IPA servers are masters, some just run more services > than others. It sounds like you have at least one CA available which > should be sufficient. > >> Directory server is running >> The apache web server is running and I can get to the gui ipa >> cert-show 1 works > > Ok. I guess the place to start is to get certs for Apache and 389-ds, > then we can see about using these new certs. > > In the thread you showed that the IPA 389-ds doesn't have a Server-Cert > nickname. You'll want to do the same for /etc/httpd/alias before running > the following commands otherwise you could end up with non-functional > server. > > These should get IPA certs for 389-ds and Apache. You'll need to edit > these commands to match your environment: > > # ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p > /etc/httpd/alias/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_httpd > -N CN=ipa.example.com -K HTTP/ipa.example.com at EXAMPLE.COM > > > # ipa-getcert request -d /etc/dirsrv/slapd-EXAMPLE-COM -n Server-Cert -p > /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt -C > '/usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM' -N > CN=ipa.example.com -K ldap/ipa.example.com at EXAMPLE.COM > > > I'd do them one at a time and wait until the cert is issued and tracked. > This will restart both Apache and 389-ds but it shouldn't affect > operation because the certs won't be used yet. > > You then need to get the old CA cert and put it into the right places. > Since it is already in the PKI-IPA NSS database let's fetch it from > there. For giggles you should probably save whatever the contents of > /etc/ipa/ca.crt are before-hand. > > # certutil -L -d /etc/dirsrv/slapd-PKI-IPA -n 'IPADOMAIN.COM IPA CA' -a >> /etc/ipa/ca.crt > > Now add that to the Apache and 389-ds databases: > > # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/httpd/alias -t CT,C, -a > -i /etc/ipa/ca.crt # certutil -A -n 'IPADOMAIN.COM IPA CA' -d > /etc/dirsrv/slapd-EXAMPLE-COM -t CT,, -a -i /etc/ipa/ca.crt > > Next add it to /etc/pki/nssdb if it isn't already there: > > # certutil -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i /etc/ipa/ca.crt > > Next, verify that the newly issued certs are trusted: > > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias # certutil -V -u V > -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM > > Both should return: > certutil: certificate is valid > > Next is to configure the services to use the new certs. I'd stop IPA to > do this: ipactl stop > > Edit /etc/httpd/conf.d/nss.conf and change the NSSNickname to Server-Cert > > Edit /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif and set nsSSLPersonalitySSL > to Server-Cert > > Now try to start the world: ipactl start > > Run a few commands: > > # ipa user-show admin > # ipa cert-show 1 > > Both should work. > > Assuming all has gone well to this point, copy /etc/ipa/ca.crt to > /usr/share/ipa/html/ca.crt > > Finally run: ipa-ldap-updater --upgrade > > This should load the new CA certificate into LDAP. > > This has the potential to break a whole bunch of your clients. It is > probably enough to just copy over the new CA cert to the right > location(s) on the clients. The mechanics of this depend on the OS. > >> Are the TLS errors due to the mismatch in certs between slapd-PKI-CA >> and slapd-NETWORKFLEET-COM? > > No, has nothing to do with the CA at all. The client doesn't have (or > trust) the CA that issued the LDAP server cert. > > rob > >> >> >> -----Original Message----- >> >> >> From: freeipa-users-bounces at redhat.com > >> > >> [mailto:freeipa-users-bounces at redhat.com > >> >] On Behalf Of Rob Crittenden >> Sent: Wednesday, March 11, 2015 7:20 PM >> To: sipazzo; freeipa-users at redhat.com >> > >> Subject: Re: [Freeipa-users] Need to replace cert for ipa servers >> >> sipazzo wrote: >>> Thanks Rob, I apologize that error was probably not helpful. This is >>> what I see when running install in debug mode: >>> >>> Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an >>> IPA server Init LDAP connection with: >>> ldap://ipa2-corp.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >>> server Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >>> server Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >>> server Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >>> server Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> >>> The certificates are very confusing to me. I don't understand how >>> things are working when we have a set of GoDaddy certs in >>> slapd-NETWORKFLEET-COM and a set of the Dogtag certs in slapd-PKI-CA. >>> The cert in /usr/share/ipa/html/ca.crt looks like the original one >>> issued by the Dogtag cert system and matches the ones on the clients. >>> Not to further confuse things but the original master server that >>> signed all these certs was taken offline months ago due to some >>> issues it was having. I do still have access to it if necessary. >>> >>> As far as why the godaddy certs were swapped out for the Dogtag certs >>> it was originally for something as simple as the untrusted >>> certificate dialogue when accessing the ipa gui. I did not swap out >>> the certs so am unsure of exactly what happened. There is no real >>> need to use the GoDaddy certs as far as I am concerned. I just want >>> the best solution to the issues I am seeing as I am in kind of a bind >>> with the GoDaddy cert being revoked and needing to be replaced and >>> the master Dogtag certificate server offline. We have a mixed >>> environment with Rhel 5, 6 and Solaris clients so are not using sssd > in all cases. >>> >>> I know this is asking a lot but appreciate any help you can give. >> >> What is the current state of things? Does your IPA Apache server work? >> Is 389-ds up and running? Do you have a working IPA CA? >> >> Does ipa cert-show 1 work? >> >> If the answer is yes to all then we should be able to generate new >> certs for all the services. >> >> 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 >> > > -- > 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 Wed Mar 25 23:55:15 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Mar 2015 19:55:15 -0400 Subject: [Freeipa-users] Is systemd really a requirement for freeipa 4.x? In-Reply-To: <5512F334.5050000@redhat.com> References: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> <5512F334.5050000@redhat.com> Message-ID: <55134AE3.7090209@redhat.com> On 03/25/2015 01:41 PM, Rob Crittenden wrote: > Coy Hile wrote: >> When I look at the SPEC file for freeipa-4.1.3, I see requirements >> around Systemd. Is that really a hard requirement, or is it possible to >> run newer FreeIPA (that is to say 4.x) on a host that hasn't been >> infested by systemd (such as CentOS 6, for example)? At the moment, I'm >> speaking completely of the server components. > There are a slew of major dependencies that prevent IPA 4.x from working > in RHEL/CentOS 6. It would be quite non-trivial to try to backport > everything needed. > > rob > systemd is just one of the next generation technologies we had to deal with but it we had to deal with we took advantage of it. As Rob said 4.x depends on many component that are not portable back to RHEL/CentOS 6. Please consider Fedora 21/RHEL 7.1/CentOS 7.1 if you want to run latest bits. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Mar 26 00:01:36 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Mar 2015 20:01:36 -0400 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <1427298281.8302.62.camel@willson.usersys.redhat.com> References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> <1427298281.8302.62.camel@willson.usersys.redhat.com> Message-ID: <55134C60.3060505@redhat.com> On 03/25/2015 11:44 AM, Simo Sorce wrote: > On Wed, 2015-03-25 at 14:46 +0000, Guertin, David S. wrote: >> Follow-up: today I tried clearing the sssd cache and restarting sssd on all three clients, and all three lost their AD users: >> >> # rm -f /var/lib/sss/db/* >> # service sssd restart >> Stopping sssd: [ OK ] >> Starting sssd: [ OK ] >> # id 'MIDD\juser' >> id: MIDD\juser: No such user >> >> David Guertin >> > This is normal, users are "loaded in" when they actually try to Log In. > > Simo. > Yes. The ability to look up AD users that never authenticated was added in 7.1 and 6.7 (i.e. SSSD 1.12) -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From lundman at lundman.net Thu Mar 26 00:25:28 2015 From: lundman at lundman.net (Jorgen Lundman) Date: Thu, 26 Mar 2015 09:25:28 +0900 Subject: [Freeipa-users] bind-dyndb-ldap vs DLZ In-Reply-To: <55126655.30109@redhat.com> References: <55122F5F.8030505@lundman.net> <55126655.30109@redhat.com> Message-ID: <551351F8.5070508@lundman.net> Thanks for your email, (I have included the ML in this reply) We run Solaris with bind+DLZ+ldap on the DNS servers, and are looking at better performance. Which means evaluating bind-dyndb-ldap. I did some minor tweaks to compile bind-dyndb on Solaris. Since we already have large systems running in production, with provisioning, and support tools, it is unlikely we would change the schema. It would probably be less work for me to fork bind-dyndb and massage it into handling DLZ schema directly. But before that, we are just evaluating bind-dyndb to decide if it fits with our systems. I loaded the 300k zones we have in DLZ-LDAP, into bind-dyndb schema (Just SOA records with a single ARecord). [1] The first issue is that to start named takes about 50 mins. This is a bit of an issue as there is no resolving while it is starting. This seems to be the same delay each time I start it. slapd is running on localhost, and is otherwise idle. It is just a large syncrepl for 300k records, always starting from epoch... [2] Is it supposed to be able to use the "dump-file" on exit for faster loads? Perhaps I broke something while porting it to Solaris. I see it create directories for each zone, only to create an empty "keys" directory. In addition to that, having 300k entries in one directory might need hashing. ZFS is ok with it, but it tends to slow down. However, once it is loaded, it is much faster than DLZ+LDAP. Previous system would see about 300qps. (All zones, plus /usr/share/dict/words+".com" with dnsperf) bind-dyndb gave the same benchmarking test 18796qps. Now, interestingly, I can also define a DLZ+LDAP line in named.conf after the bind-dyndb. This has the effect that while bind-dyndb is taking 50 mins to start up, it will resolve names using DLZ+LDAP. Sure, at the worse qps of course, but it is at least resolving. [3] However, that has a side-effect that, once bind-dyndb is loaded, it will also query DLZ+LDAP on negative entries. Thus decreasing the performance to 3884qps. Wonder if there is a way to have bind-dyndb ignore DLZ+LDAP /once it has loaded/. That is our current situation. Sincerely, Lund ps. There are some minor faults in the example.ldif, like "idnsName=example.com"'s idnsName is "ipatest.com". And is missing NSRecord. Petr Spacek wrote: > On 25.3.2015 04:45, Jorgen Lundman wrote: >> >> Hey Petr, >> >> Your name came up on the DLZ list a while back and I was interested in >> bind-dyndb-ldap. We run DLZ-LDAP here, and after this weeks DDOS >> firefighting we are looking at increasing our qps. >> >> At the moment, each BIND-DLZ-LDAP server can do about 200qps, which is >> pretty low. But for authoritative it has been sufficient until now. I have >> fixed DLZ-LDAP, enabling MULTITHREADED (it is off by default for some >> reason) but still, it has to query the DB each time. The thing refuses to >> use more than 130MB of cache, each server has 32GB so that is a bit >> annoying. :) >> >> Biggest issue with bind-dyndb-ldap is the schema difference to DLZ's >> schema. Most items can probably be handled with straight keyword rename, >> but one of the larger differences is that bind-dyndb-ldap handles multiple >> "ARecord" for one entry, whereas DLZ uses that odd "A1,DNSHostName=foo" and >> "A2,DNSHostName=foo" to do multiples. >> >> Do you know if anyone has already looked at DLZ to bind-dyndb-ldap >> migration? I suppose as a test case (to see what qps I can get), I can >> convert the DLZ LDAP into zone files, then back to bind-dyndb-ldap schema >> using your supplied scripts. >> >> If you have time, drop me a line. > > Hello! > > As far as I know there is no DLZ->bind-dyndb-ldap convertor. > > I would say that an easiest way is to do AXFR from DLZ-backed zone, save it to > a file and feed the zone file into > https://github.com/pspacek/zone2dyndb-ldif > > IMHO it is not worth to develop special DLZ->bind-dyndb-ldap convertor because > we can always use zone file format as intermediate step. > > LDAP schema used by bind-dyndb-ldap is described on: > https://fedorahosted.org/bind-dyndb-ldap/wiki/LDAPSchema > > > If you have any further questions please contact freeipa-users at redhat.com > mailing list so everyone including search engines can see it :-) > > Thank you for understanding and have a nice day! > -- Jorgen Lundman | Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) From g.fer.ordas at unicyber.co.uk Thu Mar 26 00:32:04 2015 From: g.fer.ordas at unicyber.co.uk (g.fer.ordas at unicyber.co.uk) Date: Thu, 26 Mar 2015 00:32:04 +0000 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <55122775.5040406@redhat.com> References: <55122775.5040406@redhat.com> Message-ID: Hi I am setting up a plain and simple sssd service against my FreeIPA Server. The FreeIPA Server is a Centos 7.1 box with IPA version 4.1 and the client box is ubuntu: Ubuntu 12.04.5 LTS The Users and Credentials are being Synched out of an AD Server (the passwords happened to be transferred using the PassSync Service) Now.. I wanted to setup a very simple sssd service (not the FreeIPA client service) And so far I succeeded on synching the users along with the passwords using SSSD. Now, Trying to get the sudo access sorted I cannot see that working, and I came across some documentation mentioning SSSD is NOT currently supporting IPA schema for the SUDOers if that is the case Can anybody point me to the right document or procedure in terms of getting also the sudoers installed? Would be possible , somehow, to have this sorted WITHOUT using the ipa-client? many thanks! From dpal at redhat.com Thu Mar 26 00:35:59 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Mar 2015 20:35:59 -0400 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: References: <55122775.5040406@redhat.com> Message-ID: <5513546F.8090302@redhat.com> On 03/25/2015 08:32 PM, g.fer.ordas at unicyber.co.uk wrote: > Hi > > I am setting up a plain and simple sssd service against my FreeIPA > Server. > The FreeIPA Server is a Centos 7.1 box with IPA version 4.1 and the > client box is ubuntu: Ubuntu 12.04.5 LTS > > The Users and Credentials are being Synched out of an AD Server (the > passwords happened to be transferred using the PassSync Service) > > Now.. I wanted to setup a very simple sssd service (not the FreeIPA > client service) > And so far I succeeded on synching the users along with the passwords > using SSSD. > > Now, Trying to get the sudo access sorted I cannot see that working, > and I came across some documentation mentioning SSSD is NOT currently > supporting IPA schema for the SUDOers > if that is the case > > Can anybody point me to the right document or procedure in terms of > getting also the sudoers installed? > > Would be possible , somehow, to have this sorted WITHOUT using the > ipa-client? > > many thanks! > > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From yamakasi.014 at gmail.com Thu Mar 26 00:57:35 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 26 Mar 2015 01:57:35 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <550C3104.5050500@redhat.com> References: <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> Message-ID: OK, quite clear but I think that is not going to help me, if you ask me, I might be wrong here as this is what I get: # wget https://ldap.mydomain.tld/ipa/json --2015-03-26 01:22:51-- https://ldap.mydomain.tld/ipa/json Resolving ldap.mydomain.tld (ldap.mydomain.tld)... 10.100.0.250 Connecting to ldap.mydomain.tld (ldap.mydomain.tld)|10.100.0.250|:443... connected. ERROR: cannot verify ldap.mydomain.tld's certificate, issued by '/O=MYDOMAIN.TLD/CN=Certificate Authority': Self-signed certificate encountered. ERROR: certificate common name 'ldap-01.mydomain.tld' doesn't match requested host name 'ldap.mydomain.tld'. To connect to ldap.mydomain.tld insecurely, use `--no-check-certificate'. (I used the gui that actually worked quite OK following the docs, tried your version also but got stuck as I did it on the IPA server, need to recheck that) I think this happens because I use the ca.crt from /etc/ipa/ca.crt and the one I generated in the same file. I need to have them both in my curl certificate. I might be wrong here, but this is where I'm at. Thanks again for your patience. Matt 2015-03-20 15:39 GMT+01:00 Rob Crittenden : > Matt . wrote: >> The right way to sequest a SAN, this seems to need some extra config file ? > > Like I said before, use certmonger, it makes life easier. > > I'll create a new host balancer.example.com with a HTTP service. I'll > generate a cert with a SAN for idp.example.com in that service. I'm > generating the cert on idp.example.com, hence the service-add-host bit. > > On 4.1 (freeipa-server-4.1.3-2.fc22.x86_64) > > # kinit admin > # ipa host-add balancer.example.com > # ipa service-add HTTP/balancer.example.com --force > # ipa service-add-host --hosts=idp.example.com HTTP/balancer.example.com > # ipa-getcert request -f /etc/pki/tls/certs/balancer.pem -k > /etc/pki/tls/private/balancer.key -N CN=balancer.example.com -K > HTTP/balancer.example.com -D idp.example.com > # getcert list -i until it goes to MONITORING > # openssl x509 -text -in /etc/pki/tls/certs/balancer.pem > Certificate: > Data: > Version: 3 (0x2) > Serial Number: 11 (0xb) > Signature Algorithm: sha256WithRSAEncryption > Issuer: O=EXAMPLE.COM, CN=Certificate Authority > Validity > Not Before: Mar 20 14:29:33 2015 GMT > Not After : Mar 20 14:29:33 2017 GMT > Subject: O=EXAMPLE.COM, CN=balancer.example.com > [SNIP] > X509v3 extensions: > [SNIP] > X509v3 Subject Alternative Name: > DNS:idp.example.com, othername:, > othername: > [SNIP] > > SAN was definitely not supported in 3.0. Not sure about 3.3, should work > in 4.0+. > > rob > >> >> 2015-03-19 15:04 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> Isn't this documented well (yet) ? >>> >>> Is what documented yet? >>> >>> rob >>> >>>> >>>> The RH docs are always very detailed about it, but I'm not sure >>>> here... I see solutions but not 100% from A to Z to make sure we do it >>>> the proper way. >>>> >>>> 2015-03-12 16:59 GMT+01:00 Matt . : >>>>> Not worried, I need to try. >>>>> >>>>> I think it's not an issue as we use persistance for the connection. We >>>>> only do some user adding/chaging stuff, nothing really fancy but it >>>>> needs to be decent. As persistence comes in I think we don't have to >>>>> worry about it, we discussed that here earlier as I remember. >>>>> >>>>> Or do I ? >>>>> >>>>> Something else; did you had a nice PTO ? >>>>> >>>>> 2015-03-12 15:54 GMT+01:00 Rob Crittenden : >>>>>> Matt . wrote: >>>>>>> Hi, >>>>>>> >>>>>>> Security wise I can understand that. >>>>>>> >>>>>>> Yes I have read about that... but that would let me use the >>>>>>> loadbalancer to connect ? I was not sure if the SAN would "connect" as >>>>>>> "other" host. >>>>>> >>>>>> Kerberos through a load balancer can be a problem. Is this what you're >>>>>> worried about? >>>>>> >>>>>> rob >>>>>> >>>>>>> >>>>>>> 2015-03-12 15:07 GMT+01:00 Rob Crittenden : >>>>>>>> Matt . wrote: >>>>>>>>> Hi Guys, >>>>>>>>> >>>>>>>>> Is Rob able to look at this ? I hope he has some sparetime as I'm >>>>>>>>> kinda stuck with this issue. >>>>>>>> >>>>>>>> Wildcard certs are not supported. >>>>>>>> >>>>>>>> You can request a SAN with certmonger using -D . That will work >>>>>>>> with IPA 4.x for sure, maybe 3.3.5. >>>>>>>> >>>>>>>> rob >>>>>>>> >>>>>>>>> >>>>>>>>> Thanks! >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> 2015-03-08 12:30 GMT+01:00 Matt . : >>>>>>>>>> I'm reviewing some things. >>>>>>>>>> >>>>>>>>>> When I'm using a loadbalancer, which I prefer in this setup I need to >>>>>>>>>> have the same certificates on both servers. Maybe a wildcard for my >>>>>>>>>> domain could do instead of having only both fqdn's of the servers >>>>>>>>>> including the loadbalancer's fqdn. >>>>>>>>>> >>>>>>>>>> But the question remains, how? >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> I will balance with IP persistance so I think there won't be any >>>>>>>>>>> mixing as long as that "used" server is online. >>>>>>>>>>> >>>>>>>>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>>>>>>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>>>>>>>>> >>>>>>>>>>>>> OK, understood. >>>>>>>>>>>>> >>>>>>>>>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>>>>>>>>> record and the first is not reacable, would it try to do it again or >>>>>>>>>>>>> will handle DNS this in front of it ? >>>>>>>>>>>>> >>>>>>>>>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>>>>>>>>> checked if the user was able to auth himself using his ldap >>>>>>>>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>>>>>>>>> to the IPA server. >>>>>>>>>>>>> >>>>>>>>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>>>>>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>>>>>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>>>>>>>>> from PHP for an example. Building in extra checks in front could be >>>>>>>>>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>>>>>>>>> better. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>>>>>>>>> Rob. What is our failover logic for API? >>>>>>>>>>>> >>>>>>>>>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>>>>>>>>> whole conversation goes to the same server you should be fine. I do not >>>>>>>>>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>>>>>>>>> cert there then if you can enforce the use of the same server in this case. >>>>>>>>>>>> >>>>>>>>>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>>>>>>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>>>>>>>>> >>>>>>>>>>>> Rob does that make sense for you? >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Thanks! >>>>>>>>>>>>> >>>>>>>>>>>>> Cheers, >>>>>>>>>>>>> >>>>>>>>>>>>> Matt >>>>>>>>>>>>> >>>>>>>>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>>>>>>>>> SRV won't fit here sorry to say. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>>>>>>>>> believe ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>>>>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>>>>>>>>> it >>>>>>>>>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>>>>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>>>>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>>>>>>>>> you >>>>>>>>>>>>>> do not have any load balancers and this is the common case. You are >>>>>>>>>>>>>> trying >>>>>>>>>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>>>>>>>>> 100% there in step 6 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Matthijs >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>>>>>>>>> curl/json. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>>>>>>>>> It >>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>>>>>>>>> easiest >>>>>>>>>>>>>>>> way. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>> is to >>>>>>>>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>>>>>>>>> works >>>>>>>>>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>>>>>>>>> IPA >>>>>>>>>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>>>>>>>>> own >>>>>>>>>>>>>>>> keytab with different key. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>>>>>>>>> possibility >>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>> sharing keytabs between IPA services. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Does this make it more clear ? >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>>>>>>>>> clients. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>>>>>>>>> ipa >>>>>>>>>>>>>>>>>>> server ? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Any other options ? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>>>>>>>>> detail, please? >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>>>>>>>>> possible to use >>>>>>>>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>>>>>>>>> to ipa >>>>>>>>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>>>>>>>>> classical load >>>>>>>>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>>>>>>>>> you to mess >>>>>>>>>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Petr Spacek @ Red Hat >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> 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. >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> 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 Thu Mar 26 01:14:53 2015 From: Less at imagine-sw.com (Les Stott) Date: Thu, 26 Mar 2015 01:14:53 +0000 Subject: [Freeipa-users] clarification on expired password behaviour Message-ID: <4ED173A868981548967B4FCA27072226280E262C@AACMBXP04.exchserver.com> Hi All, Running freeipa 3.0.0.42 on rhel 6.6, all standard packages. I also have freeradius installed which is used for network devices (cisco, brocade, f5, ucs etc) to authenticate users. Freeradius is using the ldap store in FreeIPA as an authentication backend. All is working fine. But I would like clarification on the following... A user account in freeipa is showing up as having an expired password. This is confirmed by logging into the freeipa web interface or ssh and seeing a prompt to change password immediately. If I choose to not set the password, it remains expired. Now, if I try to access a network device that is using radius based auth, using the account with the expired password, it successfully logs in even though the password is expired. Is this normal? i.e. a password can still be used even if it's in an expired state? I understand that going via radius using freeipa as an ldap backend is not the normal process. Is there a way to make password authentication fail if a password is expired when used in this scenario? Thanks in advance, Regards, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Mar 26 01:51:52 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Mar 2015 21:51:52 -0400 Subject: [Freeipa-users] clarification on expired password behaviour In-Reply-To: <4ED173A868981548967B4FCA27072226280E262C@AACMBXP04.exchserver.com> References: <4ED173A868981548967B4FCA27072226280E262C@AACMBXP04.exchserver.com> Message-ID: <55136638.6000504@redhat.com> On 03/25/2015 09:14 PM, Les Stott wrote: > > Hi All, > > Running freeipa 3.0.0.42 on rhel 6.6, all standard packages. > > I also have freeradius installed which is used for network devices > (cisco, brocade, f5, ucs etc) to authenticate users. Freeradius is > using the ldap store in FreeIPA as an authentication backend. > > All is working fine. > > But I would like clarification on the following... > > A user account in freeipa is showing up as having an expired password. > This is confirmed by logging into the freeipa web interface or ssh and > seeing a prompt to change password immediately. > > If I choose to not set the password, it remains expired. > > Now, if I try to access a network device that is using radius based > auth, using the account with the expired password, it successfully > logs in even though the password is expired. > > Is this normal? i.e. a password can still be used even if it's in an > expired state? > > I understand that going via radius using freeipa as an ldap backend is > not the normal process. > > Is there a way to make password authentication fail if a password is > expired when used in this scenario? > > Thanks in advance, > > Regards, > > Les > > > https://fedorahosted.org/freeipa/ticket/1539 You can see the details in the ticket. The workaround will be to use kinit instead of LDAP for authentication in freeradius or use pam and leverage SSSD as an IPA client on the RADIUS server. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.fer.ordas at unicyber.co.uk Thu Mar 26 02:41:23 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Wed, 25 Mar 2015 19:41:23 -0700 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <5513546F.8090302@redhat.com> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> Message-ID: <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> Exactly the document i was having a look at. In simple words,is possible to work this around and how,? Otherwise i have to drop freeipa and get back to 389_ds as still seems fully ldap sssd compatible. Have you got any doc clearly stating how to get this done? I really invested many days on reaching this far being? sudo the last tiny bit to get sorted which is hugely frustrated. Thanks for all the support Sent from Type Mail On Mar 25, 2015, 5:35 PM, at 5:35 PM, Dmitri Pal wrote: >On 03/25/2015 08:32 PM, g.fer.ordas at unicyber.co.uk wrote: >> Hi >> >> I am setting up a plain and simple sssd service against my FreeIPA >> Server. >> The FreeIPA Server is a Centos 7.1 box with IPA version 4.1 and the >> client box is ubuntu: Ubuntu 12.04.5 LTS >> >> The Users and Credentials are being Synched out of an AD Server (the >> passwords happened to be transferred using the PassSync Service) >> >> Now.. I wanted to setup a very simple sssd service (not the FreeIPA >> client service) >> And so far I succeeded on synching the users along with the passwords > >> using SSSD. >> >> Now, Trying to get the sudo access sorted I cannot see that working, >> and I came across some documentation mentioning SSSD is NOT currently > >> supporting IPA schema for the SUDOers >> if that is the case >> >> Can anybody point me to the right document or procedure in terms of >> getting also the sudoers installed? >> >> Would be possible , somehow, to have this sorted WITHOUT using the >> ipa-client? >> >> many thanks! >> >> >http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > >-- >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 dpal at redhat.com Thu Mar 26 02:52:06 2015 From: dpal at redhat.com (Dmitri Pal) Date: Wed, 25 Mar 2015 22:52:06 -0400 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> Message-ID: <55137456.3010006@redhat.com> On 03/25/2015 10:41 PM, Gonzalo Fernandez Ordas wrote: > > Exactly the document i was having a look at. > In simple words,is possible to work this around and how,? > It is possible. The doc has guidelines. Are they not clear? > Otherwise i have to drop freeipa and get back to 389_ds as still seems > fully ldap sssd compatible. > > Have you got any doc clearly stating how to get this done? > I really invested many days on reaching this far being sudo the last > tiny bit to get sorted which is hugely frustrated. > > Thanks for all the support > Sent from Type Mail > > On Mar 25, 2015, at 5:35 PM, Dmitri Pal > wrote: > > On 03/25/2015 08:32 PM, g.fer.ordas at unicyber.co.uk wrote: > > Hi I am setting up a plain and simple sssd service against my > FreeIPA Server. The FreeIPA Server is a Centos 7.1 box with > IPA version 4.1 and the client box is ubuntu: Ubuntu 12.04.5 > LTS The Users and Credentials are being Synched out of an AD > Server (the passwords happened to be transferred using the > PassSync Service) Now.. I wanted to setup a very simple sssd > service (not the FreeIPA client service) And so far I > succeeded on synching the users along with the passwords using > SSSD. Now, Trying to get the sudo access sorted I cannot see > that working, and I came across some documentation mentioning > SSSD is NOT currently supporting IPA schema for the SUDOers if > that is the case Can anybody point me to the right document or > procedure in terms of getting also the sudoers installed? > Would be possible , somehow, to have this sorted WITHOUT using > the ipa-client? many thanks! > > > > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Thu Mar 26 02:56:48 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Wed, 25 Mar 2015 22:56:48 -0400 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> Message-ID: <55137570.2070606@redhat.com> Gonzalo Fernandez Ordas wrote: > Exactly the document i was having a look at. > In simple words,is possible to work this around and how,? > Otherwise i have to drop freeipa and get back to 389_ds as still seems > fully ldap sssd compatible. > > Have you got any doc clearly stating how to get this done? > I really invested many days on reaching this far being sudo the last > tiny bit to get sorted which is hugely frustrated. How to configure sudo largely depends on the version of SSSD you have in Ubuntu. I'm not sure how configuring SSSD is going to affect your choice of server though. If you still use SSSD the same problem will exist regardless, right? rob > > Thanks for all the support > Sent from Type Mail > > On Mar 25, 2015, at 5:35 PM, Dmitri Pal > wrote: > > On 03/25/2015 08:32 PM, g.fer.ordas at unicyber.co.uk wrote: > > Hi > > I am setting up a plain and simple sssd service against my FreeIPA > Server. > The FreeIPA Server is a Centos 7.1 box with IPA version 4.1 and the > client box is ubuntu: Ubuntu 12.04.5 LTS > > The Users and Credentials are being Synched out of an AD Server > (the > passwords happened to be transferred using the PassSync Service) > > Now.. I wanted to setup a very simple sssd service (not the FreeIPA > client service) > And so far I succeeded on synching the users along with the > passwords > using SSSD. > > Now, Trying to get the sudo access sorted I cannot see that > working, > and I came across some documentation mentioning SSSD is NOT > currently > supporting IPA schema for the SUDOers > if that is the case > > Can anybody point me to the right document or procedure in terms of > getting also the sudoers installed? > > Would be possible , somehow, to have this sorted WITHOUT using the > ipa-client? > > many thanks! > > > > http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf > > > From munna.hadoop at gmail.com Thu Mar 26 03:39:49 2015 From: munna.hadoop at gmail.com (Shaik M) Date: Thu, 26 Mar 2015 11:39:49 +0800 Subject: [Freeipa-users] Unable to Install IPA In-Reply-To: <551067A5.60002@redhat.com> References: <54F1360B.2080807@redhat.com> <54F5C301.60604@redhat.com> <551067A5.60002@redhat.com> Message-ID: Hi, I have stopped working on IPA and we are using 389-DS. Thanks, Shaik On 24 March 2015 at 03:21, Endi Sukma Dewata wrote: > On 3/3/2015 8:19 AM, Endi Sukma Dewata wrote: > >> On 2/28/2015 1:01 PM, Hadoop Solutions wrote: >> >>> Hi Rob, >>> >>> please find the attached log of /var/log/ipaserver-install.log >>> >>> kindly let me know the solution for this.. >>> >>> Thanks, >>> Shaik >>> >> >> Hi, >> >> I see this near the bottom of the ipaserver-install.log. >> >> ############################################# >> Attempting to connect to: sv2lxdpdsedi02.corp.equinix.com:9445 >> Connected. >> Posting Query = >> https://sv2lxdpdsedi02.corp.equinix.com:9445//ca/admin/ >> console/config/wizard?p=9&op=next&xml=true&host= >> sv2lxdpdsedi02.corp.equinix.com&port=7389&binddn=cn% >> 3DDirectory+Manager&__bindpwd=XXXXXXXX&basedn=o%3Dipaca& >> database=ipaca&display=%24displayStr >> >> RESPONSE STATUS: HTTP/1.1 404 Not Found >> RESPONSE HEADER: Server: Apache-Coyote/1.1 >> RESPONSE HEADER: Content-Type: text/html;charset=UTF-8 >> RESPONSE HEADER: Date: Sat, 28 Feb 2015 05:57:35 GMT >> RESPONSE HEADER: Connection: close >> ERROR: unable to parse xml >> ERROR XML = >> ERROR: Tag='updateStatus' has no values >> Error in LdapConnectionPanel(): updateStatus value is null >> ERROR: ConfigureCA: LdapConnectionPanel() failure >> ERROR: unable to create CA >> >> ####################################################################### >> >> 2015-02-28T05:57:35Z DEBUG stderr=[Fatal Error] :-1:-1: Premature end of >> file. >> org.xml.sax.SAXParseException: Premature end of file. >> at org.apache.xerces.parsers.DOMParser.parse(xerces-j2-2.7.1.jar.so) >> at >> org.apache.xerces.jaxp.DocumentBuilderImpl.parse(xerces-j2-2.7.1.jar.so) >> at javax.xml.parsers.DocumentBuilder.parse(libgcj.so.10) >> at ParseXML.parse(ParseXML.java:258) >> at ConfigureCA.getStatus(ConfigureCA.java:205) >> at ConfigureCA.checkStatus(ConfigureCA.java:221) >> at ConfigureCA.checkStatus(ConfigureCA.java:216) >> at ConfigureCA.LdapConnectionPanel(ConfigureCA.java:510) >> at ConfigureCA.ConfigureCAInstance(ConfigureCA.java:1225) >> at ConfigureCA.main(ConfigureCA.java:1672) >> >> Could you post the /var/log/pki-ca/debug? Thanks. >> >> > Hi, if this is still a problem please let me know. Thanks. > > -- > Endi S. Dewata > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Less at imagine-sw.com Thu Mar 26 03:45:26 2015 From: Less at imagine-sw.com (Les Stott) Date: Thu, 26 Mar 2015 03:45:26 +0000 Subject: [Freeipa-users] clarification on expired password behaviour In-Reply-To: <55136638.6000504@redhat.com> References: <4ED173A868981548967B4FCA27072226280E262C@AACMBXP04.exchserver.com> <55136638.6000504@redhat.com> Message-ID: <4ED173A868981548967B4FCA27072226280E2878@AACMBXP04.exchserver.com> From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Dmitri Pal Sent: Thursday, 26 March 2015 12:52 PM To: freeipa-users at redhat.com Subject: Re: [Freeipa-users] clarification on expired password behaviour On 03/25/2015 09:14 PM, Les Stott wrote: Hi All, Running freeipa 3.0.0.42 on rhel 6.6, all standard packages. I also have freeradius installed which is used for network devices (cisco, brocade, f5, ucs etc) to authenticate users. Freeradius is using the ldap store in FreeIPA as an authentication backend. All is working fine. But I would like clarification on the following... A user account in freeipa is showing up as having an expired password. This is confirmed by logging into the freeipa web interface or ssh and seeing a prompt to change password immediately. If I choose to not set the password, it remains expired. Now, if I try to access a network device that is using radius based auth, using the account with the expired password, it successfully logs in even though the password is expired. Is this normal? i.e. a password can still be used even if it's in an expired state? I understand that going via radius using freeipa as an ldap backend is not the normal process. Is there a way to make password authentication fail if a password is expired when used in this scenario? Thanks in advance, Regards, Les https://fedorahosted.org/freeipa/ticket/1539 You can see the details in the ticket. The workaround will be to use kinit instead of LDAP for authentication in freeradius or use pam and leverage SSSD as an IPA client on the RADIUS server. Thanks Dmitri. In fact the radius server is installed on the freeipa server and talks locally via loopback. I will look at kinit and sssd options. Regards, Les -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.fer.ordas at unicyber.co.uk Thu Mar 26 05:21:19 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Wed, 25 Mar 2015 22:21:19 -0700 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <55137570.2070606@redhat.com> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> <55137570.2070606@redhat.com> Message-ID: <5513974F.2080608@unicyber.co.uk> I have to test a few options to see how I can overcome that issue. A pity as I nearly got everything setup in full. Any findings I will get back to the list as this might be relevant for other users. On 25/03/2015 19:56, Rob Crittenden wrote: > Gonzalo Fernandez Ordas wrote: >> Exactly the document i was having a look at. >> In simple words,is possible to work this around and how,? >> Otherwise i have to drop freeipa and get back to 389_ds as still seems >> fully ldap sssd compatible. >> >> Have you got any doc clearly stating how to get this done? >> I really invested many days on reaching this far being sudo the last >> tiny bit to get sorted which is hugely frustrated. > How to configure sudo largely depends on the version of SSSD you have in > Ubuntu. I'm not sure how configuring SSSD is going to affect your choice > of server though. If you still use SSSD the same problem will exist > regardless, right? > > rob > >> Thanks for all the support >> Sent from Type Mail >> >> On Mar 25, 2015, at 5:35 PM, Dmitri Pal > > wrote: >> >> On 03/25/2015 08:32 PM, g.fer.ordas at unicyber.co.uk wrote: >> >> Hi >> >> I am setting up a plain and simple sssd service against my FreeIPA >> Server. >> The FreeIPA Server is a Centos 7.1 box with IPA version 4.1 and the >> client box is ubuntu: Ubuntu 12.04.5 LTS >> >> The Users and Credentials are being Synched out of an AD Server >> (the >> passwords happened to be transferred using the PassSync Service) >> >> Now.. I wanted to setup a very simple sssd service (not the FreeIPA >> client service) >> And so far I succeeded on synching the users along with the >> passwords >> using SSSD. >> >> Now, Trying to get the sudo access sorted I cannot see that >> working, >> and I came across some documentation mentioning SSSD is NOT >> currently >> supporting IPA schema for the SUDOers >> if that is the case >> >> Can anybody point me to the right document or procedure in terms of >> getting also the sudoers installed? >> >> Would be possible , somehow, to have this sorted WITHOUT using the >> ipa-client? >> >> many thanks! >> >> >> >> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> >> >> > From sbose at redhat.com Thu Mar 26 08:23:21 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 26 Mar 2015 09:23:21 +0100 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <55134C60.3060505@redhat.com> References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> <1427298281.8302.62.camel@willson.usersys.redhat.com> <55134C60.3060505@redhat.com> Message-ID: <20150326082321.GI3550@p.redhat.com> On Wed, Mar 25, 2015 at 08:01:36PM -0400, Dmitri Pal wrote: > On 03/25/2015 11:44 AM, Simo Sorce wrote: > >On Wed, 2015-03-25 at 14:46 +0000, Guertin, David S. wrote: > >>Follow-up: today I tried clearing the sssd cache and restarting sssd on all three clients, and all three lost their AD users: > >> > >># rm -f /var/lib/sss/db/* > >># service sssd restart > >>Stopping sssd: [ OK ] > >>Starting sssd: [ OK ] > >># id 'MIDD\juser' > >>id: MIDD\juser: No such user > >> > >>David Guertin > >> > >This is normal, users are "loaded in" when they actually try to Log In. > > > >Simo. > > > Yes. The ability to look up AD users that never authenticated was added in > 7.1 and 6.7 (i.e. SSSD 1.12) I would like to just clarify tis a bit. The support to lookup up secondary groups (the group list the id command shows) for user which never authenticated was added in 7.1/6.7. The plain user lookup as e.g. done with the 'getent passwd username' always worked. David, the IPA clients will connect the IPA server to get the user data. This means if the server cannot resolve the user the clients cannot either. So the IPA server should be checked first. You said that you have three IPA servers (master and replicas). Did you run ipa-adtrust-install on all server? If not, please do. If you are not sure, running ipa-adtrust-install multiple times does not so any harm. Since you are using RHEL-6 clients I assume your IPA servers are on RHEL-6 as well. In this case please try if the command wbinfo -n 'MIDD\juser' returns the SID of the user on the IPA server. HTH bye, Sumit > > -- > 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 jhrozek at redhat.com Thu Mar 26 08:31:10 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 26 Mar 2015 04:31:10 -0400 (EDT) Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <5513974F.2080608@unicyber.co.uk> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> <55137570.2070606@redhat.com> <5513974F.2080608@unicyber.co.uk> Message-ID: <901732470.4546498.1427358670169.JavaMail.zimbra@redhat.com> If you have SSSD 1.9.6 or newer all the sudo configuration boils down to including 'sss' for 'sudoers' in nsswitch.conf and sudo_provider=ipa in sssd.conf. You also need a reasonably recent sudo itself. Posting versions of SSSD and sudo would help. ----- Original Message ----- From: "Gonzalo Fernandez Ordas" To: "Rob Crittenden" , dpal at redhat.com Cc: freeipa-users at redhat.com Sent: Thursday, 26 March, 2015 6:21:19 AM Subject: Re: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD I have to test a few options to see how I can overcome that issue. A pity as I nearly got everything setup in full. Any findings I will get back to the list as this might be relevant for other users. On 25/03/2015 19:56, Rob Crittenden wrote: > Gonzalo Fernandez Ordas wrote: >> Exactly the document i was having a look at. >> In simple words,is possible to work this around and how,? >> Otherwise i have to drop freeipa and get back to 389_ds as still seems >> fully ldap sssd compatible. >> >> Have you got any doc clearly stating how to get this done? >> I really invested many days on reaching this far being sudo the last >> tiny bit to get sorted which is hugely frustrated. > How to configure sudo largely depends on the version of SSSD you have in > Ubuntu. I'm not sure how configuring SSSD is going to affect your choice > of server though. If you still use SSSD the same problem will exist > regardless, right? > > rob > >> Thanks for all the support >> Sent from Type Mail >> >> On Mar 25, 2015, at 5:35 PM, Dmitri Pal > > wrote: >> >> On 03/25/2015 08:32 PM, g.fer.ordas at unicyber.co.uk wrote: >> >> Hi >> >> I am setting up a plain and simple sssd service against my FreeIPA >> Server. >> The FreeIPA Server is a Centos 7.1 box with IPA version 4.1 and the >> client box is ubuntu: Ubuntu 12.04.5 LTS >> >> The Users and Credentials are being Synched out of an AD Server >> (the >> passwords happened to be transferred using the PassSync Service) >> >> Now.. I wanted to setup a very simple sssd service (not the FreeIPA >> client service) >> And so far I succeeded on synching the users along with the >> passwords >> using SSSD. >> >> Now, Trying to get the sudo access sorted I cannot see that >> working, >> and I came across some documentation mentioning SSSD is NOT >> currently >> supporting IPA schema for the SUDOers >> if that is the case >> >> Can anybody point me to the right document or procedure in terms of >> getting also the sudoers installed? >> >> Would be possible , somehow, to have this sorted WITHOUT using the >> ipa-client? >> >> many thanks! >> >> >> >> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >> >> >> > -- 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 yamakasi.014 at gmail.com Thu Mar 26 09:45:52 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 26 Mar 2015 10:45:52 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9BA31.9070706@redhat.com> <54F9C4C8.8020008@redhat.com> <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> Message-ID: When digging around I see this documentation: http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html I would except that server.example.com is not going to be accepted by IPA when you visit the webgui like that ? 2015-03-26 1:57 GMT+01:00 Matt . : > OK, quite clear but I think that is not going to help me, if you ask > me, I might be wrong here as this is what I get: > > # wget https://ldap.mydomain.tld/ipa/json > --2015-03-26 01:22:51-- https://ldap.mydomain.tld/ipa/json > Resolving ldap.mydomain.tld (ldap.mydomain.tld)... 10.100.0.250 > Connecting to ldap.mydomain.tld > (ldap.mydomain.tld)|10.100.0.250|:443... connected. > ERROR: cannot verify ldap.mydomain.tld's certificate, issued by > '/O=MYDOMAIN.TLD/CN=Certificate Authority': > Self-signed certificate encountered. > ERROR: certificate common name 'ldap-01.mydomain.tld' doesn't > match requested host name 'ldap.mydomain.tld'. > To connect to ldap.mydomain.tld insecurely, use `--no-check-certificate'. > > (I used the gui that actually worked quite OK following the docs, > tried your version also but got stuck as I did it on the IPA server, > need to recheck that) > > I think this happens because I use the ca.crt from /etc/ipa/ca.crt and > the one I generated in the same file. I need to have them both in my > curl certificate. > > I might be wrong here, but this is where I'm at. > > Thanks again for your patience. > > Matt > > > > 2015-03-20 15:39 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> The right way to sequest a SAN, this seems to need some extra config file ? >> >> Like I said before, use certmonger, it makes life easier. >> >> I'll create a new host balancer.example.com with a HTTP service. I'll >> generate a cert with a SAN for idp.example.com in that service. I'm >> generating the cert on idp.example.com, hence the service-add-host bit. >> >> On 4.1 (freeipa-server-4.1.3-2.fc22.x86_64) >> >> # kinit admin >> # ipa host-add balancer.example.com >> # ipa service-add HTTP/balancer.example.com --force >> # ipa service-add-host --hosts=idp.example.com HTTP/balancer.example.com >> # ipa-getcert request -f /etc/pki/tls/certs/balancer.pem -k >> /etc/pki/tls/private/balancer.key -N CN=balancer.example.com -K >> HTTP/balancer.example.com -D idp.example.com >> # getcert list -i until it goes to MONITORING >> # openssl x509 -text -in /etc/pki/tls/certs/balancer.pem >> Certificate: >> Data: >> Version: 3 (0x2) >> Serial Number: 11 (0xb) >> Signature Algorithm: sha256WithRSAEncryption >> Issuer: O=EXAMPLE.COM, CN=Certificate Authority >> Validity >> Not Before: Mar 20 14:29:33 2015 GMT >> Not After : Mar 20 14:29:33 2017 GMT >> Subject: O=EXAMPLE.COM, CN=balancer.example.com >> [SNIP] >> X509v3 extensions: >> [SNIP] >> X509v3 Subject Alternative Name: >> DNS:idp.example.com, othername:, >> othername: >> [SNIP] >> >> SAN was definitely not supported in 3.0. Not sure about 3.3, should work >> in 4.0+. >> >> rob >> >>> >>> 2015-03-19 15:04 GMT+01:00 Rob Crittenden : >>>> Matt . wrote: >>>>> Isn't this documented well (yet) ? >>>> >>>> Is what documented yet? >>>> >>>> rob >>>> >>>>> >>>>> The RH docs are always very detailed about it, but I'm not sure >>>>> here... I see solutions but not 100% from A to Z to make sure we do it >>>>> the proper way. >>>>> >>>>> 2015-03-12 16:59 GMT+01:00 Matt . : >>>>>> Not worried, I need to try. >>>>>> >>>>>> I think it's not an issue as we use persistance for the connection. We >>>>>> only do some user adding/chaging stuff, nothing really fancy but it >>>>>> needs to be decent. As persistence comes in I think we don't have to >>>>>> worry about it, we discussed that here earlier as I remember. >>>>>> >>>>>> Or do I ? >>>>>> >>>>>> Something else; did you had a nice PTO ? >>>>>> >>>>>> 2015-03-12 15:54 GMT+01:00 Rob Crittenden : >>>>>>> Matt . wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> Security wise I can understand that. >>>>>>>> >>>>>>>> Yes I have read about that... but that would let me use the >>>>>>>> loadbalancer to connect ? I was not sure if the SAN would "connect" as >>>>>>>> "other" host. >>>>>>> >>>>>>> Kerberos through a load balancer can be a problem. Is this what you're >>>>>>> worried about? >>>>>>> >>>>>>> rob >>>>>>> >>>>>>>> >>>>>>>> 2015-03-12 15:07 GMT+01:00 Rob Crittenden : >>>>>>>>> Matt . wrote: >>>>>>>>>> Hi Guys, >>>>>>>>>> >>>>>>>>>> Is Rob able to look at this ? I hope he has some sparetime as I'm >>>>>>>>>> kinda stuck with this issue. >>>>>>>>> >>>>>>>>> Wildcard certs are not supported. >>>>>>>>> >>>>>>>>> You can request a SAN with certmonger using -D . That will work >>>>>>>>> with IPA 4.x for sure, maybe 3.3.5. >>>>>>>>> >>>>>>>>> rob >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Thanks! >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> 2015-03-08 12:30 GMT+01:00 Matt . : >>>>>>>>>>> I'm reviewing some things. >>>>>>>>>>> >>>>>>>>>>> When I'm using a loadbalancer, which I prefer in this setup I need to >>>>>>>>>>> have the same certificates on both servers. Maybe a wildcard for my >>>>>>>>>>> domain could do instead of having only both fqdn's of the servers >>>>>>>>>>> including the loadbalancer's fqdn. >>>>>>>>>>> >>>>>>>>>>> But the question remains, how? >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> 2015-03-07 10:37 GMT+01:00 Matt . : >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> I will balance with IP persistance so I think there won't be any >>>>>>>>>>>> mixing as long as that "used" server is online. >>>>>>>>>>>> >>>>>>>>>>>> 2015-03-06 19:16 GMT+01:00 Dmitri Pal : >>>>>>>>>>>>> On 03/06/2015 11:05 AM, Matt . wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> OK, understood. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But when a webservice does execute a command (from scripting) to a SVR >>>>>>>>>>>>>> record and the first is not reacable, would it try to do it again or >>>>>>>>>>>>>> will handle DNS this in front of it ? >>>>>>>>>>>>>> >>>>>>>>>>>>>> I do a kinit against an IPA server using a keytab after I first >>>>>>>>>>>>>> checked if the user was able to auth himself using his ldap >>>>>>>>>>>>>> credentials, if so, this kinit exec is fired and I do some CURL stuff >>>>>>>>>>>>>> to the IPA server. >>>>>>>>>>>>>> >>>>>>>>>>>>>> That's why I wanted a loadbalancer, the loadbalancer sees if a server >>>>>>>>>>>>>> is down and doesn't even try to direct any of the commands to it... >>>>>>>>>>>>>> I'm not sure if the SRV will handle this well when doing these command >>>>>>>>>>>>>> from PHP for an example. Building in extra checks in front could be >>>>>>>>>>>>>> done but it not ideal as a loadbalancer can handle such things much >>>>>>>>>>>>>> better. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> OK, this makes things much more clear. Thanks for the explanation. >>>>>>>>>>>>> Rob. What is our failover logic for API? >>>>>>>>>>>>> >>>>>>>>>>>>> For CLI we use a negotiation and then we store a cookie so as long as the >>>>>>>>>>>>> whole conversation goes to the same server you should be fine. I do not >>>>>>>>>>>>> think you need to re-encrypt the traffic at load balancer and thus have a >>>>>>>>>>>>> cert there then if you can enforce the use of the same server in this case. >>>>>>>>>>>>> >>>>>>>>>>>>> The issue I anticipate is with Kerberos. I think you should not load balance >>>>>>>>>>>>> the Kerberos traffic, only the API commands starting with the negotiation. >>>>>>>>>>>>> >>>>>>>>>>>>> Rob does that make sense for you? >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks! >>>>>>>>>>>>>> >>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>> >>>>>>>>>>>>>> Matt >>>>>>>>>>>>>> >>>>>>>>>>>>>> 2015-03-06 16:41 GMT+01:00 Dmitri Pal : >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> On 03/06/2015 10:24 AM, Matt . wrote: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I'm really bound to a loadbalancer, as it's HA setup of loadbalancers, >>>>>>>>>>>>>>>> SRV won't fit here sorry to say. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> I auth users, so their keytab should be the same between two masters I >>>>>>>>>>>>>>>> believe ? >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Each entity in Kerberos exchange has its own identity and key. >>>>>>>>>>>>>>> If you send a ticket that is destined to service A instead to service B >>>>>>>>>>>>>>> it >>>>>>>>>>>>>>> would not work unless they share the same keys and identity. Sharinf same >>>>>>>>>>>>>>> keys and identities between the servers just would not work with IPA. >>>>>>>>>>>>>>> Keep in mind that IPA clients and server need to work and fail over if >>>>>>>>>>>>>>> you >>>>>>>>>>>>>>> do not have any load balancers and this is the common case. You are >>>>>>>>>>>>>>> trying >>>>>>>>>>>>>>> to add one where it is really not needed creating overhead for yourself. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> In that case... I need to add the altnames to the certs, but I'm not >>>>>>>>>>>>>>>> 100% there in step 6 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Thanks again! >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Cheers, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Matthijs >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 2015-03-06 16:16 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> On 6.3.2015 15:39, Matt . wrote: >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> I have 2 IPA servers where I kinit to and post to the api using >>>>>>>>>>>>>>>>>> curl/json. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> If we are talking purely about scripting, you can use IPA Python API. >>>>>>>>>>>>>>>>> It >>>>>>>>>>>>>>>>> will >>>>>>>>>>>>>>>>> handle fail over for you even without any load balancer. That would be >>>>>>>>>>>>>>>>> easiest >>>>>>>>>>>>>>>>> way. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As I need redundancy and don't want to have it script managed, but one >>>>>>>>>>>>>>>>>> central point where I can tal to I use a loadbalancer. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Well, if you can control clients then the easiest and most universal >>>>>>>>>>>>>>>>> way >>>>>>>>>>>>>>>>> is to >>>>>>>>>>>>>>>>> use DNS SRV records and add failover logic to clients. That solution >>>>>>>>>>>>>>>>> works >>>>>>>>>>>>>>>>> even when servers are geographically distributed/in different networks >>>>>>>>>>>>>>>>> and >>>>>>>>>>>>>>>>> does not have single point of failure (the load balancer). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As I connect to the loadbalancer using DNAT, so the client IP is known >>>>>>>>>>>>>>>>>> on the IPA server because this is needed for the http service >>>>>>>>>>>>>>>>>> principals I need to add the loadbalancer hostname to my IPA server >>>>>>>>>>>>>>>>>> and make it as an ALT name to it's Certificate. >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> As the users are the same on both servers I would asume i can use a >>>>>>>>>>>>>>>>>> keytab for a user against both servers from my clients. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm talking about keytabs on the FreeIPA servers - services running on >>>>>>>>>>>>>>>>> IPA >>>>>>>>>>>>>>>>> server have their own keytabs too. Every service on every server has >>>>>>>>>>>>>>>>> own >>>>>>>>>>>>>>>>> keytab with different key. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> You need to talk with Simo or some other Kerberos guru about >>>>>>>>>>>>>>>>> possibility >>>>>>>>>>>>>>>>> of >>>>>>>>>>>>>>>>> sharing keytabs between IPA services. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> Does this make it more clear ? >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm still not sure if you want to have human users too or just API >>>>>>>>>>>>>>>>> clients. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> 2015-03-06 15:31 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> On 6.3.2015 15:13, Matt . wrote: >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> But as the user is the same, I could use the same keytab for each >>>>>>>>>>>>>>>>>>>> ipa >>>>>>>>>>>>>>>>>>>> server ? >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> I need to use the API indeed, so need to issue the http service. >>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> Any other options ? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I do not really understand your use case. Could you describe it in >>>>>>>>>>>>>>>>>>> detail, please? >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>> 2015-03-06 14:24 GMT+01:00 Petr Spacek : >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> On 6.3.2015 14:08, Martin Kosek wrote: >>>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>>> I'm figuring out how to regenerate the webserver certificates so I >>>>>>>>>>>>>>>>>>>>>> can >>>>>>>>>>>>>>>>>>>>>> use a loadbalancer in front of my ipa servers. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> Are you talking about FreeIPA web interface? It is technically >>>>>>>>>>>>>>>>>>>>> possible to use >>>>>>>>>>>>>>>>>>>>> load-balancer but it will be really hacky. You would have to solve >>>>>>>>>>>>>>>>>>>>> certificates and also distribute shared keytabs and so on. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> I would recommend you to use "something" which issues HTTP redirect >>>>>>>>>>>>>>>>>>>>> to ipa >>>>>>>>>>>>>>>>>>>>> server 1/2/3/4/5 according to current state instead of using >>>>>>>>>>>>>>>>>>>>> classical load >>>>>>>>>>>>>>>>>>>>> balancer on the network level. Normal HTTP redirect will not force >>>>>>>>>>>>>>>>>>>>> you to mess >>>>>>>>>>>>>>>>>>>>> with certs and keytabs. >>>>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>>>>> Petr^2 Spacek >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>> Petr Spacek @ Red Hat >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>> 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. >>>>>>>>>>>>> >>>>>>>>>>>>> -- >>>>>>>>>>>>> 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 andrew.holway at gmail.com Thu Mar 26 09:49:22 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Thu, 26 Mar 2015 10:49:22 +0100 Subject: [Freeipa-users] Is systemd really a requirement for freeipa 4.x? In-Reply-To: <55134AE3.7090209@redhat.com> References: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> <5512F334.5050000@redhat.com> <55134AE3.7090209@redhat.com> Message-ID: > > When I look at the SPEC file for freeipa-4.1.3, I see requirements >>> around Systemd. Is that really a hard requirement, or is it possible to >>> run newer FreeIPA (that is to say 4.x) on a host that hasn't been >>> infested by systemd >> >> >From an SELinux standpoint systemd is far superior to initd as it allows far more graceful domain transitions. Apart from the binary logging and it being a bit monolithic; I really don't understand the anit-systemd crowd problems. Its advantages over the now ancient initd seem to be obvious. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Thu Mar 26 09:56:38 2015 From: pspacek at redhat.com (Petr Spacek) Date: Thu, 26 Mar 2015 10:56:38 +0100 Subject: [Freeipa-users] bind-dyndb-ldap vs DLZ In-Reply-To: <551351F8.5070508@lundman.net> References: <55122F5F.8030505@lundman.net> <55126655.30109@redhat.com> <551351F8.5070508@lundman.net> Message-ID: <5513D7D6.7070408@redhat.com> Hello Jorgen and list, On 26.3.2015 01:25, Jorgen Lundman wrote: > Thanks for your email, (I have included the ML in this reply) > > We run Solaris with bind+DLZ+ldap on the DNS servers, and are looking at > better performance. Which means evaluating bind-dyndb-ldap. I did some > minor tweaks to compile bind-dyndb on Solaris. Perfect! I can merge your changes upstream if you send me a patch with your changes. It would make your life easier later when you need to pick new code. > Since we already have large systems running in production, with > provisioning, and support tools, it is unlikely we would change the schema. > It would probably be less work for me to fork bind-dyndb and massage it > into handling DLZ schema directly. Hmm, that might be a challenge. bind-dyndb-ldap code implicitly assumes that there is 1:1 mapping between DNS name<->LDAP DN. This makes implementation of dynamic updates much easier. Anyway, please be so kind and send your patches to us too. It is well possible that some chunks will be applicable to bind-dyndb-ldap too. Hopefully this approach would improve code quality upstream and at the same time allow you to maintain minimal patch set and pull new code from upstream often and with minimal pain. BTW there is outstanding patch set which touches record-parsing logic: https://github.com/pspacek/bind-dyndb-ldap/tree/unknown_record_types It is not a final version yet but it might be a good idea to base your patches on that to save some patch rebasing. > But before that, we are just evaluating bind-dyndb to decide if it fits > with our systems. > > I loaded the 300k zones we have in DLZ-LDAP, into bind-dyndb schema (Just > SOA records with a single ARecord). > > [1] > The first issue is that to start named takes about 50 mins. This is a bit > of an issue as there is no resolving while it is starting. This seems to be It is expected that bind-dyndb-ldap does not serve anything until whole zone is loaded: Basically the driver downloads all data from LDAP and feeds the data into BIND's RBTDB implementation. This is the reason why it has read performance on nearly same level as plain BIND but it also adds the same limitations - all the zone data have to be in memory before the zone can be loaded. (Also, the driver supports DNSSEC in-line signing and it does not make sense to sign the zone before it is fully loaded.) Unfortunately there is no way to detect that one zone is fully loaded because SyncRepl is running on the whole dns sub-tree so we have to wait until initial synchronization is done. > the same delay each time I start it. slapd is running on localhost, and is > otherwise idle. Hmm, that stinks! I would be happy to look into it if you can provide me with output from a profiler of your choice. (It might be a good idea to profile bind-dyndb-ldap together with whole named process to see all the interactions.) > It is just a large syncrepl for 300k records, always > starting from epoch... This is a limitation of current implementation and it can be fixed, see below. > [2] > Is it supposed to be able to use the "dump-file" on exit for faster loads? Yes, something like that is planned but not implemented yet. You are basically interested in resolving following two tickets: https://fedorahosted.org/bind-dyndb-ldap/ticket/124 https://fedorahosted.org/bind-dyndb-ldap/ticket/125 With these two in place it should be fairly easy to read all data from disk, start serving the zone and do synchronization with LDAP server in background. A pre-requisite for this are basically these: 1) Answering questions on https://fedorahosted.org/bind-dyndb-ldap/wiki/BIND9/Design/RBTDB#Filesystemcachemaintenance 2) Implementation of meta-database for LDAP UUID->DNS node mapping https://fedorahosted.org/bind-dyndb-ldap/ticket/151 Trac Report #3 shows currently planned work ordered by priority: https://fedorahosted.org/bind-dyndb-ldap/report/3 As you might see, the necessary meta-database is pretty high on the list (it should be done in ~ 1 month) but start-up performance has very low priority at the moment and is very unlikely to be ready in Fedora 22 time frame. If you want to get better start-up performace earlier I would suggest you to work with us on it. Patches are more than welcome! :-) We can provide you guidance but currently we do not have capacity to implement it ourselves in near future, sorry! > Perhaps I broke something while porting it to Solaris. I see it create No you did not, it is not implemented yet :-) > directories for each zone, only to create an empty "keys" directory. In > addition to that, having 300k entries in one directory might need hashing. > ZFS is ok with it, but it tends to slow down. > > However, once it is loaded, it is much faster than DLZ+LDAP. Previous > system would see about 300qps. (All zones, plus > /usr/share/dict/words+".com" with dnsperf) > > bind-dyndb gave the same benchmarking test 18796qps. > > Now, interestingly, I can also define a DLZ+LDAP line in named.conf after > the bind-dyndb. This has the effect that while bind-dyndb is taking 50 mins > to start up, it will resolve names using DLZ+LDAP. Sure, at the worse qps > of course, but it is at least resolving. > > [3] > However, that has a side-effect that, once bind-dyndb is loaded, it will > also query DLZ+LDAP on negative entries. Thus decreasing the performance to > 3884qps. Wonder if there is a way to have bind-dyndb ignore DLZ+LDAP /once > it has loaded/. Wow, I'm surprised that this combination actually works! I expect that there will be some nasty surprises in there, especially when it comes to dynamic updates. > That is our current situation. > > Sincerely, > > Lund > > ps. There are some minor faults in the example.ldif, like > "idnsName=example.com"'s idnsName is "ipatest.com". And is missing NSRecord. Oh, thank you for catching this! It is now fixed in master branch: https://git.fedorahosted.org/cgit/bind-dyndb-ldap.git/commit/?id=0bf04034675c55178c7dd885e9cdfadd33ba441b Petr^2 Spacek > Petr Spacek wrote: >> On 25.3.2015 04:45, Jorgen Lundman wrote: >>> >>> Hey Petr, >>> >>> Your name came up on the DLZ list a while back and I was interested in >>> bind-dyndb-ldap. We run DLZ-LDAP here, and after this weeks DDOS >>> firefighting we are looking at increasing our qps. >>> >>> At the moment, each BIND-DLZ-LDAP server can do about 200qps, which is >>> pretty low. But for authoritative it has been sufficient until now. I have >>> fixed DLZ-LDAP, enabling MULTITHREADED (it is off by default for some >>> reason) but still, it has to query the DB each time. The thing refuses to >>> use more than 130MB of cache, each server has 32GB so that is a bit >>> annoying. :) >>> >>> Biggest issue with bind-dyndb-ldap is the schema difference to DLZ's >>> schema. Most items can probably be handled with straight keyword rename, >>> but one of the larger differences is that bind-dyndb-ldap handles multiple >>> "ARecord" for one entry, whereas DLZ uses that odd "A1,DNSHostName=foo" and >>> "A2,DNSHostName=foo" to do multiples. >>> >>> Do you know if anyone has already looked at DLZ to bind-dyndb-ldap >>> migration? I suppose as a test case (to see what qps I can get), I can >>> convert the DLZ LDAP into zone files, then back to bind-dyndb-ldap schema >>> using your supplied scripts. >>> >>> If you have time, drop me a line. >> >> Hello! >> >> As far as I know there is no DLZ->bind-dyndb-ldap convertor. >> >> I would say that an easiest way is to do AXFR from DLZ-backed zone, save it to >> a file and feed the zone file into >> https://github.com/pspacek/zone2dyndb-ldif >> >> IMHO it is not worth to develop special DLZ->bind-dyndb-ldap convertor because >> we can always use zone file format as intermediate step. >> >> LDAP schema used by bind-dyndb-ldap is described on: >> https://fedorahosted.org/bind-dyndb-ldap/wiki/LDAPSchema >> >> >> If you have any further questions please contact freeipa-users at redhat.com >> mailing list so everyone including search engines can see it :-) >> >> Thank you for understanding and have a nice day! >> > -- Petr^2 Spacek From yks0000 at gmail.com Thu Mar 26 10:12:14 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Thu, 26 Mar 2015 15:42:14 +0530 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server Message-ID: Hi, We are getting error while trying to ssh using users created in IPA server. root at yogesh-ubuntu-pc:~# ssh -vvv cm8158 at 52.74.84.94 OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 debug1: Reading configuration data /etc/ssh/ssh_config debug1: /etc/ssh/ssh_config line 19: Applying options for * debug2: ssh_connect: needpriv 0 debug1: Connecting to 52.74.84.94 [52.74.84.94] port 22. debug1: Connection established. debug1: permanently_set_uid: 0/0 debug3: Incorrect RSA1 identifier debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key debug1: identity file /root/.ssh/id_rsa type 1 debug1: identity file /root/.ssh/id_rsa-cert type -1 debug1: identity file /root/.ssh/id_dsa type -1 debug1: identity file /root/.ssh/id_dsa-cert type -1 debug1: identity file /root/.ssh/id_ecdsa type -1 debug1: identity file /root/.ssh/id_ecdsa-cert type -1 debug1: identity file /root/.ssh/id_ed25519 type -1 debug1: identity file /root/.ssh/id_ed25519-cert type -1 debug1: Enabling compatibility mode for protocol 2.0 debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 debug2: fd 3 setting O_NONBLOCK debug3: load_hostkeys: loading entries for host "52.74.84.94" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:89 debug3: load_hostkeys: loaded 1 keys debug3: order_hostkeyalgs: prefer hostkeyalgs: ssh-rsa-cert-v01 at openssh.com, ssh-rsa-cert-v00 at openssh.com,ssh-rsa debug1: SSH2_MSG_KEXINIT sent debug1: SSH2_MSG_KEXINIT received debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com, ssh-rsa-cert-v00 at openssh.com,ssh-rsa, ecdsa-sha2-nistp256-cert-v01 at openssh.com, ecdsa-sha2-nistp384-cert-v01 at openssh.com, ecdsa-sha2-nistp521-cert-v01 at openssh.com,ssh-ed25519-cert-v01 at openssh.com, ssh-dss-cert-v01 at openssh.com,ssh-dss-cert-v00 at openssh.com ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128, aes128-gcm at openssh.com,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com, hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com,umac-128-etm at openssh.com, hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com, hmac-md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com, umac-128 at openssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160, hmac-ripemd160 at openssh.com,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: none,zlib at openssh.com,zlib debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 debug2: kex_parse_kexinit: ssh-rsa,ssh-dss debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour, rijndael-cbc at lysator.liu.se debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com ,hmac-sha1-96,hmac-md5-96 debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: none,zlib at openssh.com debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: debug2: kex_parse_kexinit: first_kex_follows 0 debug2: kex_parse_kexinit: reserved 0 debug2: mac_setup: setup hmac-md5 debug1: kex: server->client aes128-ctr hmac-md5 none debug2: mac_setup: setup hmac-md5 debug1: kex: client->server aes128-ctr hmac-md5 none debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP debug2: bits set: 1584/3072 debug1: SSH2_MSG_KEX_DH_GEX_INIT sent debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY debug1: Server host key: RSA 05:d1:fd:ee:1a:64:fd:6b:ec:a5:ac:66:34:6f:61:e7 debug3: load_hostkeys: loading entries for host "52.74.84.94" from file "/root/.ssh/known_hosts" debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:89 debug3: load_hostkeys: loaded 1 keys debug1: Host '52.74.84.94' is known and matches the RSA host key. debug1: Found key in /root/.ssh/known_hosts:89 debug2: bits set: 1540/3072 debug1: ssh_rsa_verify: signature correct debug2: kex_derive_keys debug2: set_newkeys: mode 1 debug1: SSH2_MSG_NEWKEYS sent debug1: expecting SSH2_MSG_NEWKEYS debug2: set_newkeys: mode 0 debug1: SSH2_MSG_NEWKEYS received debug1: Roaming not allowed by server debug1: SSH2_MSG_SERVICE_REQUEST sent debug2: service_accept: ssh-userauth debug1: SSH2_MSG_SERVICE_ACCEPT received debug2: key: /root/.ssh/id_rsa (0x7f5d62f2cd10), debug2: key: /root/.ssh/id_dsa ((nil)), debug2: key: /root/.ssh/id_ecdsa ((nil)), debug2: key: /root/.ssh/id_ed25519 ((nil)), debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug3: start over, passed a different list publickey,gssapi-keyex,gssapi-with-mic debug3: preferred gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_lookup gssapi-keyex debug3: remaining preferred: gssapi-with-mic,publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-keyex debug1: Next authentication method: gssapi-keyex debug1: No valid Key exchange context debug2: we did not send a packet, disable method debug3: authmethod_lookup gssapi-with-mic debug3: remaining preferred: publickey,keyboard-interactive,password debug3: authmethod_is_enabled gssapi-with-mic debug1: Next authentication method: gssapi-with-mic debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug1: Unspecified GSS failure. Minor code may provide more information debug1: Unspecified GSS failure. Minor code may provide more information No Kerberos credentials available debug2: we did not send a packet, disable method debug3: authmethod_lookup publickey debug3: remaining preferred: keyboard-interactive,password debug3: authmethod_is_enabled publickey debug1: Next authentication method: publickey debug1: Offering RSA public key: /root/.ssh/id_rsa debug3: send_pubkey_test debug2: we sent a publickey packet, wait for reply debug1: Authentications that can continue: publickey,gssapi-keyex,gssapi-with-mic debug1: Trying private key: /root/.ssh/id_dsa debug3: no such identity: /root/.ssh/id_dsa: No such file or directory debug1: Trying private key: /root/.ssh/id_ecdsa debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory debug1: Trying private key: /root/.ssh/id_ed25519 debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory debug2: we did not send a packet, disable method debug1: No more authentication methods to try. Permission denied (publickey,gssapi-keyex,gssapi-with-mic). Below is the audit.log type=CRYPTO_KEY_USER msg=audit(1427364618.180:2624): user pid=11570 uid=0 auid=500 ses=328 msg='op=destroy kind=server fp=05:d1:fd:ee:1a:64:fd:6b:ec:a5:ac:66:34:6f:61:e7 direction=? spid=11570 suid=0 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1427364618.181:2625): user pid=11570 uid=0 auid=500 ses=328 msg='op=destroy kind=server fp=91:ae:3f:fc:6e:5e:ec:76:8f:00:50:ee:c0:1d:c4:dc direction=? spid=11570 suid=0 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' type=CRYPTO_SESSION msg=audit(1427364618.261:2626): user pid=11569 uid=0 auid=500 ses=328 msg='op=start direction=from-client cipher=aes128-ctr ksize=128 spid=11570 suid=74 rport=50263 laddr=20.0.0.159 lport=22 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' type=CRYPTO_SESSION msg=audit(1427364618.261:2627): user pid=11569 uid=0 auid=500 ses=328 msg='op=start direction=from-server cipher=aes128-ctr ksize=128 spid=11570 suid=74 rport=50263 laddr=20.0.0.159 lport=22 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' type=USER_AUTH msg=audit(1427364618.913:2628): user pid=11569 uid=0 auid=500 ses=328 msg='op=pubkey acct="cm8158" exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=ssh res=failed' type=CRYPTO_KEY_USER msg=audit(1427364618.993:2629): user pid=11569 uid=0 auid=500 ses=328 msg='op=destroy kind=session fp=? direction=both spid=11570 suid=74 rport=50263 laddr=20.0.0.159 lport=22 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' type=USER_ERR msg=audit(1427364618.993:2630): user pid=11569 uid=0 auid=500 ses=328 msg='op=PAM:bad_ident acct="?" exe="/usr/sbin/sshd" hostname=61.16.237.50 addr=61.16.237.50 terminal=ssh res=failed' type=CRYPTO_KEY_USER msg=audit(1427364618.993:2631): user pid=11569 uid=0 auid=500 ses=328 msg='op=destroy kind=server fp=05:d1:fd:ee:1a:64:fd:6b:ec:a5:ac:66:34:6f:61:e7 direction=? spid=11569 suid=0 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' type=CRYPTO_KEY_USER msg=audit(1427364618.993:2632): user pid=11569 uid=0 auid=500 ses=328 msg='op=destroy kind=server fp=91:ae:3f:fc:6e:5e:ec:76:8f:00:50:ee:c0:1d:c4:dc direction=? spid=11569 suid=0 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' type=USER_LOGIN msg=audit(1427364618.994:2633): user pid=11569 uid=0 auid=500 ses=328 msg='op=login acct="cm8158" exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=ssh res=failed' Secure log: Mar 26 10:11:58 ldap-inf-stg-sg1-01 sshd[11575]: reverse mapping checking getaddrinfo for del-static-50-237-16-61.direct.net.in [61.16.237.50] failed - POSSIBLE BREAK-IN ATTEMPT! Mar 26 10:11:58 ldap-inf-stg-sg1-01 sshd[11576]: Connection closed by 61.16.237.50 *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] -------------- next part -------------- An HTML attachment was scrubbed... URL: From coy.hile at coyhile.com Thu Mar 26 12:18:38 2015 From: coy.hile at coyhile.com (Coy Hile) Date: Thu, 26 Mar 2015 12:18:38 +0000 Subject: [Freeipa-users] Is systemd really a requirement for freeipa 4.x? In-Reply-To: References: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> <5512F334.5050000@redhat.com> <55134AE3.7090209@redhat.com> Message-ID: <20150326121838.Horde.8fNc4Ax9Ajb_IlzaIINjGQ1@webmail01.coyhile.com> Quoting Andrew Holway : >> >> When I look at the SPEC file for freeipa-4.1.3, I see requirements >>>> around Systemd. Is that really a hard requirement, or is it possible to >>>> run newer FreeIPA (that is to say 4.x) on a host that hasn't been >>>> infested by systemd >>> >>> >> From an SELinux standpoint systemd is far superior to initd as it allows > far more graceful domain transitions. > > Apart from the binary logging and it being a bit monolithic; I really don't > understand the anit-systemd crowd problems. Its advantages over the now > ancient initd seem to be obvious. The binary logging is a big problem. Log to the filesystem usefully, or log to syslog. Then one can get that data into Splunk or similar. Aside from that, systemd feels like the answer to the question no one asked. It's a bit like what Oracle has done to bastardize smf(5) in Oracle Solaris 11 over what was there in Solaris 10 (and the former OpenSolaris, now illumos). The S10 incarnation was awesome, even though the definition of service manifests in xml makes me want to claw my eyes out. Oracle's Microsoftened embrace and extend? Yeah, not so much.... For full disclosure here, the reason I was enquiring about support on CentOS 6 is because my virtualization platform of choice is SmartOS. For CentOS 6 and Ubuntu 14.04, I am able to use a 'Branded zone' natively without having to add the KVM hardware emulation layer in there, implying better network and IO performance. That said, for this particular case, the KVM overhead really doesn't matter since a box that's only doing LDAP and kerb really needn't be all that beefy. Hell, I could probably run an authoritative KDC for ATHENA.MIT.EDU on an rpi if I were so inclined. Understanding the reason behind the requirements is quite helpful, so thanks to all who provided that. I'll work with Joyent to add systemd support to the lx brand, and in the meantime, I'll just deploy on KVM infrastructure and take the hit. I assume there's no good reason to deploy a net new setup using the 3.x release? -c -- Coy Hile coy.hile at coyhile.com From jpazdziora at redhat.com Thu Mar 26 12:23:02 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Thu, 26 Mar 2015 13:23:02 +0100 Subject: [Freeipa-users] Is systemd really a requirement for freeipa 4.x? In-Reply-To: References: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> <5512F334.5050000@redhat.com> <55134AE3.7090209@redhat.com> Message-ID: <20150326122302.GB958@redhat.com> On Thu, Mar 26, 2015 at 10:49:22AM +0100, Andrew Holway wrote: > > From an SELinux standpoint systemd is far superior to initd as it allows > far more graceful domain transitions. Have you got a link which would demonstrate how systemd helps with domain transitions? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From simo at redhat.com Thu Mar 26 13:36:08 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 26 Mar 2015 09:36:08 -0400 Subject: [Freeipa-users] Is systemd really a requirement for freeipa 4.x? In-Reply-To: <20150326122302.GB958@redhat.com> References: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> <5512F334.5050000@redhat.com> <55134AE3.7090209@redhat.com> <20150326122302.GB958@redhat.com> Message-ID: <1427376968.8302.76.camel@willson.usersys.redhat.com> On Thu, 2015-03-26 at 13:23 +0100, Jan Pazdziora wrote: > On Thu, Mar 26, 2015 at 10:49:22AM +0100, Andrew Holway wrote: > > > > From an SELinux standpoint systemd is far superior to initd as it allows > > far more graceful domain transitions. > > Have you got a link which would demonstrate how systemd helps > with domain transitions? Hi everyone, before answering to the technical question I would like to ask that people refrain from comments on how good/bad systemd is, it is an inflammatory topic and people has really discussed it to no end all over the internet. I do not think we need to make camps here. Now on the SELinux thing, the init system (any init system) can transition easily to any domain it wants as it is the first process and it is explicitly given that permission by policy. The way systemd works when you run a unit file is that systemctl communicates to the init system commanding it to styart a specific unit file, then the init system does it setting up the appropriate SELinux context for the process. This is always consistent as calling systemctl is the only way to run a unit file. With the old sysV system (on Fedora/RHEL), instead the admin (root usually) had at least 2 ways of starting an init script. 1) use the service command 2) run the script directly Now if (1) was used then the service command could do a transition to the initd_t domain first and then be allowed to transition the script it would launch to the appropriate domain (just like init would do at boot). However if the admin directly executed the script instead of using the service command then this would not happen because there are no transition rules when root runs stuff directly. Root happens to have the unconfined_t role and so whatever it executes directly, normally, will inherit the same, which means unfettered access to most of the system. In turn this means the program may create files which also also marked unconfined_t (or other label not normally available to the program). Upon reboot (or proper restart via service file) the program would go back to start with the correct policy and find itself with no access to those files due to mismatching label (or behave differently due to different access to config files and the like). This was often the cause of hate by admins that do not understand the mechanics and nuances involved in using SELinux. HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Mar 26 13:39:56 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Mar 2015 09:39:56 -0400 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: Message-ID: <55140C2C.7080009@redhat.com> Yogesh Sharma wrote: > Hi, > > We are getting error while trying to ssh using users created in IPA server. > > root at yogesh-ubuntu-pc:~# ssh -vvv cm8158 at 52.74.84.94 You don't have a Kerberos ticket and you don't have ssh keys for this user. kinit cm8158 first or get the ssh keys. You'll need to use the FQDN of the host as well, rather than th IP address, if using Kerberos. rob > > OpenSSH_6.6.1, OpenSSL 1.0.1f 6 Jan 2014 > debug1: Reading configuration data /etc/ssh/ssh_config > debug1: /etc/ssh/ssh_config line 19: Applying options for * > debug2: ssh_connect: needpriv 0 > debug1: Connecting to 52.74.84.94 [52.74.84.94] port 22. > debug1: Connection established. > debug1: permanently_set_uid: 0/0 > debug3: Incorrect RSA1 identifier > debug3: Could not load "/root/.ssh/id_rsa" as a RSA1 public key > debug1: identity file /root/.ssh/id_rsa type 1 > debug1: identity file /root/.ssh/id_rsa-cert type -1 > debug1: identity file /root/.ssh/id_dsa type -1 > debug1: identity file /root/.ssh/id_dsa-cert type -1 > debug1: identity file /root/.ssh/id_ecdsa type -1 > debug1: identity file /root/.ssh/id_ecdsa-cert type -1 > debug1: identity file /root/.ssh/id_ed25519 type -1 > debug1: identity file /root/.ssh/id_ed25519-cert type -1 > debug1: Enabling compatibility mode for protocol 2.0 > debug1: Local version string SSH-2.0-OpenSSH_6.6.1p1 Ubuntu-2ubuntu2 > debug1: Remote protocol version 2.0, remote software version OpenSSH_5.3 > debug1: match: OpenSSH_5.3 pat OpenSSH_5* compat 0x0c000000 > debug2: fd 3 setting O_NONBLOCK > debug3: load_hostkeys: loading entries for host "52.74.84.94" from file > "/root/.ssh/known_hosts" > debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:89 > debug3: load_hostkeys: loaded 1 keys > debug3: order_hostkeyalgs: prefer hostkeyalgs: > ssh-rsa-cert-v01 at openssh.com > ,ssh-rsa-cert-v00 at openssh.com > ,ssh-rsa > debug1: SSH2_MSG_KEXINIT sent > debug1: SSH2_MSG_KEXINIT received > debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org > ,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa-cert-v01 at openssh.com > ,ssh-rsa-cert-v00 at openssh.com > ,ssh-rsa,ecdsa-sha2-nistp256-cert-v01 at openssh.com > ,ecdsa-sha2-nistp384-cert-v01 at openssh.com > ,ecdsa-sha2-nistp521-cert-v01 at openssh.com > ,ssh-ed25519-cert-v01 at openssh.com > ,ssh-dss-cert-v01 at openssh.com > ,ssh-dss-cert-v00 at openssh.com > ,ecdsa-sha2-nistp256,ecdsa-sha2-nistp384,ecdsa-sha2-nistp521,ssh-ed25519,ssh-dss > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com > ,aes256-gcm at openssh.com > ,chacha20-poly1305 at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.com > ,aes256-gcm at openssh.com > ,chacha20-poly1305 at openssh.com > ,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com > ,hmac-sha1-etm at openssh.com > ,umac-64-etm at openssh.com > ,umac-128-etm at openssh.com > ,hmac-sha2-256-etm at openssh.com > ,hmac-sha2-512-etm at openssh.com > ,hmac-ripemd160-etm at openssh.com > ,hmac-sha1-96-etm at openssh.com > ,hmac-md5-96-etm at openssh.com > ,hmac-md5,hmac-sha1,umac-64 at openssh.com > ,umac-128 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > ,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com > ,hmac-sha1-etm at openssh.com > ,umac-64-etm at openssh.com > ,umac-128-etm at openssh.com > ,hmac-sha2-256-etm at openssh.com > ,hmac-sha2-512-etm at openssh.com > ,hmac-ripemd160-etm at openssh.com > ,hmac-sha1-96-etm at openssh.com > ,hmac-md5-96-etm at openssh.com > ,hmac-md5,hmac-sha1,umac-64 at openssh.com > ,umac-128 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > ,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > ,zlib > debug2: kex_parse_kexinit: none,zlib at openssh.com > ,zlib > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 > debug2: kex_parse_kexinit: ssh-rsa,ssh-dss > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > > debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > ,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: hmac-md5,hmac-sha1,umac-64 at openssh.com > ,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com > ,hmac-sha1-96,hmac-md5-96 > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: none,zlib at openssh.com > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: > debug2: kex_parse_kexinit: first_kex_follows 0 > debug2: kex_parse_kexinit: reserved 0 > debug2: mac_setup: setup hmac-md5 > debug1: kex: server->client aes128-ctr hmac-md5 none > debug2: mac_setup: setup hmac-md5 > debug1: kex: client->server aes128-ctr hmac-md5 none > debug1: SSH2_MSG_KEX_DH_GEX_REQUEST(1024<3072<8192) sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_GROUP > debug2: bits set: 1584/3072 > debug1: SSH2_MSG_KEX_DH_GEX_INIT sent > debug1: expecting SSH2_MSG_KEX_DH_GEX_REPLY > debug1: Server host key: RSA 05:d1:fd:ee:1a:64:fd:6b:ec:a5:ac:66:34:6f:61:e7 > debug3: load_hostkeys: loading entries for host "52.74.84.94" from file > "/root/.ssh/known_hosts" > debug3: load_hostkeys: found key type RSA in file /root/.ssh/known_hosts:89 > debug3: load_hostkeys: loaded 1 keys > debug1: Host '52.74.84.94' is known and matches the RSA host key. > debug1: Found key in /root/.ssh/known_hosts:89 > debug2: bits set: 1540/3072 > debug1: ssh_rsa_verify: signature correct > debug2: kex_derive_keys > debug2: set_newkeys: mode 1 > debug1: SSH2_MSG_NEWKEYS sent > debug1: expecting SSH2_MSG_NEWKEYS > debug2: set_newkeys: mode 0 > debug1: SSH2_MSG_NEWKEYS received > debug1: Roaming not allowed by server > debug1: SSH2_MSG_SERVICE_REQUEST sent > debug2: service_accept: ssh-userauth > debug1: SSH2_MSG_SERVICE_ACCEPT received > debug2: key: /root/.ssh/id_rsa (0x7f5d62f2cd10), > debug2: key: /root/.ssh/id_dsa ((nil)), > debug2: key: /root/.ssh/id_ecdsa ((nil)), > debug2: key: /root/.ssh/id_ed25519 ((nil)), > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug3: start over, passed a different list > publickey,gssapi-keyex,gssapi-with-mic > debug3: preferred > gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_lookup gssapi-keyex > debug3: remaining preferred: > gssapi-with-mic,publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi-keyex > debug1: Next authentication method: gssapi-keyex > debug1: No valid Key exchange context > debug2: we did not send a packet, disable method > debug3: authmethod_lookup gssapi-with-mic > debug3: remaining preferred: publickey,keyboard-interactive,password > debug3: authmethod_is_enabled gssapi-with-mic > debug1: Next authentication method: gssapi-with-mic > debug1: Unspecified GSS failure. Minor code may provide more information > No Kerberos credentials available > > debug1: Unspecified GSS failure. Minor code may provide more information > No Kerberos credentials available > > debug1: Unspecified GSS failure. Minor code may provide more information > > > debug1: Unspecified GSS failure. Minor code may provide more information > No Kerberos credentials available > > debug2: we did not send a packet, disable method > debug3: authmethod_lookup publickey > debug3: remaining preferred: keyboard-interactive,password > debug3: authmethod_is_enabled publickey > debug1: Next authentication method: publickey > debug1: Offering RSA public key: /root/.ssh/id_rsa > debug3: send_pubkey_test > debug2: we sent a publickey packet, wait for reply > debug1: Authentications that can continue: > publickey,gssapi-keyex,gssapi-with-mic > debug1: Trying private key: /root/.ssh/id_dsa > debug3: no such identity: /root/.ssh/id_dsa: No such file or directory > debug1: Trying private key: /root/.ssh/id_ecdsa > debug3: no such identity: /root/.ssh/id_ecdsa: No such file or directory > debug1: Trying private key: /root/.ssh/id_ed25519 > debug3: no such identity: /root/.ssh/id_ed25519: No such file or directory > debug2: we did not send a packet, disable method > debug1: No more authentication methods to try. > Permission denied (publickey,gssapi-keyex,gssapi-with-mic). > > > > > Below is the audit.log > > type=CRYPTO_KEY_USER msg=audit(1427364618.180:2624): user pid=11570 > uid=0 auid=500 ses=328 msg='op=destroy kind=server > fp=05:d1:fd:ee:1a:64:fd:6b:ec:a5:ac:66:34:6f:61:e7 direction=? > spid=11570 suid=0 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 > terminal=? res=success' > type=CRYPTO_KEY_USER msg=audit(1427364618.181:2625): user pid=11570 > uid=0 auid=500 ses=328 msg='op=destroy kind=server > fp=91:ae:3f:fc:6e:5e:ec:76:8f:00:50:ee:c0:1d:c4:dc direction=? > spid=11570 suid=0 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 > terminal=? res=success' > type=CRYPTO_SESSION msg=audit(1427364618.261:2626): user pid=11569 uid=0 > auid=500 ses=328 msg='op=start direction=from-client cipher=aes128-ctr > ksize=128 spid=11570 suid=74 rport=50263 laddr=20.0.0.159 lport=22 > exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' > type=CRYPTO_SESSION msg=audit(1427364618.261:2627): user pid=11569 uid=0 > auid=500 ses=328 msg='op=start direction=from-server cipher=aes128-ctr > ksize=128 spid=11570 suid=74 rport=50263 laddr=20.0.0.159 lport=22 > exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' > type=USER_AUTH msg=audit(1427364618.913:2628): user pid=11569 uid=0 > auid=500 ses=328 msg='op=pubkey acct="cm8158" exe="/usr/sbin/sshd" > hostname=? addr=61.16.237.50 terminal=ssh res=failed' > type=CRYPTO_KEY_USER msg=audit(1427364618.993:2629): user pid=11569 > uid=0 auid=500 ses=328 msg='op=destroy kind=session fp=? direction=both > spid=11570 suid=74 rport=50263 laddr=20.0.0.159 lport=22 > exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 terminal=? res=success' > type=USER_ERR msg=audit(1427364618.993:2630): user pid=11569 uid=0 > auid=500 ses=328 msg='op=PAM:bad_ident acct="?" exe="/usr/sbin/sshd" > hostname=61.16.237.50 addr=61.16.237.50 terminal=ssh res=failed' > type=CRYPTO_KEY_USER msg=audit(1427364618.993:2631): user pid=11569 > uid=0 auid=500 ses=328 msg='op=destroy kind=server > fp=05:d1:fd:ee:1a:64:fd:6b:ec:a5:ac:66:34:6f:61:e7 direction=? > spid=11569 suid=0 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 > terminal=? res=success' > type=CRYPTO_KEY_USER msg=audit(1427364618.993:2632): user pid=11569 > uid=0 auid=500 ses=328 msg='op=destroy kind=server > fp=91:ae:3f:fc:6e:5e:ec:76:8f:00:50:ee:c0:1d:c4:dc direction=? > spid=11569 suid=0 exe="/usr/sbin/sshd" hostname=? addr=61.16.237.50 > terminal=? res=success' > type=USER_LOGIN msg=audit(1427364618.994:2633): user pid=11569 uid=0 > auid=500 ses=328 msg='op=login acct="cm8158" exe="/usr/sbin/sshd" > hostname=? addr=61.16.237.50 terminal=ssh res=failed' > > > > Secure log: > > Mar 26 10:11:58 ldap-inf-stg-sg1-01 sshd[11575]: reverse mapping > checking getaddrinfo for del-static-50-237-16-61.direct.net.in > [61.16.237.50] failed - > POSSIBLE BREAK-IN ATTEMPT! > Mar 26 10:11:58 ldap-inf-stg-sg1-01 sshd[11576]: Connection closed by > 61.16.237.50 > > / > Best Regards, > __________________________________________ > / > /Yogesh Sharma > / > /Email: yks0000 at gmail.com | Web: www.initd.in > / > > RHCE, VCE-CIA, RackSpace Cloud U > My LinkedIn Profile > > > From simo at redhat.com Thu Mar 26 13:40:21 2015 From: simo at redhat.com (Simo Sorce) Date: Thu, 26 Mar 2015 09:40:21 -0400 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: Message-ID: <1427377221.8302.78.camel@willson.usersys.redhat.com> On Thu, 2015-03-26 at 15:42 +0530, Yogesh Sharma wrote: > Hi, > > We are getting error while trying to ssh using users created in IPA > server. > > root at yogesh-ubuntu-pc:~# ssh -vvv cm8158 at 52.74.84.94 You should use the machine's fully qualified name if you want to login using GSSAPI/Krb5, an IP address cannot be resolved to a proper key as keys are registerd into the KDC as host/machine.fully.qualified.name at REALM. It's the same thing as with HTTPS, the client need to know the "name" of the server in order to be able to properly communicate with it. Simo. -- Simo Sorce * Red Hat, Inc * New York From rcritten at redhat.com Thu Mar 26 13:50:26 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Mar 2015 09:50:26 -0400 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> Message-ID: <55140EA2.9060306@redhat.com> Matt . wrote: > When digging around I see this documentation: > > http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html > > I would except that server.example.com is not going to be accepted by > IPA when you visit the webgui like that ? These are SRV records for the ldap service. Think of it as discovery for who provides ldap service in the domain. It isn't something used by a web browser. I'm no DNS expert (by far) but this example looks a little wonky. I'd think it should be example.com and not server.example.com. But in any case it is irrelevant to a browser. rob From yamakasi.014 at gmail.com Thu Mar 26 14:01:29 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 26 Mar 2015 15:01:29 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <55140EA2.9060306@redhat.com> References: <54F9CAB4.9060808@redhat.com> <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> Message-ID: HI Rob, Yes something is wrong there I guess. But still, I actually need to add a SAN to the webserver cert, which is different I think than the services at least. So the question there is... how ? Cheers, Matt 2015-03-26 14:50 GMT+01:00 Rob Crittenden : > Matt . wrote: >> When digging around I see this documentation: >> >> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >> >> I would except that server.example.com is not going to be accepted by >> IPA when you visit the webgui like that ? > > These are SRV records for the ldap service. Think of it as discovery for > who provides ldap service in the domain. It isn't something used by a > web browser. > > I'm no DNS expert (by far) but this example looks a little wonky. I'd > think it should be example.com and not server.example.com. But in any > case it is irrelevant to a browser. > > rob > From yks0000 at gmail.com Thu Mar 26 14:12:06 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Thu, 26 Mar 2015 19:42:06 +0530 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: <1427377221.8302.78.camel@willson.usersys.redhat.com> References: <1427377221.8302.78.camel@willson.usersys.redhat.com> Message-ID: Thanks, but when I trying to use admin user (default user created by IPA), I am able to login. The issue is happening only with new users we are trying to create. === TEST user Login Logs: (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=test] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [] (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 13615 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [3][1][name=test] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [test at sd.int] (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 13615 (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got request with the following data (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): domain: sd.int (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): user: test (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): ruser: (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): authtok type: 1 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): cli_pid: 13615 (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [unpack_buffer] (0x0100): cmd [241] uid [1312800003] gid [1312800003] validate [true] enterprise principal [false] offline [false] UPN [test at SD.INT] (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1312800003_XXXXXX] keytab: [/etc/krb5.keytab] (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ dns-inf-stg-sg1-01.sd.int at SD.INT] (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging sd.int (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging nss (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging pam (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging pac (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service pam replied to ping (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service ssh replied to ping (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service pac replied to ping (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service nss replied to ping (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service sd.int replied to ping (Thu Mar 26 19:30:52 2015) [[sssd[krb5_child[13625]]]] [get_and_save_tgt] (0x0020): 981: [-1765328361][Password has expired] (Thu Mar 26 19:30:55 2015) [[sssd[krb5_child[13625]]]] [map_krb5_error] (0x0020): 1043: [-1765328360][Preauthentication failed] (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [child_sig_handler] (0x0100): child [13625] finished successfully. (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [ipa_get_migration_flag_done] (0x0100): Password migration is not enabled. (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 17, ) [Success] (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Sending result [17][sd.int] (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Sent result [17][sd.int] (Thu Mar 26 19:30:55 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [17][sd.int] (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging sd.int (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging nss (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging pam (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging pac (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service pam replied to ping (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service ssh replied to ping (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service pac replied to ping (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service nss replied to ping (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service sd.int replied to ping ADMIN User Logs: (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [admin at sd.int] (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 13644 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got request with the following data (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): domain: sd.int (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): user: admin (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): ruser: (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): authtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): priv: 1 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): cli_pid: 13644 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Sending result [0][sd.int] (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][sd.int] (Thu Mar 26 19:33:45 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Thu Mar 26 19:33:45 2015) [sssd[nss]] [nss_cmd_initgroups_search] (0x0100): Requesting info for [admin at sd.int] (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_cmd_setcred] (0x0100): entering pam_cmd_setcred (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_SETCRED (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 13648 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [admin at sd.int] (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_SETCRED (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 13648 (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got request with the following data (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): command: PAM_SETCRED (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): domain: sd.int (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): user: admin (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): service: sshd (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): tty: ssh (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): ruser: (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): authtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): newauthtok type: 0 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): priv: 0 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): cli_pid: 13648 (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Sending result [0][sd.int] (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][sd.int] (Thu Mar 26 19:33:46 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Thu Mar 26 19:33:46 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at sd.int] (Thu Mar 26 19:33:46 2015) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0100): Requesting info for [1312800000 at sd.int] (Thu Mar 26 19:33:46 2015) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0080): No matching domain found for [1312800000] ==== *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Thu, Mar 26, 2015 at 7:10 PM, Simo Sorce wrote: > On Thu, 2015-03-26 at 15:42 +0530, Yogesh Sharma wrote: > > Hi, > > > > We are getting error while trying to ssh using users created in IPA > > server. > > > > root at yogesh-ubuntu-pc:~# ssh -vvv cm8158 at 52.74.84.94 > > You should use the machine's fully qualified name if you want to login > using GSSAPI/Krb5, an IP address cannot be resolved to a proper key as > keys are registerd into the KDC as > host/machine.fully.qualified.name at REALM. > > It's the same thing as with HTTPS, the client need to know the "name" of > the server in order to be able to properly communicate with it. > > Simo. > > -- > Simo Sorce * Red Hat, Inc * New York > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Thu Mar 26 14:14:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Mar 2015 15:14:30 +0100 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> Message-ID: <55141446.4020906@redhat.com> Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have the keyutils dependency fixed anyway :-) Martin On 03/25/2015 06:59 PM, Anthony Lanni wrote: > keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I > reinstalled keyutils and then ran the ipa-server-install again, and this > time it completed without error. > > Thanks very much, Martin and Dmitri! > > thx > anthony > > On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek wrote: > >> On 03/25/2015 04:11 AM, Dmitri Pal wrote: >>> On 03/24/2015 09:17 PM, Anthony Lanni wrote: >>>> While running ipa-server-install, it's failing out at the end with an >> error >>>> regarding the client install on the server. This happens regardless of >> how I >>>> input the options, but here's the latest command: >>>> >>>> ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM >>>> -n example.com -p passwd1 -a >>>> passwd2 --hostname=ldap-server-01.example.com >>>> --forwarder=10.0.1.20 >>>> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d >>>> >>>> Runs through the entire setup and gives me this: >>>> >>>> [...] >>>> ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master >>>> --unattended --domain example.com --server >>>> ldap-server-01.example.com --realm >>>> EXAMPLE.COM --hostname ldap-server-01.example.com >>>> >>>> ipa : DEBUG stdout= >>>> >>>> ipa : DEBUG stderr=Hostname: ldap-server-01.example.com >>>> >>>> Realm: EXAMPLE.COM >>>> DNS Domain: example.com >>>> IPA Server: ldap-server-01.example.com < >> http://ldap-server-01.example.com> >>>> BaseDN: dc=example,dc=com >>>> New SSSD config will be created >>>> Configured /etc/sssd/sssd.conf >>>> Traceback (most recent call last): >>>> File "/usr/sbin/ipa-client-install", line 2377, in >>>> sys.exit(main()) >>>> File "/usr/sbin/ipa-client-install", line 2363, in main >>>> rval = install(options, env, fstore, statestore) >>>> File "/usr/sbin/ipa-client-install", line 2135, in install >>>> delete_persistent_client_session_data(host_principal) >>>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in >>>> delete_persistent_client_session_data >>>> kernel_keyring.del_key(keyname) >>>> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", >> line >>>> 99, in del_key >>>> real_key = get_real_key(key) >>>> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", >> line >>>> 45, in get_real_key >>>> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, >> key], >>>> raiseonerr=False) >>> >>> Is keyctl installed? Can you run it manually? >>> Any SELinux denials? >> >> You are likely hitting >> https://fedorahosted.org/freeipa/ticket/3808 >> >> Please try installing keyutils before running ipa-server-install. It is >> fixed >> in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: >> https://bugzilla.redhat.com/show_bug.cgi?id=1205660 >> >> 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 yks0000 at gmail.com Thu Mar 26 14:17:34 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Thu, 26 Mar 2015 19:47:34 +0530 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: <1427377221.8302.78.camel@willson.usersys.redhat.com> Message-ID: I have tried with FQDN of host also as registered, but error remain same: (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730]]]] [unpack_buffer] (0x0100): cmd [241] uid [1312800004] gid [1312800004] validate [true] enterprise principal [false] offline [false] UPN [test1 at SD.INT] (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1312800004_XXXXXX] keytab: [/etc/krb5.keytab] (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Thu Mar 26 19:43:01 2015) [[sssd[krb5_child[13730]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ dns-inf-stg-sg1-01.sd.int at SD.INT] (Thu Mar 26 19:43:02 2015) [[sssd[krb5_child[13730]]]] [get_and_save_tgt] (0x0020): 981: [-1765328361][Password has expired] (Thu Mar 26 19:43:06 2015) [[sssd[krb5_child[13730]]]] [map_krb5_error] (0x0020): 1043: [-1765328360][Preauthentication failed] (Thu Mar 26 19:43:06 2015) [sssd[be[sd.int]]] [child_sig_handler] (0x0100): child [13730] finished successfully. (Thu Mar 26 19:43:06 2015) [sssd[be[sd.int]]] [ipa_get_migration_flag_done] (0x0100): Password migration is not enabled. (Thu Mar 26 19:43:06 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 17, ) [Success] Once I manually initialize the user Ticket on IPA Server using kinit username, I am able to login with and without FQDN. [root at ldap-inf-stg-sg1-01 lib]# kinit test1 Password for test1 at SD.INT: Password expired. You must change it now. Enter new password: Enter it again: Password change rejected: Password is too short Password not changed.. Please try again. Enter new password: Enter it again: root at yogesh-ubuntu-pc:/home/yogesh# ssh test1 at dns-inf-stg-sg1-01.sd.int test1 at dns-inf-stg-sg1-01.sd.int's password: Last login: Thu Mar 26 19:45:36 2015 from 125.63.90.34 -sh-4.1$ logout Connection to dns-inf-stg-sg1-01.sd.int closed. root at yogesh-ubuntu-pc:/home/yogesh# ssh test1 at 52.74.84.94 test1 at 52.74.84.94's password: Last login: Thu Mar 26 19:45:55 2015 from 125.63.90.34 -sh-4.1$ *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Thu, Mar 26, 2015 at 7:42 PM, Yogesh Sharma wrote: > Thanks, but when I trying to use admin user (default user created by IPA), > I am able to login. The issue is happening only with new users we are > trying to create. > > > > === > TEST user Login Logs: > > (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_get_account_info] > (0x0100): Got request for [4097][1][name=test] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [test] from [] > (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [test] from [] > (Thu Mar 26 19:30:51 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): > entering pam_cmd_authenticate > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > PAM_AUTHENTICATE > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > not set > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > test > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > 125.63.90.34 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 1 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 13615 > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [acctinfo_callback] > (0x0100): Request processed. Returned 0,0,Success > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_get_account_info] > (0x0100): Got request for [3][1][name=test] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_check_user_search] (0x0100): > Requesting info for [test at sd.int] > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > PAM_AUTHENTICATE > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > sd.int > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > test > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > 125.63.90.34 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 1 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 13615 > (Thu Mar 26 19:30:51 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [acctinfo_callback] > (0x0100): Request processed. Returned 0,0,Success > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): > Got request with the following data > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > command: PAM_AUTHENTICATE > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > domain: sd.int > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > user: test > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > service: sshd > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > tty: ssh > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > ruser: > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > rhost: 125.63.90.34 > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > authtok type: 1 > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > priv: 1 > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > cli_pid: 13615 > (Thu Mar 26 19:30:51 2015) [sssd[be[sd.int]]] [fo_resolve_service_send] > (0x0100): Trying to resolve service 'IPA' > (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1312800003] gid [1312800003] validate [true] > enterprise principal [false] offline [false] UPN [test at SD.INT] > (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [unpack_buffer] > (0x0100): ccname: [FILE:/tmp/krb5cc_1312800003_XXXXXX] keytab: > [/etc/krb5.keytab] > (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Thu Mar 26 19:30:51 2015) [[sssd[krb5_child[13625]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ > dns-inf-stg-sg1-01.sd.int at SD.INT] > (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging > sd.int > (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging nss > (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging pam > (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh > (Thu Mar 26 19:30:52 2015) [sssd] [service_send_ping] (0x0100): Pinging pac > (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service pam > replied to ping > (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service ssh > replied to ping > (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service pac > replied to ping > (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service nss > replied to ping > (Thu Mar 26 19:30:52 2015) [sssd] [ping_check] (0x0100): Service sd.int > replied to ping > (Thu Mar 26 19:30:52 2015) [[sssd[krb5_child[13625]]]] [get_and_save_tgt] > (0x0020): 981: [-1765328361][Password has expired] > (Thu Mar 26 19:30:55 2015) [[sssd[krb5_child[13625]]]] [map_krb5_error] > (0x0020): 1043: [-1765328360][Preauthentication failed] > (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [child_sig_handler] > (0x0100): child [13625] finished successfully. > (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] > [ipa_get_migration_flag_done] (0x0100): Password migration is not enabled. > (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > (0x0100): Backend returned: (0, 17, ) [Success] > (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > (0x0100): Sending result [17][sd.int] > (Thu Mar 26 19:30:55 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > (0x0100): Sent result [17][sd.int] > (Thu Mar 26 19:30:55 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): > received: [17][sd.int] > (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging > sd.int > (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging nss > (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging pam > (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh > (Thu Mar 26 19:31:02 2015) [sssd] [service_send_ping] (0x0100): Pinging pac > (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service pam > replied to ping > (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service ssh > replied to ping > (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service pac > replied to ping > (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service nss > replied to ping > (Thu Mar 26 19:31:02 2015) [sssd] [ping_check] (0x0100): Service sd.int > replied to ping > > > > > > > > > ADMIN User Logs: > > > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_check_user_search] (0x0100): > Requesting info for [admin at sd.int] > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > PAM_OPEN_SESSION > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > sd.int > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > admin > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > 125.63.90.34 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 13644 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): > Got request with the following data > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > command: PAM_OPEN_SESSION > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > domain: sd.int > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > user: admin > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > service: sshd > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > tty: ssh > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > ruser: > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > rhost: 125.63.90.34 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > authtok type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > priv: 1 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > cli_pid: 13644 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): > Sending result [0][sd.int] > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): > received: [0][sd.int] > (Thu Mar 26 19:33:45 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [admin] from [] > (Thu Mar 26 19:33:45 2015) [sssd[nss]] [nss_cmd_initgroups_search] > (0x0100): Requesting info for [admin at sd.int] > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_cmd_setcred] (0x0100): > entering pam_cmd_setcred > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > PAM_SETCRED > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > not set > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > admin > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > 125.63.90.34 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 13648 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_check_user_search] (0x0100): > Requesting info for [admin at sd.int] > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > PAM_SETCRED > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > sd.int > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > admin > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > 125.63.90.34 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 13648 > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): > Got request with the following data > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > command: PAM_SETCRED > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > domain: sd.int > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > user: admin > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > service: sshd > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > tty: ssh > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > ruser: > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > rhost: 125.63.90.34 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > authtok type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > priv: 0 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > cli_pid: 13648 > (Thu Mar 26 19:33:45 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): > Sending result [0][sd.int] > (Thu Mar 26 19:33:45 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): > received: [0][sd.int] > (Thu Mar 26 19:33:46 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [admin] from [] > (Thu Mar 26 19:33:46 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [admin at sd.int] > (Thu Mar 26 19:33:46 2015) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0100): > Requesting info for [1312800000 at sd.int] > (Thu Mar 26 19:33:46 2015) [sssd[nss]] [nss_cmd_getgrgid_search] (0x0080): > No matching domain found for [1312800000] > > ==== > > > > > > > *Best Regards,__________________________________________* > > *Yogesh Sharma* > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Thu, Mar 26, 2015 at 7:10 PM, Simo Sorce wrote: > >> On Thu, 2015-03-26 at 15:42 +0530, Yogesh Sharma wrote: >> > Hi, >> > >> > We are getting error while trying to ssh using users created in IPA >> > server. >> > >> > root at yogesh-ubuntu-pc:~# ssh -vvv cm8158 at 52.74.84.94 >> >> You should use the machine's fully qualified name if you want to login >> using GSSAPI/Krb5, an IP address cannot be resolved to a proper key as >> keys are registerd into the KDC as >> host/machine.fully.qualified.name at REALM. >> >> It's the same thing as with HTTPS, the client need to know the "name" of >> the server in order to be able to properly communicate with it. >> >> Simo. >> >> -- >> Simo Sorce * Red Hat, Inc * New York >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Thu Mar 26 14:25:25 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Thu, 26 Mar 2015 15:25:25 +0100 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: <1427377221.8302.78.camel@willson.usersys.redhat.com> Message-ID: On Thu, Mar 26, 2015 at 3:12 PM, Yogesh Sharma wrote: > Thanks, but when I trying to use admin user (default user created by IPA), > I am able to login. The issue is happening only with new users we are > trying to create. > > (Thu Mar 26 19:30:52 2015) [[sssd[krb5_child[13625]]]] [get_and_save_tgt] > (0x0020): 981: [-1765328361][Password has expired] > (Thu Mar 26 19:30:55 2015) [[sssd[krb5_child[13625]]]] [map_krb5_error] > (0x0020): 1043: [-1765328360][Preauthentication failed] > password expired? -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Thu Mar 26 14:25:42 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 26 Mar 2015 15:25:42 +0100 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: <1427377221.8302.78.camel@willson.usersys.redhat.com> Message-ID: <20150326142542.GT30085@hendrix.arn.redhat.com> On Thu, Mar 26, 2015 at 07:47:34PM +0530, Yogesh Sharma wrote: > Once I manually initialize the user Ticket on IPA Server using kinit > username, I am able to login with and without FQDN. It's expected that IPA users are created with expired password. But SSSD should have prompted you for a password change if you logged in the first time you logged in with the expired password...as seen from the krb5_child.log, it got the correct response from the KDC.. From yks0000 at gmail.com Thu Mar 26 14:31:39 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Thu, 26 Mar 2015 20:01:39 +0530 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: <1427377221.8302.78.camel@willson.usersys.redhat.com> Message-ID: This message is coming as user is trying to login for first time. IPA Admin has set a password and when user try to login it will prompt to change. sssd log it as password expired. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Thu, Mar 26, 2015 at 7:55 PM, Natxo Asenjo wrote: > > > On Thu, Mar 26, 2015 at 3:12 PM, Yogesh Sharma wrote: > >> Thanks, but when I trying to use admin user (default user created by >> IPA), I am able to login. The issue is happening only with new users we are >> trying to create. >> >> (Thu Mar 26 19:30:52 2015) [[sssd[krb5_child[13625]]]] [get_and_save_tgt] >> (0x0020): 981: [-1765328361][Password has expired] >> (Thu Mar 26 19:30:55 2015) [[sssd[krb5_child[13625]]]] [map_krb5_error] >> (0x0020): 1043: [-1765328360][Preauthentication failed] >> > > password expired? > > -- > regards, > natxo > > -- > 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 yks0000 at gmail.com Thu Mar 26 14:35:03 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Thu, 26 Mar 2015 20:05:03 +0530 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: <20150326142542.GT30085@hendrix.arn.redhat.com> References: <1427377221.8302.78.camel@willson.usersys.redhat.com> <20150326142542.GT30085@hendrix.arn.redhat.com> Message-ID: Hi Jakub, SSSD prompted to change the password. After changing the password, when we try to ssh again using the new password, it failed. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Thu, Mar 26, 2015 at 7:55 PM, Jakub Hrozek wrote: > On Thu, Mar 26, 2015 at 07:47:34PM +0530, Yogesh Sharma wrote: > > Once I manually initialize the user Ticket on IPA Server using kinit > > username, I am able to login with and without FQDN. > > It's expected that IPA users are created with expired password. But SSSD > should have prompted you for a password change if you logged in the > first time you logged in with the expired password...as seen from the > krb5_child.log, it got the correct response from the KDC.. > > -- > 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 jhrozek at redhat.com Thu Mar 26 15:15:22 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Thu, 26 Mar 2015 16:15:22 +0100 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: <1427377221.8302.78.camel@willson.usersys.redhat.com> <20150326142542.GT30085@hendrix.arn.redhat.com> Message-ID: <20150326151522.GU30085@hendrix.arn.redhat.com> On Thu, Mar 26, 2015 at 08:05:03PM +0530, Yogesh Sharma wrote: > Hi Jakub, > > SSSD prompted to change the password. After changing the password, when we > try to ssh again using the new password, it failed. And what do the logs say then, with the new password? From guertin at middlebury.edu Thu Mar 26 15:24:06 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Thu, 26 Mar 2015 15:24:06 +0000 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <20150326082321.GI3550@p.redhat.com> References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> <1427298281.8302.62.camel@willson.usersys.redhat.com> <55134C60.3060505@redhat.com> <20150326082321.GI3550@p.redhat.com> Message-ID: >I would like to just clarify tis a bit. The support to lookup up secondary groups >(the group list the id command shows) for user which never authenticated >was added in 7.1/6.7. Thanks. This makes sense, and indeed with Client 1 I can indeed log in, and "id 'MIDD\juser'" shows all the groups again. However, logins to Client 2 (also running RHEL 6.6 and sssd 1.11.6) still fail, and "id 'MIDD\juser'" on that client shows only local IPA groups, not AD groups. And logins to Client 3 also fail, and "id 'MIDD\juser'" there shows "No such user". (This is the RHEL 5 box with sssd 1.5.1.) So we're back to my original problem of three clients all behaving differently. >David, the IPA clients will connect the IPA server to get the user data. >This means if the server cannot resolve the user the clients cannot either. So >the IPA server should be checked first. All three servers can resolve the user. The user can log in to all the servers and "id 'MIDD\juser'" shows the correct AD groups. >You said that you have three IPA servers (master and replicas). Did you run >ipa-adtrust-install on all server? If not, please do. If you are not sure, running >ipa-adtrust-install multiple times does not so any harm. Yes, the trust relationship is set up correctly on all three servers, and "ipa trust-find --all" gives identical results on all three servers, correctly showing the trust relationship with our AD domain. > Since you are using RHEL-6 clients I assume your IPA servers are on >RHEL-6 as well. No, the servers are all running RHEL 7.1, so we're not using winbind at all -- just sssd. The clients are a mix of RHEL 6 and RHEL 5 machines. David Guertin From rcritten at redhat.com Thu Mar 26 15:48:36 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Mar 2015 11:48:36 -0400 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> Message-ID: <55142A54.3010502@redhat.com> Matt . wrote: > HI Rob, > > Yes something is wrong there I guess. In any case, it doesn't apply to what you're trying to do. > But still, I actually need to add a SAN to the webserver cert, which > is different I think than the services at least. > > So the question there is... how ? What webserver cert? Are you trying to load balance the IPA services via DNS? Not knowing what you want, I'm just answering what you are ASKING. That is not the same as giving a proper answer. I have the feeling you want to load balance IPA in general which isn't going to work without a ton of (ongoing) manual effort. Even Microsoft recommends against trying this in its AD environment: http://support.microsoft.com/en-us/kb/325608 In any case, the instructions I've already provided still apply. If you want to replace the Apache webserver cert you'll just need to do a couple of things first which has the potential of completely breaking IPA, so you'll need to be careful. Before you do anything, backup *.db in /etc/httpd/alias. Stop tracking the Apache cert in certmonger: # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert Delete the existing cert: # certutil -D -d /etc/httpd/alias -n Server-Cert Like I said, destructive. Finally use certmonger to get a new cert that includes a SAN. The syntax is slightly different than before, mostly because I'm just guessing in the dark because you aren't including enough details into what you're trying. # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt In this case the IPA server is ipa1.example.com and you're creating a SAN for ipa.example.com. Restart httpd. Note that this doesn't solve the Kerberos problem so cli access will still not work as expected. The UI _might_ work using forms-based authentication. I'd strongly urge you to think about the top of this e-mail before proceeding onto the bottom. rob > > Cheers, > > Matt > > 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> When digging around I see this documentation: >>> >>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>> >>> I would except that server.example.com is not going to be accepted by >>> IPA when you visit the webgui like that ? >> >> These are SRV records for the ldap service. Think of it as discovery for >> who provides ldap service in the domain. It isn't something used by a >> web browser. >> >> I'm no DNS expert (by far) but this example looks a little wonky. I'd >> think it should be example.com and not server.example.com. But in any >> case it is irrelevant to a browser. >> >> rob >> From anthony at advertise.com Thu Mar 26 16:28:05 2015 From: anthony at advertise.com (Anthony Lanni) Date: Thu, 26 Mar 2015 09:28:05 -0700 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: <55141446.4020906@redhat.com> References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> <55141446.4020906@redhat.com> Message-ID: great, thanks. On a related note: the server still doesn't get a (client) kerberos ticket, which means I can't kinit as a user and then log into a client machine without a password. Going the other way works fine, however. thx anthony On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek wrote: > Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have > the > keyutils dependency fixed anyway :-) > > Martin > > On 03/25/2015 06:59 PM, Anthony Lanni wrote: > > keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I > > reinstalled keyutils and then ran the ipa-server-install again, and this > > time it completed without error. > > > > Thanks very much, Martin and Dmitri! > > > > thx > > anthony > > > > On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek wrote: > > > >> On 03/25/2015 04:11 AM, Dmitri Pal wrote: > >>> On 03/24/2015 09:17 PM, Anthony Lanni wrote: > >>>> While running ipa-server-install, it's failing out at the end with an > >> error > >>>> regarding the client install on the server. This happens regardless of > >> how I > >>>> input the options, but here's the latest command: > >>>> > >>>> ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM > >>>> -n example.com -p passwd1 > -a > >>>> passwd2 --hostname=ldap-server-01.example.com > >>>> --forwarder=10.0.1.20 > >>>> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d > >>>> > >>>> Runs through the entire setup and gives me this: > >>>> > >>>> [...] > >>>> ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master > >>>> --unattended --domain example.com --server > >>>> ldap-server-01.example.com > --realm > >>>> EXAMPLE.COM --hostname > ldap-server-01.example.com > >>>> > >>>> ipa : DEBUG stdout= > >>>> > >>>> ipa : DEBUG stderr=Hostname: ldap-server-01.example.com > >>>> > >>>> Realm: EXAMPLE.COM > >>>> DNS Domain: example.com > >>>> IPA Server: ldap-server-01.example.com < > >> http://ldap-server-01.example.com> > >>>> BaseDN: dc=example,dc=com > >>>> New SSSD config will be created > >>>> Configured /etc/sssd/sssd.conf > >>>> Traceback (most recent call last): > >>>> File "/usr/sbin/ipa-client-install", line 2377, in > >>>> sys.exit(main()) > >>>> File "/usr/sbin/ipa-client-install", line 2363, in main > >>>> rval = install(options, env, fstore, statestore) > >>>> File "/usr/sbin/ipa-client-install", line 2135, in install > >>>> delete_persistent_client_session_data(host_principal) > >>>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in > >>>> delete_persistent_client_session_data > >>>> kernel_keyring.del_key(keyname) > >>>> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > >> line > >>>> 99, in del_key > >>>> real_key = get_real_key(key) > >>>> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > >> line > >>>> 45, in get_real_key > >>>> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, > >> key], > >>>> raiseonerr=False) > >>> > >>> Is keyctl installed? Can you run it manually? > >>> Any SELinux denials? > >> > >> You are likely hitting > >> https://fedorahosted.org/freeipa/ticket/3808 > >> > >> Please try installing keyutils before running ipa-server-install. It is > >> fixed > >> in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: > >> https://bugzilla.redhat.com/show_bug.cgi?id=1205660 > >> > >> 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 mkosek at redhat.com Thu Mar 26 16:31:50 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Mar 2015 17:31:50 +0100 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> <55141446.4020906@redhat.com> Message-ID: <55143476.3070607@redhat.com> I am not sure what you mean. So are you saying that "kinit USER" done on server fails? With what error? On 03/26/2015 05:28 PM, Anthony Lanni wrote: > great, thanks. > > On a related note: the server still doesn't get a (client) kerberos ticket, > which means I can't kinit as a user and then log into a client machine > without a password. Going the other way works fine, however. > > thx > anthony > > On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek wrote: > >> Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have >> the >> keyutils dependency fixed anyway :-) >> >> Martin >> >> On 03/25/2015 06:59 PM, Anthony Lanni wrote: >>> keyutils is already installed but /bin/keyctl was 0 length (!). Anyway I >>> reinstalled keyutils and then ran the ipa-server-install again, and this >>> time it completed without error. >>> >>> Thanks very much, Martin and Dmitri! >>> >>> thx >>> anthony >>> >>> On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek wrote: >>> >>>> On 03/25/2015 04:11 AM, Dmitri Pal wrote: >>>>> On 03/24/2015 09:17 PM, Anthony Lanni wrote: >>>>>> While running ipa-server-install, it's failing out at the end with an >>>> error >>>>>> regarding the client install on the server. This happens regardless of >>>> how I >>>>>> input the options, but here's the latest command: >>>>>> >>>>>> ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM >>>>>> -n example.com -p passwd1 >> -a >>>>>> passwd2 --hostname=ldap-server-01.example.com >>>>>> --forwarder=10.0.1.20 >>>>>> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d >>>>>> >>>>>> Runs through the entire setup and gives me this: >>>>>> >>>>>> [...] >>>>>> ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master >>>>>> --unattended --domain example.com --server >>>>>> ldap-server-01.example.com >> --realm >>>>>> EXAMPLE.COM --hostname >> ldap-server-01.example.com >>>>>> >>>>>> ipa : DEBUG stdout= >>>>>> >>>>>> ipa : DEBUG stderr=Hostname: ldap-server-01.example.com >>>>>> >>>>>> Realm: EXAMPLE.COM >>>>>> DNS Domain: example.com >>>>>> IPA Server: ldap-server-01.example.com < >>>> http://ldap-server-01.example.com> >>>>>> BaseDN: dc=example,dc=com >>>>>> New SSSD config will be created >>>>>> Configured /etc/sssd/sssd.conf >>>>>> Traceback (most recent call last): >>>>>> File "/usr/sbin/ipa-client-install", line 2377, in >>>>>> sys.exit(main()) >>>>>> File "/usr/sbin/ipa-client-install", line 2363, in main >>>>>> rval = install(options, env, fstore, statestore) >>>>>> File "/usr/sbin/ipa-client-install", line 2135, in install >>>>>> delete_persistent_client_session_data(host_principal) >>>>>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, in >>>>>> delete_persistent_client_session_data >>>>>> kernel_keyring.del_key(keyname) >>>>>> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", >>>> line >>>>>> 99, in del_key >>>>>> real_key = get_real_key(key) >>>>>> File "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", >>>> line >>>>>> 45, in get_real_key >>>>>> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, KEYTYPE, >>>> key], >>>>>> raiseonerr=False) >>>>> >>>>> Is keyctl installed? Can you run it manually? >>>>> Any SELinux denials? >>>> >>>> You are likely hitting >>>> https://fedorahosted.org/freeipa/ticket/3808 >>>> >>>> Please try installing keyutils before running ipa-server-install. It is >>>> fixed >>>> in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform also: >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1205660 >>>> >>>> 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 sbose at redhat.com Thu Mar 26 16:40:19 2015 From: sbose at redhat.com (Sumit Bose) Date: Thu, 26 Mar 2015 17:40:19 +0100 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> <1427298281.8302.62.camel@willson.usersys.redhat.com> <55134C60.3060505@redhat.com> <20150326082321.GI3550@p.redhat.com> Message-ID: <20150326164019.GD7785@p.redhat.com> On Thu, Mar 26, 2015 at 03:24:06PM +0000, Guertin, David S. wrote: > >I would like to just clarify tis a bit. The support to lookup up secondary groups > >(the group list the id command shows) for user which never authenticated > >was added in 7.1/6.7. > > Thanks. This makes sense, and indeed with Client 1 I can indeed log in, and "id 'MIDD\juser'" shows all the groups again. > > However, logins to Client 2 (also running RHEL 6.6 and sssd 1.11.6) still fail, and "id 'MIDD\juser'" on that client shows only local IPA groups, not AD groups. As long as the user has not logged in it is expected that the id command doe not show the full list of groups. To see why the login fails it would be good to know how you try to log in (I assume ssh) and which authentication method is used (password, ssh key, Kerberos ticket). Additionally the SSSD log files might be needed, most important here are the logs from the PAM and PAC responders and the domain log. > > And logins to Client 3 also fail, and "id 'MIDD\juser'" there shows "No such user". (This is the RHEL 5 box with sssd 1.5.1.) So we're back to my original problem of three clients all behaving differently. For RHEL5 you need a special configuration for SSSD, call 'ipa-advise config-redhat-sssd-before-1-9' for more details. HTH bye, Sumit > > >David, the IPA clients will connect the IPA server to get the user data. > >This means if the server cannot resolve the user the clients cannot either. So > >the IPA server should be checked first. > > All three servers can resolve the user. The user can log in to all the servers and "id 'MIDD\juser'" shows the correct AD groups. > > >You said that you have three IPA servers (master and replicas). Did you run > >ipa-adtrust-install on all server? If not, please do. If you are not sure, running > >ipa-adtrust-install multiple times does not so any harm. > > Yes, the trust relationship is set up correctly on all three servers, and "ipa trust-find --all" gives identical results on all three servers, correctly showing the trust relationship with our AD domain. > > > Since you are using RHEL-6 clients I assume your IPA servers are on > >RHEL-6 as well. > > No, the servers are all running RHEL 7.1, so we're not using winbind at all -- just sssd. > > The clients are a mix of RHEL 6 and RHEL 5 machines. > > David Guertin From anthony at advertise.com Thu Mar 26 16:52:42 2015 From: anthony at advertise.com (Anthony Lanni) Date: Thu, 26 Mar 2015 09:52:42 -0700 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: <55143476.3070607@redhat.com> References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> <55141446.4020906@redhat.com> <55143476.3070607@redhat.com> Message-ID: kinit USER works perfectly; but I can't ssh into the client machine from the server without it requesting a password. I think this is a DNS issue, actually. The server isn't resolving the name of the client, so I'm ssh'ing with the IP address, and that's not going to work since it's not in the Kerberos db ("Cannot determine realm for numeric host address"). Except, of course, that the server did not get its own valid Kerberos host certificate. It should, right? during the ipa-client-install --on-master step of the server install? In fact, the global DNS config is completely empty. But I'm going to have to tear down the server and rebuild because it's on the same domain as an AD server, and ipa-client-install finds that server rather than the new IPA server by default: that won't work because I want LDAP to dynamically update the records, and establish a trust with the AD server. Also we've got 2 linux DNS root servers that act as forwarders. I pointed the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind to configure IPA to use them properly. SO I'm sure that's where most of my problems lie. I've got to RTFM a bit more before I really start asking the right questions, I think. At that point I'll start a new thread. thx anthony On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek wrote: > I am not sure what you mean. So are you saying that "kinit USER" done on > server > fails? With what error? > > On 03/26/2015 05:28 PM, Anthony Lanni wrote: > > great, thanks. > > > > On a related note: the server still doesn't get a (client) kerberos > ticket, > > which means I can't kinit as a user and then log into a client machine > > without a password. Going the other way works fine, however. > > > > thx > > anthony > > > > On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek wrote: > > > >> Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have > >> the > >> keyutils dependency fixed anyway :-) > >> > >> Martin > >> > >> On 03/25/2015 06:59 PM, Anthony Lanni wrote: > >>> keyutils is already installed but /bin/keyctl was 0 length (!). Anyway > I > >>> reinstalled keyutils and then ran the ipa-server-install again, and > this > >>> time it completed without error. > >>> > >>> Thanks very much, Martin and Dmitri! > >>> > >>> thx > >>> anthony > >>> > >>> On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek > wrote: > >>> > >>>> On 03/25/2015 04:11 AM, Dmitri Pal wrote: > >>>>> On 03/24/2015 09:17 PM, Anthony Lanni wrote: > >>>>>> While running ipa-server-install, it's failing out at the end with > an > >>>> error > >>>>>> regarding the client install on the server. This happens regardless > of > >>>> how I > >>>>>> input the options, but here's the latest command: > >>>>>> > >>>>>> ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM > >>>>>> -n example.com -p passwd1 > >> -a > >>>>>> passwd2 --hostname=ldap-server-01.example.com > >>>>>> --forwarder=10.0.1.20 > >>>>>> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d > >>>>>> > >>>>>> Runs through the entire setup and gives me this: > >>>>>> > >>>>>> [...] > >>>>>> ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master > >>>>>> --unattended --domain example.com --server > >>>>>> ldap-server-01.example.com > >> --realm > >>>>>> EXAMPLE.COM --hostname > >> ldap-server-01.example.com > >>>>>> > >>>>>> ipa : DEBUG stdout= > >>>>>> > >>>>>> ipa : DEBUG stderr=Hostname: ldap-server-01.example.com > >>>>>> > >>>>>> Realm: EXAMPLE.COM > >>>>>> DNS Domain: example.com > >>>>>> IPA Server: ldap-server-01.example.com < > >>>> http://ldap-server-01.example.com> > >>>>>> BaseDN: dc=example,dc=com > >>>>>> New SSSD config will be created > >>>>>> Configured /etc/sssd/sssd.conf > >>>>>> Traceback (most recent call last): > >>>>>> File "/usr/sbin/ipa-client-install", line 2377, in > >>>>>> sys.exit(main()) > >>>>>> File "/usr/sbin/ipa-client-install", line 2363, in main > >>>>>> rval = install(options, env, fstore, statestore) > >>>>>> File "/usr/sbin/ipa-client-install", line 2135, in install > >>>>>> delete_persistent_client_session_data(host_principal) > >>>>>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, > in > >>>>>> delete_persistent_client_session_data > >>>>>> kernel_keyring.del_key(keyname) > >>>>>> File > "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > >>>> line > >>>>>> 99, in del_key > >>>>>> real_key = get_real_key(key) > >>>>>> File > "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > >>>> line > >>>>>> 45, in get_real_key > >>>>>> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, > KEYTYPE, > >>>> key], > >>>>>> raiseonerr=False) > >>>>> > >>>>> Is keyctl installed? Can you run it manually? > >>>>> Any SELinux denials? > >>>> > >>>> You are likely hitting > >>>> https://fedorahosted.org/freeipa/ticket/3808 > >>>> > >>>> Please try installing keyutils before running ipa-server-install. It > is > >>>> fixed > >>>> in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform > also: > >>>> https://bugzilla.redhat.com/show_bug.cgi?id=1205660 > >>>> > >>>> 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 mkosek at redhat.com Thu Mar 26 17:01:01 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Mar 2015 18:01:01 +0100 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> <55141446.4020906@redhat.com> <55143476.3070607@redhat.com> Message-ID: <55143B4D.7080201@redhat.com> On 03/26/2015 05:52 PM, Anthony Lanni wrote: > kinit USER works perfectly; but I can't ssh into the client machine from > the server without it requesting a password. > > I think this is a DNS issue, actually. The server isn't resolving the name > of the client, so I'm ssh'ing with the IP address, and that's not going to > work since it's not in the Kerberos db ("Cannot determine realm for numeric > host address"). So it looks like you have found your problem - Kerberos tends to break if DNS is not set properly. > Except, of course, that the server did not get its own valid Kerberos host > certificate. It should, right? during the ipa-client-install --on-master > step of the server install? Are you asking about host certificate or a Kerberos keytab (/etc/krb5.keytab)? They are 2 distinct things. > In fact, the global DNS config is completely empty. But I'm going to have > to tear down the server and rebuild because it's on the same domain as an > AD server, and ipa-client-install finds that server rather than the new IPA > server by default: that won't work because I want LDAP to dynamically > update the records, and establish a trust with the AD server. > Also we've got 2 linux DNS root servers that act as forwarders. I pointed > the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind > to configure IPA to use them properly. SO I'm sure that's where most of my > problems lie. > > I've got to RTFM a bit more before I really start asking the right > questions, I think. At that point I'll start a new thread. Ok :-) Martin > > > > thx > anthony > > On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek wrote: > >> I am not sure what you mean. So are you saying that "kinit USER" done on >> server >> fails? With what error? >> >> On 03/26/2015 05:28 PM, Anthony Lanni wrote: >>> great, thanks. >>> >>> On a related note: the server still doesn't get a (client) kerberos >> ticket, >>> which means I can't kinit as a user and then log into a client machine >>> without a password. Going the other way works fine, however. >>> >>> thx >>> anthony >>> >>> On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek wrote: >>> >>>> Ok, thanks for reaching back. BTW, next RHEL-6 minor release should have >>>> the >>>> keyutils dependency fixed anyway :-) >>>> >>>> Martin >>>> >>>> On 03/25/2015 06:59 PM, Anthony Lanni wrote: >>>>> keyutils is already installed but /bin/keyctl was 0 length (!). Anyway >> I >>>>> reinstalled keyutils and then ran the ipa-server-install again, and >> this >>>>> time it completed without error. >>>>> >>>>> Thanks very much, Martin and Dmitri! >>>>> >>>>> thx >>>>> anthony >>>>> >>>>> On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek >> wrote: >>>>> >>>>>> On 03/25/2015 04:11 AM, Dmitri Pal wrote: >>>>>>> On 03/24/2015 09:17 PM, Anthony Lanni wrote: >>>>>>>> While running ipa-server-install, it's failing out at the end with >> an >>>>>> error >>>>>>>> regarding the client install on the server. This happens regardless >> of >>>>>> how I >>>>>>>> input the options, but here's the latest command: >>>>>>>> >>>>>>>> ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM >>>>>>>> -n example.com -p passwd1 >>>> -a >>>>>>>> passwd2 --hostname=ldap-server-01.example.com >>>>>>>> --forwarder=10.0.1.20 >>>>>>>> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d >>>>>>>> >>>>>>>> Runs through the entire setup and gives me this: >>>>>>>> >>>>>>>> [...] >>>>>>>> ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master >>>>>>>> --unattended --domain example.com --server >>>>>>>> ldap-server-01.example.com >>>> --realm >>>>>>>> EXAMPLE.COM --hostname >>>> ldap-server-01.example.com >>>>>>>> >>>>>>>> ipa : DEBUG stdout= >>>>>>>> >>>>>>>> ipa : DEBUG stderr=Hostname: ldap-server-01.example.com >>>>>>>> >>>>>>>> Realm: EXAMPLE.COM >>>>>>>> DNS Domain: example.com >>>>>>>> IPA Server: ldap-server-01.example.com < >>>>>> http://ldap-server-01.example.com> >>>>>>>> BaseDN: dc=example,dc=com >>>>>>>> New SSSD config will be created >>>>>>>> Configured /etc/sssd/sssd.conf >>>>>>>> Traceback (most recent call last): >>>>>>>> File "/usr/sbin/ipa-client-install", line 2377, in >>>>>>>> sys.exit(main()) >>>>>>>> File "/usr/sbin/ipa-client-install", line 2363, in main >>>>>>>> rval = install(options, env, fstore, statestore) >>>>>>>> File "/usr/sbin/ipa-client-install", line 2135, in install >>>>>>>> delete_persistent_client_session_data(host_principal) >>>>>>>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, >> in >>>>>>>> delete_persistent_client_session_data >>>>>>>> kernel_keyring.del_key(keyname) >>>>>>>> File >> "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", >>>>>> line >>>>>>>> 99, in del_key >>>>>>>> real_key = get_real_key(key) >>>>>>>> File >> "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", >>>>>> line >>>>>>>> 45, in get_real_key >>>>>>>> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, >> KEYTYPE, >>>>>> key], >>>>>>>> raiseonerr=False) >>>>>>> >>>>>>> Is keyctl installed? Can you run it manually? >>>>>>> Any SELinux denials? >>>>>> >>>>>> You are likely hitting >>>>>> https://fedorahosted.org/freeipa/ticket/3808 >>>>>> >>>>>> Please try installing keyutils before running ipa-server-install. It >> is >>>>>> fixed >>>>>> in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform >> also: >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1205660 >>>>>> >>>>>> 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 pvoborni at redhat.com Thu Mar 26 17:14:34 2015 From: pvoborni at redhat.com (Petr Vobornik) Date: Thu, 26 Mar 2015 18:14:34 +0100 Subject: [Freeipa-users] Announcing FreeIPA 4.1.4 Message-ID: <55143E7A.7050907@redhat.com> The FreeIPA team would like to announce FreeIPA v4.1.4 security release! It can be downloaded from http://www.freeipa.org/page/Downloads. The builds will be available for Fedora 21. Builds for Fedora 20 are available in the official COPR repository . == Highlights in 4.1.4 == === Security fixes === * 'CVE-2015-1827' It was discovered that the IPA extdom Directory Server plug-in did not correctly perform memory reallocation when handling user account information. A request for a list of groups for a user that belongs to a large number of groups would cause a Directory Server to crash. * 'CVE-2015-0283' Additionally, FreeIPA 4.1.4 requires use of slapi-nis 0.54.2 which includes number of fixes for the CVE-2015-0283: It was discovered that the slapi-nis Directory Server plug-in did not correctly perform memory reallocation when handling user account information. A request for information about a group with many members, or a request for a user that belongs to a large number of groups, would cause a Directory Server to enter an infinite loop and consume an excessive amount of CPU time. These issues were discovered by Sumit Bose of Red Hat. === Enhancements === * Various documentation improvements by Gabe Alford === Bug fixes === * Various fixes to DNSSEC support and overall DNS deployment scripts * Improvements in handling CA certificates from previous deployments when installing FreeIPA clients * Licensing of FreeIPA is clarified with regards to OpenSSL integration * More robust configuration of slapi-nis plugin to prevent potential dead-locks with other operations requiring lower-level database access. == Upgrading == Upgrade instructions are available on upgrade page . == Feedback == Please provide comments, bugs and other feedback via the freeipa-users mailing list or #freeipa channel on Freenode. == Detailed Changelog since 4.1.3 == === Alexander Bokovoy (2) === * fix Makefile.am for daemons * slapi-nis: require 0.54.2 for CVE-2015-0283 fixes === David Kupka (2) === * Use IPA CA certificate when available and ignore NO_TLS_LDAP when not. * Restore default.conf and use it to build API. === Gabe Alford (3) === * ipa-replica-prepare should document ipv6 options * ipatests: Add tests for valid and invalid ipa-advise * ipa-replica-prepare can only be created on the first master === Jan Cholasta (4) === * certstore: Make certificate retrieval more robust * client-install: Do not crash on invalid CA certificate in LDAP * client: Fix ca_is_enabled calls * upload_cacrt: Fix empty cACertificate in cn=CAcert === Martin Babinsky (3) === * ipa-dns-install: use STARTTLS to connect to DS * migrate-ds: print out failed attempts when no users/groups are migrated * show the exception message thrown by dogtag._parse_ca_status during install === Martin Ba?ti (7) === * DNSSEC add support for CKM_RSA_PKCS_OAEP mechanism * Fix memory leaks in ipap11helper * Remove unused method from ipap11pkcs helper module * DNS fix: do not traceback if unsupported records are in LDAP * DNS fix: do not show part options for unsupported records * DNS: remove NSEC3PARAM from records * Fix dead code in ipap11helper module === Martin Ko?ek (1) === * Remove references to GPL v2.0 license === Nathan Kinder (1) === * Timeout when performing time sync during client install === Petr Voborn?k (2) === * ipatests: add missing ssh object classes to idoverrideuser * Become IPA 4.1.4 === Petr ?pa?ek (3) === * p11helper: standardize indentation and other visual aspects of the code * p11helper: use sizeof() instead of magic constants * p11helper: clarify error message === Simo Sorce (2) === * Add a clear OpenSSL exception. * Stop including the DES algorythm from openssl. === Sumit Bose (7) === * ipa-range-check: do not treat missing objects as error * Add configure check for cwrap libraries * extdom: handle ERANGE return code for getXXYYY_r() calls * extdom: make nss buffer configurable * extdom: return LDAP_NO_SUCH_OBJECT to the client * extdom: fix memory leak * extdom: fix wrong realloc size === Tom?? Babej (3) === * ipatests: Add coverage for adding and removing sshpubkeys in ID overrides * ipalib: Make sure correct attribute name is referenced for fax * idviews: Use case-insensitive detection of Default Trust View === Thierry Bordaz (1) === * Limit deadlocks between DS plugin DNA and slapi-nis -- Petr Vobornik From anthony at advertise.com Thu Mar 26 17:38:54 2015 From: anthony at advertise.com (Anthony Lanni) Date: Thu, 26 Mar 2015 10:38:54 -0700 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: <55143B4D.7080201@redhat.com> References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> <55141446.4020906@redhat.com> <55143476.3070607@redhat.com> <55143B4D.7080201@redhat.com> Message-ID: I'm referring to the host certificate; I was looking at the web UI, under Identity->Hosts in the server details page. The Host Certificate section says 'No Valid Certificate'. The server has a /etc/krb5.keytab file, and on the same page the Enrollment section says 'Kerberos Key Present, Host Provisioned'. thx anthony thx anthony On Thu, Mar 26, 2015 at 10:01 AM, Martin Kosek wrote: > On 03/26/2015 05:52 PM, Anthony Lanni wrote: > > kinit USER works perfectly; but I can't ssh into the client machine from > > the server without it requesting a password. > > > > I think this is a DNS issue, actually. The server isn't resolving the > name > > of the client, so I'm ssh'ing with the IP address, and that's not going > to > > work since it's not in the Kerberos db ("Cannot determine realm for > numeric > > host address"). > > So it looks like you have found your problem - Kerberos tends to break if > DNS > is not set properly. > > > Except, of course, that the server did not get its own valid Kerberos > host > > certificate. It should, right? during the ipa-client-install --on-master > > step of the server install? > > Are you asking about host certificate or a Kerberos keytab > (/etc/krb5.keytab)? > They are 2 distinct things. > > > In fact, the global DNS config is completely empty. But I'm going to have > > to tear down the server and rebuild because it's on the same domain as an > > AD server, and ipa-client-install finds that server rather than the new > IPA > > server by default: that won't work because I want LDAP to dynamically > > update the records, and establish a trust with the AD server. > > Also we've got 2 linux DNS root servers that act as forwarders. I pointed > > the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind > > to configure IPA to use them properly. SO I'm sure that's where most of > my > > problems lie. > > > > I've got to RTFM a bit more before I really start asking the right > > questions, I think. At that point I'll start a new thread. > > Ok :-) > > Martin > > > > > > > > > thx > > anthony > > > > On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek wrote: > > > >> I am not sure what you mean. So are you saying that "kinit USER" done on > >> server > >> fails? With what error? > >> > >> On 03/26/2015 05:28 PM, Anthony Lanni wrote: > >>> great, thanks. > >>> > >>> On a related note: the server still doesn't get a (client) kerberos > >> ticket, > >>> which means I can't kinit as a user and then log into a client machine > >>> without a password. Going the other way works fine, however. > >>> > >>> thx > >>> anthony > >>> > >>> On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek > wrote: > >>> > >>>> Ok, thanks for reaching back. BTW, next RHEL-6 minor release should > have > >>>> the > >>>> keyutils dependency fixed anyway :-) > >>>> > >>>> Martin > >>>> > >>>> On 03/25/2015 06:59 PM, Anthony Lanni wrote: > >>>>> keyutils is already installed but /bin/keyctl was 0 length (!). > Anyway > >> I > >>>>> reinstalled keyutils and then ran the ipa-server-install again, and > >> this > >>>>> time it completed without error. > >>>>> > >>>>> Thanks very much, Martin and Dmitri! > >>>>> > >>>>> thx > >>>>> anthony > >>>>> > >>>>> On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek > >> wrote: > >>>>> > >>>>>> On 03/25/2015 04:11 AM, Dmitri Pal wrote: > >>>>>>> On 03/24/2015 09:17 PM, Anthony Lanni wrote: > >>>>>>>> While running ipa-server-install, it's failing out at the end with > >> an > >>>>>> error > >>>>>>>> regarding the client install on the server. This happens > regardless > >> of > >>>>>> how I > >>>>>>>> input the options, but here's the latest command: > >>>>>>>> > >>>>>>>> ipa-server-install --setup-dns -N --idstart=1000 -r EXAMPLE.COM > >>>>>>>> -n example.com -p > passwd1 > >>>> -a > >>>>>>>> passwd2 --hostname=ldap-server-01.example.com > >>>>>>>> --forwarder=10.0.1.20 > >>>>>>>> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d > >>>>>>>> > >>>>>>>> Runs through the entire setup and gives me this: > >>>>>>>> > >>>>>>>> [...] > >>>>>>>> ipa : DEBUG args=/usr/sbin/ipa-client-install --on-master > >>>>>>>> --unattended --domain example.com --server > >>>>>>>> ldap-server-01.example.com > >>>> --realm > >>>>>>>> EXAMPLE.COM --hostname > >>>> ldap-server-01.example.com > >>>>>>>> > >>>>>>>> ipa : DEBUG stdout= > >>>>>>>> > >>>>>>>> ipa : DEBUG stderr=Hostname: > ldap-server-01.example.com > >>>>>>>> > >>>>>>>> Realm: EXAMPLE.COM > >>>>>>>> DNS Domain: example.com > >>>>>>>> IPA Server: ldap-server-01.example.com < > >>>>>> http://ldap-server-01.example.com> > >>>>>>>> BaseDN: dc=example,dc=com > >>>>>>>> New SSSD config will be created > >>>>>>>> Configured /etc/sssd/sssd.conf > >>>>>>>> Traceback (most recent call last): > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2377, in > >>>>>>>> sys.exit(main()) > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2363, in main > >>>>>>>> rval = install(options, env, fstore, statestore) > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2135, in install > >>>>>>>> delete_persistent_client_session_data(host_principal) > >>>>>>>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", line 124, > >> in > >>>>>>>> delete_persistent_client_session_data > >>>>>>>> kernel_keyring.del_key(keyname) > >>>>>>>> File > >> "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > >>>>>> line > >>>>>>>> 99, in del_key > >>>>>>>> real_key = get_real_key(key) > >>>>>>>> File > >> "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > >>>>>> line > >>>>>>>> 45, in get_real_key > >>>>>>>> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, > >> KEYTYPE, > >>>>>> key], > >>>>>>>> raiseonerr=False) > >>>>>>> > >>>>>>> Is keyctl installed? Can you run it manually? > >>>>>>> Any SELinux denials? > >>>>>> > >>>>>> You are likely hitting > >>>>>> https://fedorahosted.org/freeipa/ticket/3808 > >>>>>> > >>>>>> Please try installing keyutils before running ipa-server-install. It > >> is > >>>>>> fixed > >>>>>> in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform > >> also: > >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1205660 > >>>>>> > >>>>>> 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 rcritten at redhat.com Thu Mar 26 17:44:09 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Mar 2015 13:44:09 -0400 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> <55141446.4020906@redhat.com> <55143476.3070607@redhat.com> <55143B4D.7080201@redhat.com> Message-ID: <55144569.907@redhat.com> Anthony Lanni wrote: > I'm referring to the host certificate; I was looking at the web UI, > under Identity->Hosts in the server details page. The Host Certificate > section says 'No Valid Certificate'. > The server has a /etc/krb5.keytab file, and on the same page the > Enrollment section says 'Kerberos Key Present, Host Provisioned'. No, masters never got this certificate issued. It was intended to be an alternate way to authenticate a host to IPA. The host certificate is not used by IPA currently, and in 4.1 one isn't issued for clients by default any more. rob > > thx > anthony > > thx > anthony > > On Thu, Mar 26, 2015 at 10:01 AM, Martin Kosek > wrote: > > On 03/26/2015 05:52 PM, Anthony Lanni wrote: > > kinit USER works perfectly; but I can't ssh into the client machine from > > the server without it requesting a password. > > > > I think this is a DNS issue, actually. The server isn't resolving the name > > of the client, so I'm ssh'ing with the IP address, and that's not going to > > work since it's not in the Kerberos db ("Cannot determine realm for numeric > > host address"). > > So it looks like you have found your problem - Kerberos tends to > break if DNS > is not set properly. > > > Except, of course, that the server did not get its own valid Kerberos host > > certificate. It should, right? during the ipa-client-install --on-master > > step of the server install? > > Are you asking about host certificate or a Kerberos keytab > (/etc/krb5.keytab)? > They are 2 distinct things. > > > In fact, the global DNS config is completely empty. But I'm going to have > > to tear down the server and rebuild because it's on the same domain as an > > AD server, and ipa-client-install finds that server rather than the new IPA > > server by default: that won't work because I want LDAP to dynamically > > update the records, and establish a trust with the AD server. > > Also we've got 2 linux DNS root servers that act as forwarders. I pointed > > the IPA server at them, but I don't know enough about FreeIPA or DNS/Bind > > to configure IPA to use them properly. SO I'm sure that's where most of my > > problems lie. > > > > I've got to RTFM a bit more before I really start asking the right > > questions, I think. At that point I'll start a new thread. > > Ok :-) > > Martin > > > > > > > > > thx > > anthony > > > > On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek > wrote: > > > >> I am not sure what you mean. So are you saying that "kinit USER" > done on > >> server > >> fails? With what error? > >> > >> On 03/26/2015 05:28 PM, Anthony Lanni wrote: > >>> great, thanks. > >>> > >>> On a related note: the server still doesn't get a (client) kerberos > >> ticket, > >>> which means I can't kinit as a user and then log into a client > machine > >>> without a password. Going the other way works fine, however. > >>> > >>> thx > >>> anthony > >>> > >>> On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek > wrote: > >>> > >>>> Ok, thanks for reaching back. BTW, next RHEL-6 minor release > should have > >>>> the > >>>> keyutils dependency fixed anyway :-) > >>>> > >>>> Martin > >>>> > >>>> On 03/25/2015 06:59 PM, Anthony Lanni wrote: > >>>>> keyutils is already installed but /bin/keyctl was 0 length > (!). Anyway > >> I > >>>>> reinstalled keyutils and then ran the ipa-server-install > again, and > >> this > >>>>> time it completed without error. > >>>>> > >>>>> Thanks very much, Martin and Dmitri! > >>>>> > >>>>> thx > >>>>> anthony > >>>>> > >>>>> On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek > > > >> wrote: > >>>>> > >>>>>> On 03/25/2015 04:11 AM, Dmitri Pal wrote: > >>>>>>> On 03/24/2015 09:17 PM, Anthony Lanni wrote: > >>>>>>>> While running ipa-server-install, it's failing out at the > end with > >> an > >>>>>> error > >>>>>>>> regarding the client install on the server. This happens > regardless > >> of > >>>>>> how I > >>>>>>>> input the options, but here's the latest command: > >>>>>>>> > >>>>>>>> ipa-server-install --setup-dns -N --idstart=1000 -r > EXAMPLE.COM > >>>>>>>> -n example.com > -p passwd1 > >>>> -a > >>>>>>>> passwd2 --hostname=ldap-server-01.example.com > > >>>>>>>> --forwarder=10.0.1.20 > >>>>>>>> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d > >>>>>>>> > >>>>>>>> Runs through the entire setup and gives me this: > >>>>>>>> > >>>>>>>> [...] > >>>>>>>> ipa : DEBUG args=/usr/sbin/ipa-client-install > --on-master > >>>>>>>> --unattended --domain example.com > --server > >>>>>>>> ldap-server-01.example.com > > >>>> --realm > >>>>>>>> EXAMPLE.COM > --hostname > >>>> ldap-server-01.example.com > >>>>>>>> > >>>>>>>> ipa : DEBUG stdout= > >>>>>>>> > >>>>>>>> ipa : DEBUG stderr=Hostname: > ldap-server-01.example.com > >>>>>>>> > >>>>>>>> Realm: EXAMPLE.COM > >>>>>>>> DNS Domain: example.com > > >>>>>>>> IPA Server: ldap-server-01.example.com > < > >>>>>> http://ldap-server-01.example.com> > >>>>>>>> BaseDN: dc=example,dc=com > >>>>>>>> New SSSD config will be created > >>>>>>>> Configured /etc/sssd/sssd.conf > >>>>>>>> Traceback (most recent call last): > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2377, in > >>>>>>>> sys.exit(main()) > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2363, in main > >>>>>>>> rval = install(options, env, fstore, statestore) > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2135, in install > >>>>>>>> delete_persistent_client_session_data(host_principal) > >>>>>>>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", > line 124, > >> in > >>>>>>>> delete_persistent_client_session_data > >>>>>>>> kernel_keyring.del_key(keyname) > >>>>>>>> File > >> "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > >>>>>> line > >>>>>>>> 99, in del_key > >>>>>>>> real_key = get_real_key(key) > >>>>>>>> File > >> "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > >>>>>> line > >>>>>>>> 45, in get_real_key > >>>>>>>> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, > >> KEYTYPE, > >>>>>> key], > >>>>>>>> raiseonerr=False) > >>>>>>> > >>>>>>> Is keyctl installed? Can you run it manually? > >>>>>>> Any SELinux denials? > >>>>>> > >>>>>> You are likely hitting > >>>>>> https://fedorahosted.org/freeipa/ticket/3808 > >>>>>> > >>>>>> Please try installing keyutils before running > ipa-server-install. It > >> is > >>>>>> fixed > >>>>>> in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this platform > >> also: > >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1205660 > >>>>>> > >>>>>> 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 anthony at advertise.com Thu Mar 26 18:09:19 2015 From: anthony at advertise.com (Anthony Lanni) Date: Thu, 26 Mar 2015 11:09:19 -0700 Subject: [Freeipa-users] ipa-client-install failing on new ipa-server In-Reply-To: <55144569.907@redhat.com> References: <55122775.5040406@redhat.com> <5512AB72.6090201@redhat.com> <55141446.4020906@redhat.com> <55143476.3070607@redhat.com> <55143B4D.7080201@redhat.com> <55144569.907@redhat.com> Message-ID: ah, ok. So I'm going to assume the problem with my server not being able to get a DNS record for any of the clients is why the user can't ssh into the clients. Thanks for the help, everyone! thx anthony On Thu, Mar 26, 2015 at 10:44 AM, Rob Crittenden wrote: > Anthony Lanni wrote: > > I'm referring to the host certificate; I was looking at the web UI, > > under Identity->Hosts in the server details page. The Host Certificate > > section says 'No Valid Certificate'. > > The server has a /etc/krb5.keytab file, and on the same page the > > Enrollment section says 'Kerberos Key Present, Host Provisioned'. > > No, masters never got this certificate issued. It was intended to be an > alternate way to authenticate a host to IPA. The host certificate is not > used by IPA currently, and in 4.1 one isn't issued for clients by > default any more. > > rob > > > > > thx > > anthony > > > > thx > > anthony > > > > On Thu, Mar 26, 2015 at 10:01 AM, Martin Kosek > > wrote: > > > > On 03/26/2015 05:52 PM, Anthony Lanni wrote: > > > kinit USER works perfectly; but I can't ssh into the client > machine from > > > the server without it requesting a password. > > > > > > I think this is a DNS issue, actually. The server isn't resolving > the name > > > of the client, so I'm ssh'ing with the IP address, and that's not > going to > > > work since it's not in the Kerberos db ("Cannot determine realm > for numeric > > > host address"). > > > > So it looks like you have found your problem - Kerberos tends to > > break if DNS > > is not set properly. > > > > > Except, of course, that the server did not get its own valid > Kerberos host > > > certificate. It should, right? during the ipa-client-install > --on-master > > > step of the server install? > > > > Are you asking about host certificate or a Kerberos keytab > > (/etc/krb5.keytab)? > > They are 2 distinct things. > > > > > In fact, the global DNS config is completely empty. But I'm going > to have > > > to tear down the server and rebuild because it's on the same > domain as an > > > AD server, and ipa-client-install finds that server rather than > the new IPA > > > server by default: that won't work because I want LDAP to > dynamically > > > update the records, and establish a trust with the AD server. > > > Also we've got 2 linux DNS root servers that act as forwarders. I > pointed > > > the IPA server at them, but I don't know enough about FreeIPA or > DNS/Bind > > > to configure IPA to use them properly. SO I'm sure that's where > most of my > > > problems lie. > > > > > > I've got to RTFM a bit more before I really start asking the right > > > questions, I think. At that point I'll start a new thread. > > > > Ok :-) > > > > Martin > > > > > > > > > > > > > > thx > > > anthony > > > > > > On Thu, Mar 26, 2015 at 9:31 AM, Martin Kosek > > wrote: > > > > > >> I am not sure what you mean. So are you saying that "kinit USER" > > done on > > >> server > > >> fails? With what error? > > >> > > >> On 03/26/2015 05:28 PM, Anthony Lanni wrote: > > >>> great, thanks. > > >>> > > >>> On a related note: the server still doesn't get a (client) > kerberos > > >> ticket, > > >>> which means I can't kinit as a user and then log into a client > > machine > > >>> without a password. Going the other way works fine, however. > > >>> > > >>> thx > > >>> anthony > > >>> > > >>> On Thu, Mar 26, 2015 at 7:14 AM, Martin Kosek > > wrote: > > >>> > > >>>> Ok, thanks for reaching back. BTW, next RHEL-6 minor release > > should have > > >>>> the > > >>>> keyutils dependency fixed anyway :-) > > >>>> > > >>>> Martin > > >>>> > > >>>> On 03/25/2015 06:59 PM, Anthony Lanni wrote: > > >>>>> keyutils is already installed but /bin/keyctl was 0 length > > (!). Anyway > > >> I > > >>>>> reinstalled keyutils and then ran the ipa-server-install > > again, and > > >> this > > >>>>> time it completed without error. > > >>>>> > > >>>>> Thanks very much, Martin and Dmitri! > > >>>>> > > >>>>> thx > > >>>>> anthony > > >>>>> > > >>>>> On Wed, Mar 25, 2015 at 5:34 AM, Martin Kosek > > > > > >> wrote: > > >>>>> > > >>>>>> On 03/25/2015 04:11 AM, Dmitri Pal wrote: > > >>>>>>> On 03/24/2015 09:17 PM, Anthony Lanni wrote: > > >>>>>>>> While running ipa-server-install, it's failing out at the > > end with > > >> an > > >>>>>> error > > >>>>>>>> regarding the client install on the server. This happens > > regardless > > >> of > > >>>>>> how I > > >>>>>>>> input the options, but here's the latest command: > > >>>>>>>> > > >>>>>>>> ipa-server-install --setup-dns -N --idstart=1000 -r > > EXAMPLE.COM > > >>>>>>>> -n example.com > > -p passwd1 > > >>>> -a > > >>>>>>>> passwd2 --hostname=ldap-server-01.example.com > > > > >>>>>>>> --forwarder=10.0.1.20 > > >>>>>>>> --forwarder=10.0.1.21 --reverse-zone=1.0.10.in-addr.arpa. -d > > >>>>>>>> > > >>>>>>>> Runs through the entire setup and gives me this: > > >>>>>>>> > > >>>>>>>> [...] > > >>>>>>>> ipa : DEBUG args=/usr/sbin/ipa-client-install > > --on-master > > >>>>>>>> --unattended --domain example.com > > --server > > >>>>>>>> ldap-server-01.example.com > > < > http://ldap-server-01.example.com> > > >>>> --realm > > >>>>>>>> EXAMPLE.COM > > --hostname > > >>>> ldap-server-01.example.com > > >>>>>>>> > > >>>>>>>> ipa : DEBUG stdout= > > >>>>>>>> > > >>>>>>>> ipa : DEBUG stderr=Hostname: > > ldap-server-01.example.com > > >>>>>>>> > > >>>>>>>> Realm: EXAMPLE.COM > > > >>>>>>>> DNS Domain: example.com > > > > >>>>>>>> IPA Server: ldap-server-01.example.com > > < > > >>>>>> http://ldap-server-01.example.com> > > >>>>>>>> BaseDN: dc=example,dc=com > > >>>>>>>> New SSSD config will be created > > >>>>>>>> Configured /etc/sssd/sssd.conf > > >>>>>>>> Traceback (most recent call last): > > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2377, in > > > >>>>>>>> sys.exit(main()) > > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2363, in main > > >>>>>>>> rval = install(options, env, fstore, statestore) > > >>>>>>>> File "/usr/sbin/ipa-client-install", line 2135, in install > > >>>>>>>> delete_persistent_client_session_data(host_principal) > > >>>>>>>> File "/usr/lib/python2.6/site-packages/ipalib/rpc.py", > > line 124, > > >> in > > >>>>>>>> delete_persistent_client_session_data > > >>>>>>>> kernel_keyring.del_key(keyname) > > >>>>>>>> File > > >> "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > > >>>>>> line > > >>>>>>>> 99, in del_key > > >>>>>>>> real_key = get_real_key(key) > > >>>>>>>> File > > >> "/usr/lib/python2.6/site-packages/ipapython/kernel_keyring.py", > > >>>>>> line > > >>>>>>>> 45, in get_real_key > > >>>>>>>> (stdout, stderr, rc) = run(['keyctl', 'search', KEYRING, > > >> KEYTYPE, > > >>>>>> key], > > >>>>>>>> raiseonerr=False) > > >>>>>>> > > >>>>>>> Is keyctl installed? Can you run it manually? > > >>>>>>> Any SELinux denials? > > >>>>>> > > >>>>>> You are likely hitting > > >>>>>> https://fedorahosted.org/freeipa/ticket/3808 > > >>>>>> > > >>>>>> Please try installing keyutils before running > > ipa-server-install. It > > >> is > > >>>>>> fixed > > >>>>>> in RHEL-7, I filed us a RHEL-6 ticket, to fix it in this > platform > > >> also: > > >>>>>> https://bugzilla.redhat.com/show_bug.cgi?id=1205660 > > >>>>>> > > >>>>>> 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 steve at sylvation.com Thu Mar 26 18:09:53 2015 From: steve at sylvation.com (Steve Neuharth) Date: Thu, 26 Mar 2015 13:09:53 -0500 Subject: [Freeipa-users] can't specify DNS name or subject in cert request in FreeIPA 3.3 Message-ID: I'm trying to specify a subject name in a cert request like this: ipa-getcert request -K HTTP/web.test.org -N *cn=www.test.org ,o=TEST.ORG * -f /tmp/webserver.crt -k /tmp/webprivate.key -r or like this ipa-getcert request -K HTTP/web.test.org -D www.test.org -f /tmp/webserver.crt -k /tmp/webprivate.key -r The resulting certificate, however, just has the hostname of the server like this: Request ID '20150326060555': status: MONITORING stuck: no key pair storage: type=FILE,location='/tmp/webprivate.key' certificate: type=FILE,location='/tmp/webserver.crt' CA: IPA issuer: CN=Certificate Authority,O=TEST.ORG subject: *CN=web.test.org ,O=TEST.ORG * expires: 2017-03-26 05:46:29 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 Is this a bug or am I doing something wrong in certmonger? --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Thu Mar 26 18:29:31 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 26 Mar 2015 14:29:31 -0400 Subject: [Freeipa-users] Understanding the migration mode Message-ID: Hello, I followed https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords in order to migrate our NIS installation, and for the most part it worked. The server responds to ypcat from the NIS clients, and users can log in. However, I'm seeing a couple of weird issues. Normally, ypcat returns "username:cryptpass:uid:gid:gecos:homedir:shell" for users and authentication works fine. For new users that were added directly to IPA, instead of the cryptpass, I see an asterisk(*), which is also understandable. However, for a couple of migrated users, I'm seeing that their cyrptpasses have also been replaced with *s (in ypcat's output) over the course of time. This creates problems for authentication on clients that haven't been migrated, and they can't log in with their passwords. These users didn't explicitly call kinit or go to the webui for migration. Is it normal for the crypt passes to be replaced by *? I migrated a couple of clients, and these users would have sshed to the migrated clients or possibly to the server. That didn't seem to affect ypcat's behaviour directly, and yet that is the only thing I can think of that has any connection to this. Regards, Prasun -------------- next part -------------- An HTML attachment was scrubbed... URL: From lists at thetimmy.com Thu Mar 26 18:37:04 2015 From: lists at thetimmy.com (Timothy Worman) Date: Thu, 26 Mar 2015 11:37:04 -0700 Subject: [Freeipa-users] inserting users via java In-Reply-To: <55111922.8010705@redhat.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> Message-ID: <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> Thanks everyone for the input. I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. 2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. I would be willing to test option 4 if that is where the future is headed. Tim > On Mar 24, 2015, at 12:58 AM, Martin Kosek wrote: > > On 03/24/2015 01:29 AM, Dmitri Pal wrote: >> On 03/23/2015 05:56 PM, Timothy Worman wrote: >>> I have an existing web app built with java/WebObjects that currently handles >>> some user/groups tasks with our current directory server (Open Directory). We >>> are investigating a move to FreeIPA for our directory services. >>> >>> Just in mucking around, I?ve found that if I try to insert a new user >>> (inetOrgPerson) into into IPA?s implementation, the new user does not inherit >>> all the object classes it should. It only inherits the ones leading to >>> inetOrgPerson. This does result in a successful inetOrgPerson insertion, but >>> that user record does not show up in the Web GUI management tools. >>> >>> Usually, I have focused on inetOrgPerson because that is where the bulk of >>> the info about a user lives. >>> >>> We have a SQL database that contains people in our organization (used by >>> other services), so, we need to be able to leverage that and push users into >>> IPA when appropriate and we have an existing app to do this. >>> >>> Tim W >>> >> You have several options: >> 1) Call ipa CLI from your application - this is possible right now (but not >> quite nice) >> 2) Call ipa JSON API from your application - this is not supported but >> possible. We use python API. You can do it in Java but it will be a lot of work. >> 3) Use more elaborate LDAP add commands (with all the object classes needed for >> users). Hard, but doable. >> 4) Help us with testing the upcoming feature >> http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow >> creating users via simple ldap command in a staging area and them moving them >> to normal users area with automatic creation of missing attributes by means of >> a cron job. >> >> I would vote for 1) as a temp solution and 4) as a longer term one. > > I do not fully agree with preferring 1) over 2). Java has libraries for > JSON-RPC protocol, it should be pretty doable to write a call that calls the > "user_add" command. > > We are lacking proper documentation for the API, but what you can look in the > sources or in the Web UI with and see the JSONs sent to the server, if you are > interested in the real life examples. > > Advantage of 2) over 1) is that you get the native objects (strings, arrays, > numbers) and you do not need to parse it from CLI. > > Martin From mkosek at redhat.com Thu Mar 26 18:42:46 2015 From: mkosek at redhat.com (Martin Kosek) Date: Thu, 26 Mar 2015 19:42:46 +0100 Subject: [Freeipa-users] inserting users via java In-Reply-To: <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> Message-ID: <55145326.80600@redhat.com> On 03/26/2015 07:37 PM, Timothy Worman wrote: > Thanks everyone for the input. > > I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. > > 2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. > > This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: ~~~ from ipalib import api from ipalib import errors api.bootstrap(context='cli') api.finalize() api.Backend.rpcclient.connect() api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') ~~~ What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? > I would be willing to test option 4 if that is where the future is headed. Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. > Tim > >> On Mar 24, 2015, at 12:58 AM, Martin Kosek wrote: >> >> On 03/24/2015 01:29 AM, Dmitri Pal wrote: >>> On 03/23/2015 05:56 PM, Timothy Worman wrote: >>>> I have an existing web app built with java/WebObjects that currently handles >>>> some user/groups tasks with our current directory server (Open Directory). We >>>> are investigating a move to FreeIPA for our directory services. >>>> >>>> Just in mucking around, I?ve found that if I try to insert a new user >>>> (inetOrgPerson) into into IPA?s implementation, the new user does not inherit >>>> all the object classes it should. It only inherits the ones leading to >>>> inetOrgPerson. This does result in a successful inetOrgPerson insertion, but >>>> that user record does not show up in the Web GUI management tools. >>>> >>>> Usually, I have focused on inetOrgPerson because that is where the bulk of >>>> the info about a user lives. >>>> >>>> We have a SQL database that contains people in our organization (used by >>>> other services), so, we need to be able to leverage that and push users into >>>> IPA when appropriate and we have an existing app to do this. >>>> >>>> Tim W >>>> >>> You have several options: >>> 1) Call ipa CLI from your application - this is possible right now (but not >>> quite nice) >>> 2) Call ipa JSON API from your application - this is not supported but >>> possible. We use python API. You can do it in Java but it will be a lot of work. >>> 3) Use more elaborate LDAP add commands (with all the object classes needed for >>> users). Hard, but doable. >>> 4) Help us with testing the upcoming feature >>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow >>> creating users via simple ldap command in a staging area and them moving them >>> to normal users area with automatic creation of missing attributes by means of >>> a cron job. >>> >>> I would vote for 1) as a temp solution and 4) as a longer term one. >> >> I do not fully agree with preferring 1) over 2). Java has libraries for >> JSON-RPC protocol, it should be pretty doable to write a call that calls the >> "user_add" command. >> >> We are lacking proper documentation for the API, but what you can look in the >> sources or in the Web UI with and see the JSONs sent to the server, if you are >> interested in the real life examples. >> >> Advantage of 2) over 1) is that you get the native objects (strings, arrays, >> numbers) and you do not need to parse it from CLI. >> >> Martin > From lists at thetimmy.com Thu Mar 26 19:19:18 2015 From: lists at thetimmy.com (Timothy Worman) Date: Thu, 26 Mar 2015 12:19:18 -0700 Subject: [Freeipa-users] inserting users via java In-Reply-To: <55145326.80600@redhat.com> References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> <55145326.80600@redhat.com> Message-ID: On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: > > On 03/26/2015 07:37 PM, Timothy Worman wrote: >> Thanks everyone for the input. >> >> I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. >> >> 2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. >> >> This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. > > There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: > > ~~~ > from ipalib import api > from ipalib import errors > > api.bootstrap(context='cli') > api.finalize() > api.Backend.rpcclient.connect() > api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') > ~~~ > > What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. > I would be willing to test option 4 if that is where the future is headed. > > Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. This may not be a bad thing if you?re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. Tim > >> Tim >> >>> On Mar 24, 2015, at 12:58 AM, Martin Kosek wrote: >>> >>> On 03/24/2015 01:29 AM, Dmitri Pal wrote: >>>> On 03/23/2015 05:56 PM, Timothy Worman wrote: >>>>> I have an existing web app built with java/WebObjects that currently handles >>>>> some user/groups tasks with our current directory server (Open Directory). We >>>>> are investigating a move to FreeIPA for our directory services. >>>>> >>>>> Just in mucking around, I?ve found that if I try to insert a new user >>>>> (inetOrgPerson) into into IPA?s implementation, the new user does not inherit >>>>> all the object classes it should. It only inherits the ones leading to >>>>> inetOrgPerson. This does result in a successful inetOrgPerson insertion, but >>>>> that user record does not show up in the Web GUI management tools. >>>>> >>>>> Usually, I have focused on inetOrgPerson because that is where the bulk of >>>>> the info about a user lives. >>>>> >>>>> We have a SQL database that contains people in our organization (used by >>>>> other services), so, we need to be able to leverage that and push users into >>>>> IPA when appropriate and we have an existing app to do this. >>>>> >>>>> Tim W >>>>> >>>> You have several options: >>>> 1) Call ipa CLI from your application - this is possible right now (but not >>>> quite nice) >>>> 2) Call ipa JSON API from your application - this is not supported but >>>> possible. We use python API. You can do it in Java but it will be a lot of work. >>>> 3) Use more elaborate LDAP add commands (with all the object classes needed for >>>> users). Hard, but doable. >>>> 4) Help us with testing the upcoming feature >>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow >>>> creating users via simple ldap command in a staging area and them moving them >>>> to normal users area with automatic creation of missing attributes by means of >>>> a cron job. >>>> >>>> I would vote for 1) as a temp solution and 4) as a longer term one. >>> >>> I do not fully agree with preferring 1) over 2). Java has libraries for >>> JSON-RPC protocol, it should be pretty doable to write a call that calls the >>> "user_add" command. >>> >>> We are lacking proper documentation for the API, but what you can look in the >>> sources or in the Web UI with and see the JSONs sent to the server, if you are >>> interested in the real life examples. >>> >>> Advantage of 2) over 1) is that you get the native objects (strings, arrays, >>> numbers) and you do not need to parse it from CLI. >>> >>> Martin >> > From yamakasi.014 at gmail.com Thu Mar 26 19:43:35 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 26 Mar 2015 20:43:35 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <55142A54.3010502@redhat.com> References: <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> <55142A54.3010502@redhat.com> Message-ID: Hi Rob, Thank you very much! I think this will work out as it's only https traffic. I will report back! Thanks a lot! Matt 2015-03-26 16:48 GMT+01:00 Rob Crittenden : > Matt . wrote: >> HI Rob, >> >> Yes something is wrong there I guess. > > In any case, it doesn't apply to what you're trying to do. > >> But still, I actually need to add a SAN to the webserver cert, which >> is different I think than the services at least. >> >> So the question there is... how ? > > What webserver cert? Are you trying to load balance the IPA services via > DNS? > > Not knowing what you want, I'm just answering what you are ASKING. That > is not the same as giving a proper answer. I have the feeling you want > to load balance IPA in general which isn't going to work without a ton > of (ongoing) manual effort. Even Microsoft recommends against trying > this in its AD environment: http://support.microsoft.com/en-us/kb/325608 > > In any case, the instructions I've already provided still apply. > > If you want to replace the Apache webserver cert you'll just need to do > a couple of things first which has the potential of completely breaking > IPA, so you'll need to be careful. > > Before you do anything, backup *.db in /etc/httpd/alias. > > Stop tracking the Apache cert in certmonger: > > # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert > > Delete the existing cert: > > # certutil -D -d /etc/httpd/alias -n Server-Cert > > Like I said, destructive. > > Finally use certmonger to get a new cert that includes a SAN. The syntax > is slightly different than before, mostly because I'm just guessing in > the dark because you aren't including enough details into what you're > trying. > > # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com > -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt > > In this case the IPA server is ipa1.example.com and you're creating a > SAN for ipa.example.com. > > Restart httpd. > > Note that this doesn't solve the Kerberos problem so cli access will > still not work as expected. The UI _might_ work using forms-based > authentication. > > I'd strongly urge you to think about the top of this e-mail before > proceeding onto the bottom. > > rob > >> >> Cheers, >> >> Matt >> >> 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> When digging around I see this documentation: >>>> >>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>>> >>>> I would except that server.example.com is not going to be accepted by >>>> IPA when you visit the webgui like that ? >>> >>> These are SRV records for the ldap service. Think of it as discovery for >>> who provides ldap service in the domain. It isn't something used by a >>> web browser. >>> >>> I'm no DNS expert (by far) but this example looks a little wonky. I'd >>> think it should be example.com and not server.example.com. But in any >>> case it is irrelevant to a browser. >>> >>> rob >>> > From frozen3 at aol.com Thu Mar 26 19:44:06 2015 From: frozen3 at aol.com (David Beck) Date: Thu, 26 Mar 2015 14:44:06 -0500 Subject: [Freeipa-users] AIX client integration Message-ID: <6F16433B-6FA8-4D49-A3E4-27FC4518957D@aol.com> All, This for anyone using AIX clients with freeipa. I have the client up and running just fine (No KRB5, AIX Bug); however I cannot seem to get the client to load the groups attributes properly. The users primary group shows up in the groups attribute from lsuser but not any subsequent groups the user is a member of in IPA. In the outputs below, I do a lookup for IPA user 0016751and I would expect the groups= attirbute to match those that are listed in the "Member of Groups" from freeipa. I experiemented with the groups attribute and mapping to the memberOf ldap attribute in the IPAuser.map file but that hasn't changed the outcome. If anyone has any pointers or advice it would ge greatly appreciated! AIX Client: 6100-09-04-1441 LDAP Client version: idsldap.clt32bit61.rte 6.1.0.57 COMMITTED Directory Server - 32 bit idsldap.clt_max_crypto32bit61.rte idsldap.cltbase61.adt 6.1.0.57 COMMITTED Directory Server - Base Client idsldap.cltbase61.rte 6.1.0.57 COMMITTED Directory Server - Base Client idsldap.ent61.rte 6.1.0.26 COMMITTED Directory Server - Entitlement idsldap.clt32bit61.rte 6.1.0.57 COMMITTED Directory Server - 32 bit idsldap.cltbase61.rte 6.1.0.57 COMMITTED Directory Server - Base Client IDM Server: RHEL 6.6 x64 ipa-server-3.0.0-42 AIX Client LDAP Config: ldapservers:idm1-corp-p1.idm.abc.com,idm2-corp-p1.idm.abc.com binddn:uid=0016751,cn=users,cn=accounts,dc=idm,dc=abc,dc=com bindpwd:password authtype:ldap_auth userattrmappath:/etc/security/ldap/IPAuser.map groupattrmappath:/etc/security/ldap/IPAgroup.map userbasedn:cn=users,cn=accounts,dc=idm,dc=abc,dc=com groupbasedn:cn=groups,cn=accounts,dc=idm,dc=abc,dc=com #IPAuser.map file keyobjectclass SEC_CHAR posixaccount s na username SEC_CHAR uid s na id SEC_INT idnumber s na pgrp SEC_CHAR gidnumber s na #groups SEC_LIST memberOf m na home SEC_CHAR homedirectory s na shell SEC_CHAR loginshell s na gecos SEC_CHAR gecos s na spassword SEC_CHAR userpassword s na lastupdate SEC_INT shadowlastchange s days #IPAgroup.map file groupname SEC_CHAR cn s na id SEC_INT gidNumber s na users SEC_LIST member m na LDAP User lookup root at aix:/home/root > lsuser -f -R LDAP 0016751 0016751: id=1329001106 pgrp=0016751 groups=0016751 home=/home/0016751 shell=/bin/bash gecos=David Beck login=true su=true rlogin=true daemon=true admin=false sugroups=ALL admgroups= tpath=nosak ttys=ALL expires=0 auth1=SYSTEM auth2=NONE umask=77 registry=LDAP SYSTEM=compat or LDAP logintimes= loginretries=3 pwdwarntime=14 account_locked=false LDAP Group lookup root at aix:/home/root > lsgroup -R LDAP aix-admins aix-admins id=1329004961users=0016066,0016751,0002885,0016896,0016304,0014269,0015513,0015611,0016721registry=LDAP User Group lookup root at aix:/home/root > groups 0016751 0016751 : 0016751 From the IDM server: [root at idm1-corp-p1 ~]# ipa user-show 0016751 User login: 0016751 First name: David Last name: Beck Home directory: /home/0016751 Login shell: /bin/bash Email address: David.Beck at abc.com UID: 1329001106 GID: 1329001106 Telephone Number: 555-555-5555 Job Title: Account disabled: False Password: True Member of groups: unixss, linux-admins, aix-admins, smb-linfs-linadm, tam-admins Roles: IPA Administration Member of Sudo rule: nmap-intaudit Member of HBAC rule: aix-sshd-test Indirect Member of group: smb-linfs Indirect Member of Sudo rule: serverAdmin Indirect Member of HBAC rule: ssh_all, cvs_access Kerberos keys available: True -------------- next part -------------- An HTML attachment was scrubbed... URL: From abokovoy at redhat.com Thu Mar 26 20:37:36 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Thu, 26 Mar 2015 22:37:36 +0200 Subject: [Freeipa-users] AIX client integration In-Reply-To: <6F16433B-6FA8-4D49-A3E4-27FC4518957D@aol.com> References: <6F16433B-6FA8-4D49-A3E4-27FC4518957D@aol.com> Message-ID: <20150326203736.GD3878@redhat.com> On Thu, 26 Mar 2015, David Beck wrote: >All, > >This for anyone using AIX clients with freeipa. I have the client up >and running just fine (No KRB5, AIX Bug); however I cannot seem to get If you mean inability to use GSSAPI authentication against LDAP, it is not a bug in AIX. Rather, it is a bug in CyrusSASL which is fixed in RHEL-6.6.z. We have plans to fix RHEL 7.x too but for your situation an update is going to help. https://rhn.redhat.com/errata/RHBA-2015-0721.html >the client to load the groups attributes properly. The users primary >group shows up in the groups attribute from lsuser but not any >subsequent groups the user is a member of in IPA. In the outputs >below, I do a lookup for IPA user 0016751and I would expect the groups= >attirbute to match those that are listed in the "Member of Groups" from >freeipa. > >I experiemented with the groups attribute and mapping to the memberOf >ldap attribute in the IPAuser.map file but that hasn't changed the >outcome. If anyone has any pointers or advice it would ge greatly >appreciated! Use /var/log/dirsrv/slapd-ABC-COM/access to find out a connection corresponding to AIX operations around your lookups and show all lines with the same conn= element. Ideally, it would help to get a network trace between AIX and IPA LDAP server. Given that you are not using SASL GSSAPI and SSL, it should be easy to see what exactly is requested by AIX and returned by IPA LDAP. -- / Alexander Bokovoy From yamakasi.014 at gmail.com Thu Mar 26 21:11:11 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 26 Mar 2015 22:11:11 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> <55142A54.3010502@redhat.com> Message-ID: Hi, This should be it and worked for generating the cert with the altname ldap.domain.tld When I login and I go to services I get the following: cannot connect to 'https://ldap-01.domain.tld:443/ca/agent/ca/displayBySerial': (SSL_ERROR_BAD_CERT_DOMAIN) Unable to communicate securely with peer: requested domain name does not match the server's certificate. So I'm a little bit confused here as the certificate contains both hostnames. A simple wget says the ldap-01 doesn't exist also: https://ldap-01.domain.tld/ipa/json Connecting to ldap-01.domain.tld (ldap-01.domain.tld)|10.100.0.251|:443... connected. ERROR: no certificate subject alternative name matches requested host name 'ldap-01.domain.tld'. To connect to ldap-01.domain.tld insecurely, use `--no-check-certificate'. 2015-03-26 20:43 GMT+01:00 Matt . : > Hi Rob, > > Thank you very much! > > I think this will work out as it's only https traffic. > > I will report back! > > Thanks a lot! > > Matt > > 2015-03-26 16:48 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> HI Rob, >>> >>> Yes something is wrong there I guess. >> >> In any case, it doesn't apply to what you're trying to do. >> >>> But still, I actually need to add a SAN to the webserver cert, which >>> is different I think than the services at least. >>> >>> So the question there is... how ? >> >> What webserver cert? Are you trying to load balance the IPA services via >> DNS? >> >> Not knowing what you want, I'm just answering what you are ASKING. That >> is not the same as giving a proper answer. I have the feeling you want >> to load balance IPA in general which isn't going to work without a ton >> of (ongoing) manual effort. Even Microsoft recommends against trying >> this in its AD environment: http://support.microsoft.com/en-us/kb/325608 >> >> In any case, the instructions I've already provided still apply. >> >> If you want to replace the Apache webserver cert you'll just need to do >> a couple of things first which has the potential of completely breaking >> IPA, so you'll need to be careful. >> >> Before you do anything, backup *.db in /etc/httpd/alias. >> >> Stop tracking the Apache cert in certmonger: >> >> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert >> >> Delete the existing cert: >> >> # certutil -D -d /etc/httpd/alias -n Server-Cert >> >> Like I said, destructive. >> >> Finally use certmonger to get a new cert that includes a SAN. The syntax >> is slightly different than before, mostly because I'm just guessing in >> the dark because you aren't including enough details into what you're >> trying. >> >> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com >> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt >> >> In this case the IPA server is ipa1.example.com and you're creating a >> SAN for ipa.example.com. >> >> Restart httpd. >> >> Note that this doesn't solve the Kerberos problem so cli access will >> still not work as expected. The UI _might_ work using forms-based >> authentication. >> >> I'd strongly urge you to think about the top of this e-mail before >> proceeding onto the bottom. >> >> rob >> >>> >>> Cheers, >>> >>> Matt >>> >>> 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >>>> Matt . wrote: >>>>> When digging around I see this documentation: >>>>> >>>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>>>> >>>>> I would except that server.example.com is not going to be accepted by >>>>> IPA when you visit the webgui like that ? >>>> >>>> These are SRV records for the ldap service. Think of it as discovery for >>>> who provides ldap service in the domain. It isn't something used by a >>>> web browser. >>>> >>>> I'm no DNS expert (by far) but this example looks a little wonky. I'd >>>> think it should be example.com and not server.example.com. But in any >>>> case it is irrelevant to a browser. >>>> >>>> rob >>>> >> From yamakasi.014 at gmail.com Thu Mar 26 21:30:02 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 26 Mar 2015 22:30:02 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> <55142A54.3010502@redhat.com> Message-ID: OK some new update: When I do a curl -k https://ldap.domain.tld/ipa/config/ca.crt I get a 301 to https://ldap-01.core.prod.msp.cullie.local/ipa/config/ca.crt But when I visit the https://ldap.domain.tld/ipa/config/ca.crt with my browser it just works fine. 2015-03-26 22:11 GMT+01:00 Matt . : > Hi, > > This should be it and worked for generating the cert with the altname > ldap.domain.tld > > When I login and I go to services I get the following: > > cannot connect to > 'https://ldap-01.domain.tld:443/ca/agent/ca/displayBySerial': > (SSL_ERROR_BAD_CERT_DOMAIN) Unable to communicate securely with peer: > requested domain name does not match the server's certificate. > > So I'm a little bit confused here as the certificate contains both hostnames. > > A simple wget says the ldap-01 doesn't exist also: > > https://ldap-01.domain.tld/ipa/json > Connecting to ldap-01.domain.tld > (ldap-01.domain.tld)|10.100.0.251|:443... connected. > ERROR: no certificate subject alternative name matches > requested host name 'ldap-01.domain.tld'. > To connect to ldap-01.domain.tld insecurely, use `--no-check-certificate'. > > > > 2015-03-26 20:43 GMT+01:00 Matt . : >> Hi Rob, >> >> Thank you very much! >> >> I think this will work out as it's only https traffic. >> >> I will report back! >> >> Thanks a lot! >> >> Matt >> >> 2015-03-26 16:48 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> HI Rob, >>>> >>>> Yes something is wrong there I guess. >>> >>> In any case, it doesn't apply to what you're trying to do. >>> >>>> But still, I actually need to add a SAN to the webserver cert, which >>>> is different I think than the services at least. >>>> >>>> So the question there is... how ? >>> >>> What webserver cert? Are you trying to load balance the IPA services via >>> DNS? >>> >>> Not knowing what you want, I'm just answering what you are ASKING. That >>> is not the same as giving a proper answer. I have the feeling you want >>> to load balance IPA in general which isn't going to work without a ton >>> of (ongoing) manual effort. Even Microsoft recommends against trying >>> this in its AD environment: http://support.microsoft.com/en-us/kb/325608 >>> >>> In any case, the instructions I've already provided still apply. >>> >>> If you want to replace the Apache webserver cert you'll just need to do >>> a couple of things first which has the potential of completely breaking >>> IPA, so you'll need to be careful. >>> >>> Before you do anything, backup *.db in /etc/httpd/alias. >>> >>> Stop tracking the Apache cert in certmonger: >>> >>> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert >>> >>> Delete the existing cert: >>> >>> # certutil -D -d /etc/httpd/alias -n Server-Cert >>> >>> Like I said, destructive. >>> >>> Finally use certmonger to get a new cert that includes a SAN. The syntax >>> is slightly different than before, mostly because I'm just guessing in >>> the dark because you aren't including enough details into what you're >>> trying. >>> >>> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com >>> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt >>> >>> In this case the IPA server is ipa1.example.com and you're creating a >>> SAN for ipa.example.com. >>> >>> Restart httpd. >>> >>> Note that this doesn't solve the Kerberos problem so cli access will >>> still not work as expected. The UI _might_ work using forms-based >>> authentication. >>> >>> I'd strongly urge you to think about the top of this e-mail before >>> proceeding onto the bottom. >>> >>> rob >>> >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >>>>> Matt . wrote: >>>>>> When digging around I see this documentation: >>>>>> >>>>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>>>>> >>>>>> I would except that server.example.com is not going to be accepted by >>>>>> IPA when you visit the webgui like that ? >>>>> >>>>> These are SRV records for the ldap service. Think of it as discovery for >>>>> who provides ldap service in the domain. It isn't something used by a >>>>> web browser. >>>>> >>>>> I'm no DNS expert (by far) but this example looks a little wonky. I'd >>>>> think it should be example.com and not server.example.com. But in any >>>>> case it is irrelevant to a browser. >>>>> >>>>> rob >>>>> >>> From yamakasi.014 at gmail.com Thu Mar 26 21:37:33 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 26 Mar 2015 22:37:33 +0100 Subject: [Freeipa-users] Log filling up a couple of times per day Message-ID: Hi Guys, I'm facing every day a fast filling log of: /var/log/krb5kdc.log /var/log/dirsrv/slapd-DOMAIN/access* I need to remove the files and restart ipa. The kerberos log is filling up most, the access logs are quite fast on 100MB and a new one is created. Now I do some LDAP loging/logout per day, servers that chedck if they are registered for SSSD so that it logs it is normal, but I want to get rid of it I guess. I'm throwing out I think about 6GB per day of logs, all loglevels are low. Any idea ? It's 3.x on CentOS 6.6 Any idea ? Thanks Matt From dpal at redhat.com Thu Mar 26 21:59:18 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 26 Mar 2015 17:59:18 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: References: Message-ID: <55148136.8040003@redhat.com> On 03/26/2015 02:29 PM, Prasun Gera wrote: > Hello, > I followed > https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords > in order to migrate our NIS installation, and for the most part it > worked. The server responds to ypcat from the NIS clients, and users > can log in. However, I'm seeing a couple of weird issues. Normally, > ypcat returns "username:cryptpass:uid:gid:gecos:homedir:shell" for > users and authentication works fine. For new users that were added > directly to IPA, instead of the cryptpass, I see an asterisk(*), which > is also understandable. However, for a couple of migrated users, I'm > seeing that their cyrptpasses have also been replaced with *s (in > ypcat's output) over the course of time. This creates problems for > authentication on clients that haven't been migrated, and they can't > log in with their passwords. These users didn't explicitly call kinit > or go to the webui for migration. Is it normal for the crypt passes to > be replaced by *? I migrated a couple of clients, and these users > would have sshed to the migrated clients or possibly to the server. > That didn't seem to affect ypcat's behaviour directly, and yet that is > the only thing I can think of that has any connection to this. > > Regards, > Prasun > > Based on what you describe I assume that you: - Migrated users to IPA - Enabled slapi-nis plugin - Use old clients with slapi-nis as a NIS server and expect to be able to authenticate with new and old users against IPA NIS map. Right? So the authentication does not work and this is by design since passwords in files are insecure and distributing them centrally as NIS did is security problem. The suggestion is to change the authentication method on old clients to LDAP or Kerberos first, whatever they support (they usually do even if they are quite old), and leave NIS for identity information only since some old clients do not support LDAP for that part and only support NIS. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Thu Mar 26 22:01:30 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 26 Mar 2015 18:01:30 -0400 Subject: [Freeipa-users] Log filling up a couple of times per day In-Reply-To: References: Message-ID: <551481BA.10605@redhat.com> On 03/26/2015 05:37 PM, Matt . wrote: > Hi Guys, > > I'm facing every day a fast filling log of: > > /var/log/krb5kdc.log > /var/log/dirsrv/slapd-DOMAIN/access* > > I need to remove the files and restart ipa. The kerberos log is > filling up most, the access logs are quite fast on 100MB and a new one > is created. > > Now I do some LDAP loging/logout per day, servers that chedck if they > are registered for SSSD so that it logs it is normal, but I want to > get rid of it I guess. > > I'm throwing out I think about 6GB per day of logs, all loglevels are low. > > Any idea ? > > It's 3.x on CentOS 6.6 > > Any idea ? > > Thanks Matt > Do you have some services that are repeatedly doing something kerberos related and failing? I guess getting a snippet of the kerberos log would give some hint on what is it logging all the time. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Mar 26 22:08:20 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 26 Mar 2015 18:08:20 -0400 Subject: [Freeipa-users] inserting users via java In-Reply-To: References: <7ABDD08F-740F-420F-865C-60C8F933A0BC@thetimmy.com> <5510AFDA.2020602@redhat.com> <55111922.8010705@redhat.com> <4B09C1ED-6E47-4DD1-B462-0539CE75DDC7@thetimmy.com> <55145326.80600@redhat.com> Message-ID: <55148354.9020405@redhat.com> On 03/26/2015 03:19 PM, Timothy Worman wrote: > On Mar 26, 2015, at 11:42 AM, Martin Kosek wrote: >> On 03/26/2015 07:37 PM, Timothy Worman wrote: >>> Thanks everyone for the input. >>> >>> I do agree that I don?t like the sound of option 1. I don?t want to be sending CLI commands from a remote host. And option 3 sounds sounds a bit brittle to me. >>> >>> 2 sounds like the most solid option available right now. I like the fact that there?s an existing/working API there. I?ll need to look into converting my objects into json. >>> >>> This area honestly seems like one of the weakest aspects of freeipa. There really needs to be a way to push known person entities into the directory easily. >> There may be some disconnect, the JSONRPC/XMLRPC API is the way we still see as an easy way to manipulate the entries (besides CLI and Web UI). In Python, adding new user is that easy: >> >> ~~~ >> from ipalib import api >> from ipalib import errors >> >> api.bootstrap(context='cli') >> api.finalize() >> api.Backend.rpcclient.connect() >> api.Command['user_add'](u'newuser', givenname=u'New', sn=u'User') >> ~~~ >> >> What way would you suggest to make it more conforming to your use case? Are you suggesting REST interface doing the above or something else? > Oh, I think the JSON option is the best one currently available. But I do think REST-ful service would be a good idea. > >> I would be willing to test option 4 if that is where the future is headed. >> >> Ok, just note that this still means LDAP interface a need to talk in LDAP protocol. > This may not be a bad thing if you?re using an ORM like Webobjects/EOF or Cayenne since you can model those ldap entities and simply set their attributes and insert. At a lower level JNDI will handle it. I personally prefer this over building strings, sending commands, etc. So this will be ready upstream within several weeks or so. Would you test it once it it is available before the official upstream release? > Tim > >>> Tim >>> >>>> On Mar 24, 2015, at 12:58 AM, Martin Kosek wrote: >>>> >>>> On 03/24/2015 01:29 AM, Dmitri Pal wrote: >>>>> On 03/23/2015 05:56 PM, Timothy Worman wrote: >>>>>> I have an existing web app built with java/WebObjects that currently handles >>>>>> some user/groups tasks with our current directory server (Open Directory). We >>>>>> are investigating a move to FreeIPA for our directory services. >>>>>> >>>>>> Just in mucking around, I?ve found that if I try to insert a new user >>>>>> (inetOrgPerson) into into IPA?s implementation, the new user does not inherit >>>>>> all the object classes it should. It only inherits the ones leading to >>>>>> inetOrgPerson. This does result in a successful inetOrgPerson insertion, but >>>>>> that user record does not show up in the Web GUI management tools. >>>>>> >>>>>> Usually, I have focused on inetOrgPerson because that is where the bulk of >>>>>> the info about a user lives. >>>>>> >>>>>> We have a SQL database that contains people in our organization (used by >>>>>> other services), so, we need to be able to leverage that and push users into >>>>>> IPA when appropriate and we have an existing app to do this. >>>>>> >>>>>> Tim W >>>>>> >>>>> You have several options: >>>>> 1) Call ipa CLI from your application - this is possible right now (but not >>>>> quite nice) >>>>> 2) Call ipa JSON API from your application - this is not supported but >>>>> possible. We use python API. You can do it in Java but it will be a lot of work. >>>>> 3) Use more elaborate LDAP add commands (with all the object classes needed for >>>>> users). Hard, but doable. >>>>> 4) Help us with testing the upcoming feature >>>>> http://www.freeipa.org/page/V4/User_Life-Cycle_Management that would allow >>>>> creating users via simple ldap command in a staging area and them moving them >>>>> to normal users area with automatic creation of missing attributes by means of >>>>> a cron job. >>>>> >>>>> I would vote for 1) as a temp solution and 4) as a longer term one. >>>> I do not fully agree with preferring 1) over 2). Java has libraries for >>>> JSON-RPC protocol, it should be pretty doable to write a call that calls the >>>> "user_add" command. >>>> >>>> We are lacking proper documentation for the API, but what you can look in the >>>> sources or in the Web UI with and see the JSONs sent to the server, if you are >>>> interested in the real life examples. >>>> >>>> Advantage of 2) over 1) is that you get the native objects (strings, arrays, >>>> numbers) and you do not need to parse it from CLI. >>>> >>>> Martin -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Thu Mar 26 22:14:35 2015 From: dpal at redhat.com (Dmitri Pal) Date: Thu, 26 Mar 2015 18:14:35 -0400 Subject: [Freeipa-users] Is systemd really a requirement for freeipa 4.x? In-Reply-To: <20150326121838.Horde.8fNc4Ax9Ajb_IlzaIINjGQ1@webmail01.coyhile.com> References: <20150325162205.Horde.6uylo0jbT6IXV966x7Iecg7@webmail01.coyhile.com> <5512F334.5050000@redhat.com> <55134AE3.7090209@redhat.com> <20150326121838.Horde.8fNc4Ax9Ajb_IlzaIINjGQ1@webmail01.coyhile.com> Message-ID: <551484CB.60704@redhat.com> On 03/26/2015 08:18 AM, Coy Hile wrote: > > Quoting Andrew Holway : > >>> >>> When I look at the SPEC file for freeipa-4.1.3, I see requirements >>>>> around Systemd. Is that really a hard requirement, or is it >>>>> possible to >>>>> run newer FreeIPA (that is to say 4.x) on a host that hasn't been >>>>> infested by systemd >>>> >>>> >>> From an SELinux standpoint systemd is far superior to initd as it >>> allows >> far more graceful domain transitions. >> >> Apart from the binary logging and it being a bit monolithic; I really >> don't >> understand the anit-systemd crowd problems. Its advantages over the now >> ancient initd seem to be obvious. > > > The binary logging is a big problem. Log to the filesystem usefully, > or log to > syslog. Then one can get that data into Splunk or similar. Aside from > that, > systemd feels like the answer to the question no one asked. It's a > bit like > what Oracle has done to bastardize smf(5) in Oracle Solaris 11 over > what was > there in Solaris 10 (and the former OpenSolaris, now illumos). The S10 > incarnation was awesome, even though the definition of service > manifests in xml > makes me want to claw my eyes out. Oracle's Microsoftened embrace and > extend? > Yeah, not so much.... > > For full disclosure here, the reason I was enquiring about support on > CentOS 6 is > because my virtualization platform of choice is SmartOS. For CentOS 6 > and Ubuntu > 14.04, I am able to use a 'Branded zone' natively without having to > add the KVM > hardware emulation layer in there, implying better network and IO > performance. > That said, for this particular case, the KVM overhead really doesn't > matter since > a box that's only doing LDAP and kerb really needn't be all that > beefy. Hell, I > could probably run an authoritative KDC for ATHENA.MIT.EDU on an rpi > if I were so > inclined. > > > Understanding the reason behind the requirements is quite helpful, so > thanks to all > who provided that. I'll work with Joyent to add systemd support to > the lx brand, > and in the meantime, I'll just deploy on KVM infrastructure and take > the hit. I > assume there's no good reason to deploy a net new setup using the 3.x > release? > > -c We recommend using latest - 4.1. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From david.kreuter at bytesource.net Thu Mar 26 22:18:59 2015 From: david.kreuter at bytesource.net (David Kreuter) Date: Thu, 26 Mar 2015 23:18:59 +0100 (CET) Subject: [Freeipa-users] Unexpected IPA Crashes In-Reply-To: <9b588bad-91eb-45ae-be48-b9725e9beb1e@zimbra.bytesource.net> Message-ID: We have been using FreeIPA since two years and were more than happy. But since two weeks we are facing unexpected crashed and can not really debug the strange behaviours. The crashes are definitely not caused by connecting a new system or changing the LDAP schema heavily. Following IPA is used: Name : ipa-server Arch : x86_64 Version : 3.3.3 Release : 28.0.1.el7.centos.3 Size : 4.1 M I have followed the troubleshooting guide http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting and activated logging and activated the core dumping. Unfortunately, I cannot provide you any core dump, because it is not created after the ipa servers crashes. I'm sure the dirsrv is causing the problem, because when i restart the 389, then ipa works fine for a while. Currently I have activated the replication log level 8192. The error log shows no suspicious error or any fatal error. Following 389* versions are used: Installed Packages 389-ds-base.x86_64 1.3.3.1-15.el7_1 @/389-ds-base-1.3.3.1-15.el7_1.x86_64 389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo 389-ds-base-libs.x86_64 1.3.3.1-15.el7_1 Can you please provide some hint how I can debug this problem in more detail. Btw, the ipa infrastructure consist of one master and one replica. The server was also crashing, when the replica server was turned off. Do you thing an upgrade would solve the problem as the last resort? -------------- next part -------------- An HTML attachment was scrubbed... URL: From prasun.gera at gmail.com Thu Mar 26 22:42:02 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Thu, 26 Mar 2015 18:42:02 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: <55148136.8040003@redhat.com> References: <55148136.8040003@redhat.com> Message-ID: Yes, that is right. I added the users with ipa user-add [username] --setattr userpassword={crypt}yourencryptedpass Actually, the authentication does work for the users added this way. i.e. Without making any changes to NIS clients. I just repurposed the NIS server to be the IPA server, turned off the ypserv & yppasswd service, and enabled the slapi-nis plugin. So far so good, and the NIS clients continue to function normally. i.e. The NIS plugin on the IPA server DOES distribute the cryptpasses. I also didn't expect the old NIS clients to authenticate any new users added to IPA directly, and that is all right. I just want the clients to function for the existing users until they are migrated. The only thing that is slightly puzzling is that a couple of users have been migrated unintentionally, so to speak. A user can be explicitly migrated to IPA if (s)he generates the kerberos keys, at which point the slapi-nis stops distributing the crypt pass for that user. This is what I have observed so far, and it sounds reasonable. (This can also be confirmed with ipa user-show, which in case of these old users shows "Kerberos keys available: False", which turns to True once properly migrated. It can also be confirmed from the webui. The old password won't work in the webui until migrated, and once migrated, NIS cryptpasses will stop working). However, what I'm seeing is that in a couple of cases, the users have been migrated to IPA automatically. Their status shows Kerberos keys available: True, and their cryptpasses have changed to * in ypcat passwd's output. On Thu, Mar 26, 2015 at 5:59 PM, Dmitri Pal wrote: > On 03/26/2015 02:29 PM, Prasun Gera wrote: > > Hello, > I followed > https://www.freeipa.org/page/NIS_accounts_migration_preserving_Passwords > in order to migrate our NIS installation, and for the most part it worked. > The server responds to ypcat from the NIS clients, and users can log in. > However, I'm seeing a couple of weird issues. Normally, ypcat returns > "username:cryptpass:uid:gid:gecos:homedir:shell" for users and > authentication works fine. For new users that were added directly to IPA, > instead of the cryptpass, I see an asterisk(*), which is also > understandable. However, for a couple of migrated users, I'm seeing that > their cyrptpasses have also been replaced with *s (in ypcat's output) over > the course of time. This creates problems for authentication on clients > that haven't been migrated, and they can't log in with their passwords. > These users didn't explicitly call kinit or go to the webui for migration. > Is it normal for the crypt passes to be replaced by *? I migrated a couple > of clients, and these users would have sshed to the migrated clients or > possibly to the server. That didn't seem to affect ypcat's behaviour > directly, and yet that is the only thing I can think of that has any > connection to this. > > Regards, > Prasun > > > > Based on what you describe I assume that you: > - Migrated users to IPA > - Enabled slapi-nis plugin > - Use old clients with slapi-nis as a NIS server and expect to be able to > authenticate with new and old users against IPA NIS map. > > Right? > > So the authentication does not work and this is by design since passwords > in files are insecure and distributing them centrally as NIS did is > security problem. > The suggestion is to change the authentication method on old clients to > LDAP or Kerberos first, whatever they support (they usually do even if they > are quite old), and leave NIS for identity information only since some old > clients do not support LDAP for that part and only support NIS. > > -- > 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 yamakasi.014 at gmail.com Thu Mar 26 22:54:09 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Thu, 26 Mar 2015 23:54:09 +0100 Subject: [Freeipa-users] Log filling up a couple of times per day In-Reply-To: <551481BA.10605@redhat.com> References: <551481BA.10605@redhat.com> Message-ID: Hi Dimitri, I can do, we already analyzed it once. There is a loadbalancer checking the ldap protocol which seems to be seen as fail. Is there a check I can perform on the ldap ports to see if the service is available without generating the errors ? I will post a snippet later on if you have no clue. Thanks, Matt 2015-03-26 23:01 GMT+01:00 Dmitri Pal : > On 03/26/2015 05:37 PM, Matt . wrote: >> >> Hi Guys, >> >> I'm facing every day a fast filling log of: >> >> /var/log/krb5kdc.log >> /var/log/dirsrv/slapd-DOMAIN/access* >> >> I need to remove the files and restart ipa. The kerberos log is >> filling up most, the access logs are quite fast on 100MB and a new one >> is created. >> >> Now I do some LDAP loging/logout per day, servers that chedck if they >> are registered for SSSD so that it logs it is normal, but I want to >> get rid of it I guess. >> >> I'm throwing out I think about 6GB per day of logs, all loglevels are low. >> >> Any idea ? >> >> It's 3.x on CentOS 6.6 >> >> Any idea ? >> >> Thanks Matt >> > Do you have some services that are repeatedly doing something kerberos > related and failing? > I guess getting a snippet of the kerberos log would give some hint on what > is it logging all the time. > > -- > 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 lundman at lundman.net Fri Mar 27 01:02:58 2015 From: lundman at lundman.net (Jorgen Lundman) Date: Fri, 27 Mar 2015 10:02:58 +0900 Subject: [Freeipa-users] bind-dyndb-ldap vs DLZ In-Reply-To: <5513D7D6.7070408@redhat.com> References: <55122F5F.8030505@lundman.net> <55126655.30109@redhat.com> <551351F8.5070508@lundman.net> <5513D7D6.7070408@redhat.com> Message-ID: <5514AC42.80205@lundman.net> Petr Spacek wrote: > > Perfect! I can merge your changes upstream if you send me a patch with your > changes. It would make your life easier later when you need to pick new code. Not a problem, I need to figure out why Solaris mkdir returns -1, with errno = 0. Goes against the manpage and all logic. Checking for ||errno==0 after mkdir "fixes" it but it is still odd. I also compiled without krb5. It basically compiled, but running would fail to find gss/mech_krb5.so - no idea how that is supposed to link, but since it was a quick test, I just took it out. Otherwise it compiled smoothly, some minor linux-ism with linker flags. > > Hmm, that might be a challenge. bind-dyndb-ldap code implicitly assumes that > there is 1:1 mapping between DNS name<->LDAP DN. This makes implementation of > dynamic updates much easier. Actually yes, I did mean to ask about this too. DLZ-LDAP is pretty much a read-only setup (for us), so a quick scan of the sources led me to believe that simple string replacement of "idnsName" with "DNSZoneName" (and of course, all the others), should get "a large chunk" of it done. The schemas are quite close, on a whole.. But I was surprised to see bind-dyndb actually modify the LDAP data, for my test, just "idnsSOAserial". What is the purpose of this? I would guess for zone xfers? By why update LDAP (and not just internal DNS memory), if you essentially do not use it on restart (just gets updated again on restart, from the looks of it?) >> the same delay each time I start it. slapd is running on localhost, and is >> otherwise idle. > > Hmm, that stinks! I would be happy to look into it if you can provide me with > output from a profiler of your choice. (It might be a good idea to profile > bind-dyndb-ldap together with whole named process to see all the interactions.) It is in line with what we experience with LDAP generally. If I blow away the DNS-ldap tree, a full syncrepl update takes about 1 hour. If I remove the whole LDAP tree, about 4 hours. It is not something that goes faster with more threads afaik. >> Is it supposed to be able to use the "dump-file" on exit for faster loads? > > Yes, something like that is planned but not implemented yet. Ah ok great, good to know it is planned. We could probably live with 50 mins startup time, as there are 28 servers in the DNS cluster. Just needs some care in case they are restarted, or worse, some bug causes coredump which affects all of them >> [3] >> However, that has a side-effect that, once bind-dyndb is loaded, it will >> also query DLZ+LDAP on negative entries. Thus decreasing the performance to >> 3884qps. Wonder if there is a way to have bind-dyndb ignore DLZ+LDAP /once >> it has loaded/. > > Wow, I'm surprised that this combination actually works! I expect that there > will be some nasty surprises in there, especially when it comes to dynamic > updates. I must admit it would be tempting to see if bind-dyndb could issue a definitive reply (once loaded) for both positive and negative lookups, thereby causing DLZ-LDAP to be inert. Or making it a feature of bind-dyndb to use DLZ-LDAP during load. But only in the case that they both use the same schema and source tree in LDAP. Feels a bit hackish but just evaluating possible solutions. -- Jorgen Lundman | Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) From rmeggins at redhat.com Fri Mar 27 01:15:09 2015 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 26 Mar 2015 21:15:09 -0400 (EDT) Subject: [Freeipa-users] Unexpected IPA Crashes In-Reply-To: References: Message-ID: <1321154940.5816968.1427418909379.JavaMail.zimbra@redhat.com> ----- Original Message ----- > We have been using FreeIPA since two years and were more than happy. But > since two weeks we are facing unexpected crashed and can not really debug > the strange behaviours. The crashes are definitely not caused by connecting > a new system or changing the LDAP schema heavily. Following IPA is used: > > > > Name : ipa-server > > Arch : x86_64 > > Version : 3.3.3 > > Release : 28.0.1.el7.centos.3 > > Size : 4.1 M > > > > > I have followed the troubleshooting guide > http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting > and activated logging and activated the core dumping. Do you see the string "segfault" in /var/log/messages or in journalctl? > Unfortunately, I > cannot provide you any core dump, because it is not created after the ipa > servers crashes. I'm sure the dirsrv is causing the problem, because when i > restart the 389, then ipa works fine for a while. Currently I have activated > the replication log level 8192. The error log shows no suspicious error or > any fatal error. Following 389* versions are used: > > > > > Installed Packages > > 389-ds-base.x86_64 1.3.3.1-15.el7_1 @/389-ds-base-1.3.3.1-15.el7_1.x86_64 > > 389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo > > > > 389-ds-base-libs.x86_64 1.3.3.1-15.el7_1 > > > > > Can you please provide some hint how I can debug this problem in more detail. > Btw, the ipa infrastructure consist of one master and one replica. The > server was also crashing, when the replica server was turned off. Do you > thing an upgrade would solve the problem as the last resort? > > > > -- > 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 Fri Mar 27 01:19:32 2015 From: rmeggins at redhat.com (Richard Megginson) Date: Thu, 26 Mar 2015 21:19:32 -0400 (EDT) Subject: [Freeipa-users] Log filling up a couple of times per day In-Reply-To: References: <551481BA.10605@redhat.com> Message-ID: <554255292.5817609.1427419172653.JavaMail.zimbra@redhat.com> ----- Original Message ----- > Hi Dimitri, > > I can do, we already analyzed it once. > > There is a loadbalancer checking the ldap protocol which seems to be > seen as fail. > > Is there a check I can perform on the ldap ports to see if the service > is available without generating the errors ? If you just need to check ldap i.e. that port 389 is listening: ldapsearch -xLLL -h ldaphost -s base -b "" "objectclass=*" 1.1 That will still log to the directory server access log. > > I will post a snippet later on if you have no clue. > > Thanks, > > Matt > > 2015-03-26 23:01 GMT+01:00 Dmitri Pal : > > On 03/26/2015 05:37 PM, Matt . wrote: > >> > >> Hi Guys, > >> > >> I'm facing every day a fast filling log of: > >> > >> /var/log/krb5kdc.log > >> /var/log/dirsrv/slapd-DOMAIN/access* > >> > >> I need to remove the files and restart ipa. The kerberos log is > >> filling up most, the access logs are quite fast on 100MB and a new one > >> is created. > >> > >> Now I do some LDAP loging/logout per day, servers that chedck if they > >> are registered for SSSD so that it logs it is normal, but I want to > >> get rid of it I guess. > >> > >> I'm throwing out I think about 6GB per day of logs, all loglevels are low. > >> > >> Any idea ? > >> > >> It's 3.x on CentOS 6.6 > >> > >> Any idea ? > >> > >> Thanks Matt > >> > > Do you have some services that are repeatedly doing something kerberos > > related and failing? > > I guess getting a snippet of the kerberos log would give some hint on what > > is it logging all the time. > > > > -- > > 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 > > -- > 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 Mar 27 03:01:24 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Thu, 26 Mar 2015 23:01:24 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: References: <55148136.8040003@redhat.com> Message-ID: <5514C804.4040207@redhat.com> Prasun Gera wrote: > Yes, that is right. I added the users with ipa user-add [username] > --setattr userpassword={crypt}yourencryptedpass > > Actually, the authentication does work for the users added this way. > i.e. Without making any changes to NIS clients. I just repurposed the > NIS server to be the IPA server, turned off the ypserv & yppasswd > service, and enabled the slapi-nis plugin. So far so good, and the NIS > clients continue to function normally. i.e. The NIS plugin on the IPA > server DOES distribute the cryptpasses. I also didn't expect the old NIS > clients to authenticate any new users added to IPA directly, and that is > all right. I just want the clients to function for the existing users > until they are migrated. The only thing that is slightly puzzling is > that a couple of users have been migrated unintentionally, so to speak. > > A user can be explicitly migrated to IPA if (s)he generates the kerberos > keys, at which point the slapi-nis stops distributing the crypt pass for > that user. This is what I have observed so far, and it sounds > reasonable. (This can also be confirmed with ipa user-show, which in > case of these old users shows "Kerberos keys available: False", which > turns to True once properly migrated. It can also be confirmed from the > webui. The old password won't work in the webui until migrated, and once > migrated, NIS cryptpasses will stop working). > > However, what I'm seeing is that in a couple of cases, the users have > been migrated to IPA automatically. Their status shows Kerberos keys > available: True, and their cryptpasses have changed to * in ypcat > passwd's output. The passwords will only show if they are in {crypt} format. If the password is changed in IPA it will use the default 389-ds password scheme which is a salted SHA. It may be, though I didn't think this was the case, that the password is being re-hashed during kerberos key generation. How long will you need to keep these legacy systems? This sharing of the password hashes is one of the (many) reasons people are migrating from NIS. A fix may be to change the 389-ds password hashing scheme to crypt but that may just let these NIS systems linger forever. So it's the typical balance of usability vs security. rob From yks0000 at gmail.com Fri Mar 27 04:58:13 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Fri, 27 Mar 2015 10:28:13 +0530 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: <20150326151522.GU30085@hendrix.arn.redhat.com> References: <1427377221.8302.78.camel@willson.usersys.redhat.com> <20150326142542.GT30085@hendrix.arn.redhat.com> <20150326151522.GU30085@hendrix.arn.redhat.com> Message-ID: Hi Jakub, Please find the logs for the user "test" created in IPA. (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [] (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [4097][1][name=test] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [] (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search] (0x0100): Requesting info for [test at sd.int] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [4099][1][name=test] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search] (0x0100): Requesting info for [test at sd.int] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [1][1][name=test] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging sd.int (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging nss (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging pam (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging pac (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pam replied to ping (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pac replied to ping (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service ssh replied to ping (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service nss replied to ping (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service sd.int replied to ping (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [] (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [] (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [test] from [] (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [test at sd.int] (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): entering pam_cmd_authenticate (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16634 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [be_get_account_info] (0x0100): Got request for [3][1][name=test] (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse domain SID from [(null)] (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [test at sd.int] (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 1 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16634 (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): Request processed. Returned 0,0,Success (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got request with the following data (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): command: PAM_AUTHENTICATE (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): user: test (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): ruser: (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): authtok type: 1 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): cli_pid: 16634 (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sss_krb5_cc_verify_ccache] (0x0020): 1078: [-1765328190][Credentials cache permissions incorrect] (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [check_old_ccache] (0x0040): Cannot check if saved ccache FILE:/tmp/krb5cc_1312800003_LTtoQU is valid (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [krb5_auth_send] (0x0020): check_if_ccache_file_is_used failed. (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'IPA' (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [unpack_buffer] (0x0100): cmd [241] uid [1312800011] gid [1312800011] validate [true] enterprise principal [false] offline [false] UPN [test at SD.INT] (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [unpack_buffer] (0x0100): ccname: [FILE:/tmp/krb5cc_1312800011_XXXXXX] keytab: [/etc/krb5.keytab] (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] from environment. (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from environment. (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [k5c_setup_fast] (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ dns-inf-stg-sg1-01.sd.int at SD.INT] *(Fri Mar 27 10:19:58 2015) [[sssd[krb5_child[16637]]]] [get_and_save_tgt] (0x0020): 981: [-1765328361][Password has expired]* *(Fri Mar 27 10:20:01 2015) [[sssd[krb5_child[16637]]]] [map_krb5_error] (0x0020): 1043: [-1765328360][Preauthentication failed]* (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [child_sig_handler] (0x0100): child [16637] finished successfully. (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [ipa_get_migration_flag_done] (0x0100): Password migration is not enabled. (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 17, ) [Success] (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Sending result [17][sd.int] (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Sent result [17][sd.int] (Fri Mar 27 10:20:01 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [17][sd.int] *We do not see any of the above error when try to login with "admin" user created by IPA and able to login. Seems like there is any issue in creating user from our side, though not able to figure out.* (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_cmd_acct_mgmt] (0x0100): entering pam_cmd_acct_mgmt (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got request with the following data (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): command: PAM_ACCT_MGMT (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): ruser: (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [ipa_hbac_evaluate_rules] (0x0080): Access granted by HBAC rule [allow_all] (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, ) [Success] (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Backend returned: (0, 0, Success) [Success] (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Sending result [0][sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_cmd_setcred] (0x0100): entering pam_cmd_setcred (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_SETCRED (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_SETCRED (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] (0x0100): Sent result [0][sd.int] (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got request with the following data (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): command: PAM_SETCRED (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): ruser: (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Sending result [0][sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][sd.int] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_cmd_open_session] (0x0100): entering pam_cmd_open_session (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got request with the following data (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): command: PAM_OPEN_SESSION (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): ruser: (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): priv: 1 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): cli_pid: 16680 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Sending result [0][sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][sd.int] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): Requesting info for [admin] from [] (Fri Mar 27 10:23:52 2015) [sssd[nss]] [nss_cmd_initgroups_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_cmd_setcred] (0x0100): entering pam_cmd_setcred (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_SETCRED (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16684 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_check_user_search] (0x0100): Requesting info for [admin at sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending request with the following data: (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): command: PAM_SETCRED (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: not set (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 0 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: 16684 (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): pam_dp_send_req returned 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Got request with the following data (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): command: PAM_SETCRED (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): domain: sd.int (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): user: admin (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): service: sshd (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): tty: ssh (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): ruser: (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): rhost: 125.63.90.34 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): authtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): newauthtok type: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): priv: 0 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): cli_pid: 16684 (Fri Mar 27 10:23:52 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): Sending result [0][sd.int] (Fri Mar 27 10:23:52 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): received: [0][sd.int] Apologies of using bold letters. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Thu, Mar 26, 2015 at 8:45 PM, Jakub Hrozek wrote: > On Thu, Mar 26, 2015 at 08:05:03PM +0530, Yogesh Sharma wrote: > > Hi Jakub, > > > > SSSD prompted to change the password. After changing the password, when > we > > try to ssh again using the new password, it failed. > > And what do the logs say then, with the new password? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From janellenicole80 at gmail.com Fri Mar 27 05:23:04 2015 From: janellenicole80 at gmail.com (Janelle) Date: Thu, 26 Mar 2015 22:23:04 -0700 Subject: [Freeipa-users] LDAP/IPA pw - not pre-expired Message-ID: <5514E938.1070000@gmail.com> Hi again, I can't seem to find it. Is there a way to create a new user with a non-expired PW? ~J From lundman at lundman.net Fri Mar 27 06:45:56 2015 From: lundman at lundman.net (Jorgen Lundman) Date: Fri, 27 Mar 2015 15:45:56 +0900 Subject: [Freeipa-users] bind-dyndb-ldap vs DLZ In-Reply-To: <5513D7D6.7070408@redhat.com> References: <55122F5F.8030505@lundman.net> <55126655.30109@redhat.com> <551351F8.5070508@lundman.net> <5513D7D6.7070408@redhat.com> Message-ID: <5514FCA4.9050909@lundman.net> > Hmm, that stinks! I would be happy to look into it if you can provide me with > output from a profiler of your choice. (It might be a good idea to profile > bind-dyndb-ldap together with whole named process to see all the interactions.) > Hold those horses. I must admit this timing didn't sit right with me, the more I thought about it. Since my test was all new, I created a slapd.conf from scratch. Forgot all about entryUUID index! I took out the creations of the empty master/$domain/keys directories. We don't use any of that. I noticed that its not the syncrepl that is slow, it is the MOD update of all idnsSOAserial. Unfortunately, they are all on one connection, so increasing arg "connections 15"; does not help. I took out the updates of idnsSOAserial by making ldap_replace_serial(return ISC_R_SUCCESS); Startup time is just under 2 minutes. I can certainly live with that. Just go to work out if we can actually use it without idnsSOAserial or not. We have just ldap master using syncrepl to each DNS server's local slapd. Then named to use that. No xfers, no slaves etc. Shutdown is still slow, but that appears to be a Solaris bug, after all zones are shutdown and listening ports released, it sits around calling lwp_park and unpark for 10 minutes. I can debug that later. -- Jorgen Lundman | Unix Administrator | +81 (0)3 -5456-2687 ext 1017 (work) Shibuya-ku, Tokyo | +81 (0)90-5578-8500 (cell) Japan | +81 (0)3 -3375-1767 (home) From jhrozek at redhat.com Fri Mar 27 07:02:05 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 27 Mar 2015 08:02:05 +0100 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: <1427377221.8302.78.camel@willson.usersys.redhat.com> <20150326142542.GT30085@hendrix.arn.redhat.com> <20150326151522.GU30085@hendrix.arn.redhat.com> Message-ID: <20150327070205.GA2903@hendrix.redhat.com> On Fri, Mar 27, 2015 at 10:28:13AM +0530, Yogesh Sharma wrote: > Hi Jakub, > > Please find the logs for the user "test" created in IPA. > > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [test] from [] > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] > (0x0100): Got request for [4097][1][name=test] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): > Request processed. Returned 0,0,Success > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [test] from [] > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search] > (0x0100): Requesting info for [test at sd.int] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] > (0x0100): Got request for [4099][1][name=test] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search] > (0x0100): Requesting info for [test at sd.int] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): > Request processed. Returned 0,0,Success > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] > (0x0100): Got request for [1][1][name=test] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): > Request processed. Returned 0,0,Success > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging > sd.int > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging nss > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging pam > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging ssh > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging pac > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pam > replied to ping > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pac > replied to ping > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service ssh > replied to ping > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service nss > replied to ping > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service sd.int > replied to ping > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [test] from [] > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [test] from [] > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > Requesting info for [test] from [] > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): > Requesting info for [test at sd.int] > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): > entering pam_cmd_authenticate > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > PAM_AUTHENTICATE > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > not set > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > 125.63.90.34 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 1 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 16634 > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [be_get_account_info] > (0x0100): Got request for [3][1][name=test] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > domain SID from [(null)] > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_check_user_search] (0x0100): > Requesting info for [test at sd.int] > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): Sending > request with the following data: > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): command: > PAM_AUTHENTICATE > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > sd.int > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): user: test > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > 125.63.90.34 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 1 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 16634 > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [acctinfo_callback] (0x0100): > Request processed. Returned 0,0,Success > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): > Got request with the following data > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > command: PAM_AUTHENTICATE > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > domain: sd.int > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > user: test > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > service: sshd > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > tty: ssh > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > ruser: > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > rhost: 125.63.90.34 > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > authtok type: 1 > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > priv: 1 > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > cli_pid: 16634 > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sss_krb5_cc_verify_ccache] > (0x0020): 1078: [-1765328190][Credentials cache permissions incorrect] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [check_old_ccache] (0x0040): > Cannot check if saved ccache FILE:/tmp/krb5cc_1312800003_LTtoQU is valid > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [krb5_auth_send] (0x0020): > check_if_ccache_file_is_used failed. > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [fo_resolve_service_send] > (0x0100): Trying to resolve service 'IPA' > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [unpack_buffer] > (0x0100): cmd [241] uid [1312800011] gid [1312800011] validate [true] > enterprise principal [false] offline [false] UPN [test at SD.INT] > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [unpack_buffer] > (0x0100): ccname: [FILE:/tmp/krb5cc_1312800011_XXXXXX] keytab: > [/etc/krb5.keytab] > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_RENEWABLE_LIFETIME] > from environment. > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > environment. > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to [true] > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [k5c_setup_fast] > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ > dns-inf-stg-sg1-01.sd.int at SD.INT] > *(Fri Mar 27 10:19:58 2015) [[sssd[krb5_child[16637]]]] [get_and_save_tgt] > (0x0020): 981: [-1765328361][Password has expired]* > *(Fri Mar 27 10:20:01 2015) [[sssd[krb5_child[16637]]]] [map_krb5_error] > (0x0020): 1043: [-1765328360][Preauthentication failed]* > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [child_sig_handler] (0x0100): > child [16637] finished successfully. > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [ipa_get_migration_flag_done] > (0x0100): Password migration is not enabled. > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > (0x0100): Backend returned: (0, 17, ) [Success] > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > (0x0100): Sending result [17][sd.int] > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > (0x0100): Sent result [17][sd.int] > (Fri Mar 27 10:20:01 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): > received: [17][sd.int] > > > > *We do not see any of the above error when try to login with "admin" user > created by IPA and able to login. Seems like there is any issue in creating > user from our side, though not able to figure out.* But this is the very first login after the user has been created right? Then SSH should prompt you for password change and after that, the second login should use the updated password. From yks0000 at gmail.com Fri Mar 27 07:03:41 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Fri, 27 Mar 2015 12:33:41 +0530 Subject: [Freeipa-users] IPA Client Install on Amazon Linux Message-ID: Hello, Is there any repo available for Amazon Linux to install IPA Client OR below is the only way to do as found from freeipa-user mail archive. http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html Thanks for the help. *Best Regards,__________________________________________* *Yogesh Sharma* -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Fri Mar 27 07:04:57 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Fri, 27 Mar 2015 12:34:57 +0530 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: <20150327070205.GA2903@hendrix.redhat.com> References: <1427377221.8302.78.camel@willson.usersys.redhat.com> <20150326142542.GT30085@hendrix.arn.redhat.com> <20150326151522.GU30085@hendrix.arn.redhat.com> <20150327070205.GA2903@hendrix.redhat.com> Message-ID: No. This is the second attempt after changing the password on first login. If you want I can re-send you the logs but this is the second login logs of this user. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Fri, Mar 27, 2015 at 12:32 PM, Jakub Hrozek wrote: > On Fri, Mar 27, 2015 at 10:28:13AM +0530, Yogesh Sharma wrote: > > Hi Jakub, > > > > Please find the logs for the user "test" created in IPA. > > > > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > > Requesting info for [test] from [] > > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): > > Requesting info for [test at sd.int] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] > > (0x0100): Got request for [4097][1][name=test] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): > > Requesting info for [test at sd.int] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] > (0x0100): > > Request processed. Returned 0,0,Success > > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > > Requesting info for [test] from [] > > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search] > > (0x0100): Requesting info for [test at sd.int] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] > > (0x0100): Got request for [4099][1][name=test] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[nss]] [nss_cmd_initgroups_search] > > (0x0100): Requesting info for [test at sd.int] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] > (0x0100): > > Request processed. Returned 0,0,Success > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [be_get_account_info] > > (0x0100): Got request for [1][1][name=test] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:52 2015) [sssd[be[sd.int]]] [acctinfo_callback] > (0x0100): > > Request processed. Returned 0,0,Success > > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging > > sd.int > > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging > nss > > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging > pam > > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging > ssh > > (Fri Mar 27 10:19:56 2015) [sssd] [service_send_ping] (0x0100): Pinging > pac > > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pam > > replied to ping > > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service pac > > replied to ping > > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service ssh > > replied to ping > > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service nss > > replied to ping > > (Fri Mar 27 10:19:56 2015) [sssd] [ping_check] (0x0100): Service sd.int > > replied to ping > > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > > Requesting info for [test] from [] > > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): > > Requesting info for [test at sd.int] > > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > > Requesting info for [test] from [] > > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): > > Requesting info for [test at sd.int] > > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0100): > > Requesting info for [test] from [] > > (Fri Mar 27 10:19:57 2015) [sssd[nss]] [nss_cmd_getpwnam_search] > (0x0100): > > Requesting info for [test at sd.int] > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_cmd_authenticate] (0x0100): > > entering pam_cmd_authenticate > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > command: > > PAM_AUTHENTICATE > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > > not set > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > test > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > service: > > sshd > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: > ssh > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > > not set > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > > 125.63.90.34 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > > type: 1 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > > newauthtok type: 0 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > cli_pid: > > 16634 > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [be_get_account_info] > > (0x0100): Got request for [3][1][name=test] > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sdap_attrs_get_sid_str] > > (0x0080): No [objectSIDString] attribute while id-mapping. [0][Success] > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > > [sdap_idmap_domain_has_algorithmic_mapping] (0x0080): Could not parse > > domain SID from [(null)] > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_check_user_search] (0x0100): > > Requesting info for [test at sd.int] > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_dp_send_req] (0x0100): > Sending > > request with the following data: > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > command: > > PAM_AUTHENTICATE > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > > sd.int > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > test > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > service: > > sshd > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: > ssh > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > > not set > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > > 125.63.90.34 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > > type: 1 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > > newauthtok type: 0 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_print_data] (0x0100): > cli_pid: > > 16634 > > (Fri Mar 27 10:19:57 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > > pam_dp_send_req returned 0 > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [acctinfo_callback] > (0x0100): > > Request processed. Returned 0,0,Success > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [be_pam_handler] (0x0100): > > Got request with the following data > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > command: PAM_AUTHENTICATE > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > domain: sd.int > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > user: test > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > service: sshd > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > tty: ssh > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > ruser: > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > rhost: 125.63.90.34 > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > authtok type: 1 > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > newauthtok type: 0 > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > priv: 1 > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [pam_print_data] (0x0100): > > cli_pid: 16634 > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] > [sss_krb5_cc_verify_ccache] > > (0x0020): 1078: [-1765328190][Credentials cache permissions incorrect] > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [check_old_ccache] > (0x0040): > > Cannot check if saved ccache FILE:/tmp/krb5cc_1312800003_LTtoQU is valid > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [krb5_auth_send] (0x0020): > > check_if_ccache_file_is_used failed. > > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [fo_resolve_service_send] > > (0x0100): Trying to resolve service 'IPA' > > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [unpack_buffer] > > (0x0100): cmd [241] uid [1312800011] gid [1312800011] validate [true] > > enterprise principal [false] offline [false] UPN [test at SD.INT] > > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [unpack_buffer] > > (0x0100): ccname: [FILE:/tmp/krb5cc_1312800011_XXXXXX] keytab: > > [/etc/krb5.keytab] > > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] > > [set_lifetime_options] (0x0100): Cannot read > [SSSD_KRB5_RENEWABLE_LIFETIME] > > from environment. > > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] > > [set_lifetime_options] (0x0100): Cannot read [SSSD_KRB5_LIFETIME] from > > environment. > > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] > > [set_canonicalize_option] (0x0100): SSSD_KRB5_CANONICALIZE is set to > [true] > > (Fri Mar 27 10:19:57 2015) [[sssd[krb5_child[16637]]]] [k5c_setup_fast] > > (0x0100): SSSD_KRB5_FAST_PRINCIPAL is set to [host/ > > dns-inf-stg-sg1-01.sd.int at SD.INT] > > *(Fri Mar 27 10:19:58 2015) [[sssd[krb5_child[16637]]]] > [get_and_save_tgt] > > (0x0020): 981: [-1765328361][Password has expired]* > > *(Fri Mar 27 10:20:01 2015) [[sssd[krb5_child[16637]]]] [map_krb5_error] > > (0x0020): 1043: [-1765328360][Preauthentication failed]* > > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [child_sig_handler] > (0x0100): > > child [16637] finished successfully. > > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] > [ipa_get_migration_flag_done] > > (0x0100): Password migration is not enabled. > > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > > (0x0100): Backend returned: (0, 17, ) [Success] > > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > > (0x0100): Sending result [17][sd.int] > > (Fri Mar 27 10:20:01 2015) [sssd[be[sd.int]]] [be_pam_handler_callback] > > (0x0100): Sent result [17][sd.int] > > (Fri Mar 27 10:20:01 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): > > received: [17][sd.int] > > > > > > > > *We do not see any of the above error when try to login with "admin" user > > created by IPA and able to login. Seems like there is any issue in > creating > > user from our side, though not able to figure out.* > > But this is the very first login after the user has been created right? > Then SSH should prompt you for password change and after that, the > second login should use the updated password. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From g.fer.ordas at unicyber.co.uk Fri Mar 27 07:33:02 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Fri, 27 Mar 2015 00:33:02 -0700 Subject: [Freeipa-users] IPA Client Install on Amazon Linux In-Reply-To: References: Message-ID: <551507AE.3070009@unicyber.co.uk> Yogesh My personal experience using AWS Linux and LDAP is not a good one and mostly an utter nightmare in relation to packages. Personally I would recommend you to keep away from AWS Linux and get a Centos, Fedora or Redhat. Still, if you want to go ahead, I can give you the right versions for a couple of packages as the default sudo given by Amazon simply DOES NOT work (no idea what they have done to it..) Thanks On 27/03/2015 00:03, Yogesh Sharma wrote: > Hello, > > Is there any repo available for Amazon Linux to install IPA Client OR > below is the only way to do as found from freeipa-user mail archive. > > http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html > > > Thanks for the help. > / > Best Regards, > __________________________________________ > / > /Yogesh Sharma > / > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Fri Mar 27 08:03:21 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Fri, 27 Mar 2015 13:33:21 +0530 Subject: [Freeipa-users] IPA Client Install on Amazon Linux In-Reply-To: <551507AE.3070009@unicyber.co.uk> References: <551507AE.3070009@unicyber.co.uk> Message-ID: Gonzalo, We have some running servers on Amazon Linux and it would be difficult to migrate all those to CentOS or RHEL as of now. Hence If you can provide the package's version then it would really help us till the time we do migration. For sure all over new Servers are going to be CentOS or RHEL. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Fri, Mar 27, 2015 at 1:03 PM, Gonzalo Fernandez Ordas < g.fer.ordas at unicyber.co.uk> wrote: > Yogesh > > My personal experience using AWS Linux and LDAP is not a good one and > mostly an utter nightmare in relation to packages. > Personally I would recommend you to keep away from AWS Linux and get a > Centos, Fedora or Redhat. > Still, if you want to go ahead, I can give you the right versions for a > couple of packages as the default sudo given by Amazon simply DOES NOT work > (no idea what they have done to it..) > > Thanks > > On 27/03/2015 00:03, Yogesh Sharma wrote: > > Hello, > > Is there any repo available for Amazon Linux to install IPA Client OR > below is the only way to do as found from freeipa-user mail archive. > > http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html > > > Thanks for the help. > > > > * Best Regards, __________________________________________ * > > *Yogesh Sharma * > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.kreuter at bytesource.net Fri Mar 27 08:12:20 2015 From: david.kreuter at bytesource.net (David Kreuter) Date: Fri, 27 Mar 2015 09:12:20 +0100 (CET) Subject: [Freeipa-users] Fwd: Unexpected IPA Crashes In-Reply-To: Message-ID: <833d0e26-2a27-4b71-8dc5-c4cd0eb51f92@zimbra.bytesource.net> No, there are no entries with "segfaulter" neither in /var/log/messags nor in journalctr. Meanwhile we encountered several directory server hangs and I was able to produce the stacktrace. Perhpas you can have a look. ----- Original Message ----- From: "David Kreuter" To: "freeipa-users" Sent: Thursday, 26 March, 2015 11:18:59 PM Subject: Unexpected IPA Crashes We have been using FreeIPA since two years and were more than happy. But since two weeks we are facing unexpected crashed and can not really debug the strange behaviours. The crashes are definitely not caused by connecting a new system or changing the LDAP schema heavily. Following IPA is used: Name : ipa-server Arch : x86_64 Version : 3.3.3 Release : 28.0.1.el7.centos.3 Size : 4.1 M I have followed the troubleshooting guide http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting and activated logging and activated the core dumping. Unfortunately, I cannot provide you any core dump, because it is not created after the ipa servers crashes. I'm sure the dirsrv is causing the problem, because when i restart the 389, then ipa works fine for a while. Currently I have activated the replication log level 8192. The error log shows no suspicious error or any fatal error. Following 389* versions are used: Installed Packages 389-ds-base.x86_64 1.3.3.1-15.el7_1 @/389-ds-base-1.3.3.1-15.el7_1.x86_64 389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo 389-ds-base-libs.x86_64 1.3.3.1-15.el7_1 Can you please provide some hint how I can debug this problem in more detail. Btw, the ipa infrastructure consist of one master and one replica. The server was also crashing, when the replica server was turned off. Do you thing an upgrade would solve the problem as the last resort? -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: stacktrace.1427440880.txt URL: From jhrozek at redhat.com Fri Mar 27 08:31:48 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 27 Mar 2015 09:31:48 +0100 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: <1427377221.8302.78.camel@willson.usersys.redhat.com> <20150326142542.GT30085@hendrix.arn.redhat.com> <20150326151522.GU30085@hendrix.arn.redhat.com> <20150327070205.GA2903@hendrix.redhat.com> Message-ID: <20150327083148.GB2903@hendrix.redhat.com> On Fri, Mar 27, 2015 at 12:34:57PM +0530, Yogesh Sharma wrote: > No. This is the second attempt after changing the password on first login. > > If you want I can re-send you the logs but this is the second login logs of > this user. Then it would be most interesting to see the logs of the password change, I wonder if something went wrong there. You said that if you change the password via kinit, then it's changed successfully, right? Does the wrong password change happen only on one certain host or do all behave the same? Did you configure the host using ipa-client-install or some manual method? I just tested a new user with centos 7 server and git head client and everything seemed to work fine.. From natxo.asenjo at gmail.com Fri Mar 27 08:40:54 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Fri, 27 Mar 2015 09:40:54 +0100 Subject: [Freeipa-users] Not able to SSH with User Created in IPA Server In-Reply-To: References: <1427377221.8302.78.camel@willson.usersys.redhat.com> <20150326142542.GT30085@hendrix.arn.redhat.com> <20150326151522.GU30085@hendrix.arn.redhat.com> Message-ID: On Fri, Mar 27, 2015 at 5:58 AM, Yogesh Sharma wrote: > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [sss_krb5_cc_verify_ccache] > (0x0020): 1078: [-1765328190][Credentials cache permissions incorrect] > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [check_old_ccache] > (0x0040): Cannot check if saved ccache FILE:/tmp/krb5cc_1312800003_LTtoQU > is valid > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [krb5_auth_send] (0x0020): > check_if_ccache_file_is_used failed. > (Fri Mar 27 10:19:57 2015) [sssd[be[sd.int]]] [fo_resolve_service_send] > (0x0100): Trying to resolve service 'IPA' > maybe this? Could you check what the permissions are on the kerberos cache file for this test user? -- regards, Natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From pspacek at redhat.com Fri Mar 27 09:36:49 2015 From: pspacek at redhat.com (Petr Spacek) Date: Fri, 27 Mar 2015 10:36:49 +0100 Subject: [Freeipa-users] bind-dyndb-ldap vs DLZ In-Reply-To: <5514AC42.80205@lundman.net> References: <55122F5F.8030505@lundman.net> <55126655.30109@redhat.com> <551351F8.5070508@lundman.net> <5513D7D6.7070408@redhat.com> <5514AC42.80205@lundman.net> Message-ID: <551524B1.6040103@redhat.com> On 27.3.2015 02:02, Jorgen Lundman wrote: > Petr Spacek wrote: >> Perfect! I can merge your changes upstream if you send me a patch with your >> changes. It would make your life easier later when you need to pick new code. > > Not a problem, I need to figure out why Solaris mkdir returns -1, with > errno = 0. Goes against the manpage and all logic. Checking for ||errno==0 > after mkdir "fixes" it but it is still odd. That is really weird! I'm bit worried that it would break something on some other system so I'm not rushing to merge it upstream. > I also compiled without krb5. It basically compiled, but running would fail > to find gss/mech_krb5.so - no idea how that is supposed to link, but since > it was a quick test, I just took it out. Interesting. I guess that the missing file is something like Kerberos module for GSS-API library on Solaris. Anyway, feel free to send fixes or a patch with --disable-kerberos option for configure. > Otherwise it compiled smoothly, some minor linux-ism with linker flags. Could you be more specific, please? I can certainly fix linker flags if you tell me how :-) >> Hmm, that might be a challenge. bind-dyndb-ldap code implicitly assumes that >> there is 1:1 mapping between DNS name<->LDAP DN. This makes implementation of >> dynamic updates much easier. > > Actually yes, I did mean to ask about this too. DLZ-LDAP is pretty much a > read-only setup (for us), so a quick scan of the sources led me to believe > that simple string replacement of "idnsName" with "DNSZoneName" (and of > course, all the others), should get "a large chunk" of it done. The schemas > are quite close, on a whole.. Yeah, changes for read-only mode could be pretty easy. See mainly src/ldap_entry.c a src/ldap_convert.c. > But I was surprised to see bind-dyndb actually modify the LDAP data, for my > test, just "idnsSOAserial". What is the purpose of this? I would guess for > zone xfers? By why update LDAP (and not just internal DNS memory), if you > essentially do not use it on restart (just gets updated again on restart, > from the looks of it?) This is to make sure that SOA serial is incremented even if the server crashed. The problem is that data in LDAP could be modified while server is down so you have to increment SOA serial in all cases. This could be optimized further when we finally have persistent copy of data on disk, we could simply store syncrepl cookie somewhere and increment SOA serial only if something was changed. >>> the same delay each time I start it. slapd is running on localhost, and is >>> otherwise idle. >> >> Hmm, that stinks! I would be happy to look into it if you can provide me with >> output from a profiler of your choice. (It might be a good idea to profile >> bind-dyndb-ldap together with whole named process to see all the interactions.) > > It is in line with what we experience with LDAP generally. If I blow away > the DNS-ldap tree, a full syncrepl update takes about 1 hour. If I remove > the whole LDAP tree, about 4 hours. It is not something that goes faster > with more threads afaik. Here I'm merging both you e-mails to one: > Hold those horses. I must admit this timing didn't sit right with me, the > more I thought about it. Since my test was all new, I created a slapd.conf > from scratch. Forgot all about entryUUID index! Interesting. Could you tell us how long it took to start-up with indexed entryUUID but without the other changes? Or more specifically, could you please measure impact of separate changes mentioned below? > I took out the creations of the empty master/$domain/keys directories. We > don't use any of that. This effectively breaks dynamic updates, IXFR and DNSSEC in-line signing but it might not be a problem for you if you do not use these features. > I noticed that its not the syncrepl that is slow, it is the MOD update of > all idnsSOAserial. Unfortunately, they are all on one connection, so > increasing > arg "connections 15"; > does not help. Interesting. I believe that this is caused by internal event serialization in bind-dyndb-ldap. All changes to idnsZone objects are processed only by single thread (mainly purpose is AFAIK simplification of locking). It certainly can be fixed and this fix should enable parallelization of zone loading. BTW my guess is that you are testing the worst case - a lot of small zones. It should scale better with bigger zones (but no guarantees here! :-). > I took out the updates of idnsSOAserial by making > ldap_replace_serial(return ISC_R_SUCCESS); > > Startup time is just under 2 minutes. I can certainly live with that. Just > go to work out if we can actually use it without idnsSOAserial or not. We It has ~ no purpose if you do not do DNS zone transfers or in-line signing (which depends on internal zone transfer). > have just ldap master using syncrepl to each DNS server's local slapd. Then > named to use that. No xfers, no slaves etc. You probably do not need it. > Shutdown is still slow, but that appears to be a Solaris bug, after all > zones are shutdown and listening ports released, it sits around calling > lwp_park and unpark for 10 minutes. I can debug that later. If you are really using read-only zones feel free to kill -9 the named process :-) >>> Is it supposed to be able to use the "dump-file" on exit for faster loads? >> >> Yes, something like that is planned but not implemented yet. > > Ah ok great, good to know it is planned. We could probably live with 50 > mins startup time, as there are 28 servers in the DNS cluster. Just needs > some care in case they are restarted, or worse, some bug causes coredump > which affects all of them Yes, simultaneous crash/coredump happens from time to time when we hit some nasty bind-dyndb-ldap bug. >>> [3] >>> However, that has a side-effect that, once bind-dyndb is loaded, it will >>> also query DLZ+LDAP on negative entries. Thus decreasing the performance to >>> 3884qps. Wonder if there is a way to have bind-dyndb ignore DLZ+LDAP /once >>> it has loaded/. >> >> Wow, I'm surprised that this combination actually works! I expect that there >> will be some nasty surprises in there, especially when it comes to dynamic >> updates. > > I must admit it would be tempting to see if bind-dyndb could issue a > definitive reply (once loaded) for both positive and negative lookups, > thereby causing DLZ-LDAP to be inert. bind-dyndb-ldap does answer authoritatively for all queries. I believe that what you see is side-effect/"feature" of DLZ interface. > Or making it a feature of bind-dyndb > to use DLZ-LDAP during load. But only in the case that they both use the > same schema and source tree in LDAP. > > Feels a bit hackish but just evaluating possible solutions. To me it sounds like a terrible hack. Do not even try to think about interaction with DNSSEC in-line signing. Yuck! Have a nice day (and send us patches! :-). -- Petr^2 Spacek From prasun.gera at gmail.com Fri Mar 27 10:35:03 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Fri, 27 Mar 2015 06:35:03 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: <5514C804.4040207@redhat.com> References: <55148136.8040003@redhat.com> <5514C804.4040207@redhat.com> Message-ID: > > > The passwords will only show if they are in {crypt} format. If the > password is changed in IPA it will use the default 389-ds password > scheme which is a salted SHA. Yes, that's right. If the password is changed in IPA afterwards, it will stop working for NIS clients. This is the expected behaviour and that's fine. > It may be, though I didn't think this was > the case, that the password is being re-hashed during kerberos key > generation. The kerberos keys for these users shouldn't be generated at all right ? So far I have been using the special webui page (/ipa/migration) to elevate old users to regular IPA users. The migration webui page needs the plaintext password in order to generate the kerberos keys. Until the migration step is complete, there are no kerberos keys. And that seems all right. i.e. Elevation to IPA users should happen only intentionally. > > How long will you need to keep these legacy systems? This sharing of the > password hashes is one of the (many) reasons people are migrating from NIS. > These clients are actually not even that old. Most of them are on Ubuntu 12.04 or thereabouts. IPA client support on Ubuntu systems seems to be a bit buggy. I did manage to get it to work with ppas for ipa and sssd after some minor changes. This has improved in 14.04 from what I read, and it might be a better idea to bring the clients up to that before migrating. > > A fix may be to change the 389-ds password hashing scheme to crypt but > that may just let these NIS systems linger forever. So it's the typical > balance of usability vs security. > I don't think the problem is the hashing scheme itself. The old users' passwords were encrypted using MD5 and that's how I had imported them. Changing the scheme to something else after importing won't affect these passwords anyway right ? Or do you mean that if I change 389-ds's scheme to MD5 now, even if these users are elevated to IPA users, their hashes will continue to be visible from NIS clients. I thought the encryption scheme itself, and whether on not NIS clients see the encrypted password were two separate issues. > > rob > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mkosek at redhat.com Fri Mar 27 11:42:40 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Mar 2015 12:42:40 +0100 Subject: [Freeipa-users] can't specify DNS name or subject in cert request in FreeIPA 3.3 In-Reply-To: References: Message-ID: <55154230.9010501@redhat.com> You are doing it correctly. However, the DNS SubjectAltName only works with FreeIPA 4.0+. The CA profile before this version does not allow them. This is the upstream ticket: https://fedorahosted.org/freeipa/ticket/3977 On 03/26/2015 07:09 PM, Steve Neuharth wrote: > I'm trying to specify a subject name in a cert request like this: > > ipa-getcert request -K HTTP/web.test.org -N *cn=www.test.org > ,o=TEST.ORG * -f /tmp/webserver.crt > -k /tmp/webprivate.key -r > > or like this > > ipa-getcert request -K HTTP/web.test.org -D www.test.org -f > /tmp/webserver.crt -k /tmp/webprivate.key -r > > The resulting certificate, however, just has the hostname of the server > like this: > > Request ID '20150326060555': > status: MONITORING > stuck: no > key pair storage: type=FILE,location='/tmp/webprivate.key' > certificate: type=FILE,location='/tmp/webserver.crt' > CA: IPA > issuer: CN=Certificate Authority,O=TEST.ORG > subject: *CN=web.test.org ,O=TEST.ORG > * > expires: 2017-03-26 05:46:29 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 > > Is this a bug or am I doing something wrong in certmonger? > > --steve > > > From mkosek at redhat.com Fri Mar 27 11:48:12 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Mar 2015 12:48:12 +0100 Subject: [Freeipa-users] LDAP/IPA pw - not pre-expired In-Reply-To: <5514E938.1070000@gmail.com> References: <5514E938.1070000@gmail.com> Message-ID: <5515437C.4040801@redhat.com> On 03/27/2015 06:23 AM, Janelle wrote: > Hi again, > > I can't seem to find it. Is there a way to create a new user with a non-expired > PW? No clean way, by design. You can check our reasoning on this page: https://www.freeipa.org/page/New_Passwords_Expired There is a way (setting some DN as password synchronization agent), but this is for PassSync mainly. Using it for regular admin user would be a hack and a bad security practice. HTH, Martin From janellenicole80 at gmail.com Fri Mar 27 12:52:24 2015 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 27 Mar 2015 05:52:24 -0700 Subject: [Freeipa-users] Unexpired pw? Message-ID: <2380220D-BFBF-4582-8A34-6C1F7421439D@gmail.com> Hi all, Found an odd issue and a question. If you change user pw with "ipa user-mod -password" and the client is configured for LDAP, then the user is not forced to change the pw on initial login. However, my other question is, can you set a user pw WITHOUT pre-expiring?! ~J From abokovoy at redhat.com Fri Mar 27 13:14:40 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Fri, 27 Mar 2015 15:14:40 +0200 Subject: [Freeipa-users] Unexpired pw? In-Reply-To: <2380220D-BFBF-4582-8A34-6C1F7421439D@gmail.com> References: <2380220D-BFBF-4582-8A34-6C1F7421439D@gmail.com> Message-ID: <20150327131440.GJ3878@redhat.com> On Fri, 27 Mar 2015, Janelle wrote: > >Hi all, > >Found an odd issue and a question. If you change user pw with "ipa >user-mod -password" and the client is configured for LDAP, then the >user is not forced to change the pw on initial login. We have three different cases depending on who changes userPassword attribute in LDAP: 1. cn=Directory Manager can change anything and it doesn't taint the userPassword. 2. A user can change own password and it doesn't taint the userPassword attribute. 3. Any other identity that can change a password will taint userPassword attribute. If you change user password with "ipa user-mod --password" the question should be "who are you?" and the answer to that question drives the tainting logic described above. >However, my other question is, can you set a user pw WITHOUT >pre-expiring?! cn=Directory manager is the one who can but directly in LDAP as you cannot authenticate as 'cn=Directory manager' using IPA tools. If you are insisting on lowering security of your passwords, nothing prevents you from changing user password to some value as admin user first and then setting it as that user to a correct value. We don't recommend to do so but you have means already to ignore our recommendations. -- / Alexander Bokovoy From mkosek at redhat.com Fri Mar 27 13:20:43 2015 From: mkosek at redhat.com (Martin Kosek) Date: Fri, 27 Mar 2015 14:20:43 +0100 Subject: [Freeipa-users] Unexpired pw? In-Reply-To: <2380220D-BFBF-4582-8A34-6C1F7421439D@gmail.com> References: <2380220D-BFBF-4582-8A34-6C1F7421439D@gmail.com> Message-ID: <5515592B.7060109@redhat.com> On 03/27/2015 01:52 PM, Janelle wrote: > > Hi all, > > Found an odd issue and a question. If you change user pw with "ipa user-mod -password" and the client is configured for LDAP, then the user is not forced to change the pw on initial login. This is something we would like to fix eventually, it is tracked in https://fedorahosted.org/freeipa/ticket/1539 It was not done yet as just forcing the password expiration on LDAP BIND tends to break stuff. From Andy.Thompson at e-tcc.com Fri Mar 27 12:51:03 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Fri, 27 Mar 2015 12:51:03 +0000 Subject: [Freeipa-users] passwordStorageScheme Message-ID: Relative newb here :) I'm doing some research trying to sort out the password storage scheme being used on the freeipa LDAP instance. From everything I can find it uses ssha but can be changed to ssha-512. But when I try to change that attribute on the cn=config object like referenced here https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/User_Account_Management.html#Configuring_a_Global_Password_Policy_Using_the_Command_Line-Password_Policy_Attributes It comes back with wrong attribute type. I realize that doc points to the RHDS so it might be valid for the ipa ds? So I guess my question is what hash is used by freeipa to store password hashes and is it configurable? *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** From benoit.rousselle at gmail.com Fri Mar 27 13:56:50 2015 From: benoit.rousselle at gmail.com (Benoit Rousselle) Date: Fri, 27 Mar 2015 14:56:50 +0100 Subject: [Freeipa-users] config sudo with ipa Message-ID: hi, I setup a sudo config in client ipa and set rule in ipa server. sudo rules from ipa are not found : it return 0 rules for the user This config is ambiguous. Is there a method to check if everything is OK ? The best way for this moment is to set debug_level on sssd. But I'm not sure that the problem come from there. (Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x1cba830 "ltdb_callback" (Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=my_user)(sudoUser=#1600001)(sudoUser=%utilisateur_a)(sudoUser=%adupont)(sudoUser=+*)))] (Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_callback": 0x1cb9000 (Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event "ltdb_timeout": 0x1cb9240 (Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Destroying timer event 0x1cb9240 "ltdb_timeout" (Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event 0x1cb9000 "ltdb_callback" (Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] (0x0400): Returning 0 rules for [my_user at my_domain.com] (Fri Mar 27 14:12:36 2015) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle timer re-set for client [0x1cb30e0][18] My client config : [domain/my_domain.com] debug_level = 6 cache_credentials = True krb5_store_password_if_offline = True krb5_realm = MY_IDMDOMAIN.COM ipa_domain = my_domain.com id_provider = ipa auth_provider = ipa access_provider = ipa ipa_hostname = myserver.my_domain.com chpass_provider = ipa ipa_server = _srv_, idm.my_domain.com ldap_tls_cacert = /etc/ipa/ca.crt [sssd] services = nss, pam, ssh, sudo config_file_version = 2 domains = addcnet.com [nss] [pam] [sudo] debug_level = 9 [autofs] [ssh] [pac] ---- server redhat : LINUX 6.4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From lslebodn at redhat.com Fri Mar 27 14:05:31 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Fri, 27 Mar 2015 15:05:31 +0100 Subject: [Freeipa-users] config sudo with ipa In-Reply-To: References: Message-ID: <20150327140530.GF1126@mail.corp.redhat.com> On (27/03/15 14:56), Benoit Rousselle wrote: >hi, > >I setup a sudo config in client ipa and set rule in ipa server. >sudo rules from ipa are not found : it return 0 rules for the user > >This config is ambiguous. Is there a method to check if everything is OK ? >The best way for this moment is to set debug_level on sssd. But I'm not >sure that the problem come from there. > > >(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event >0x1cba830 "ltdb_callback" > >(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] >(0x0200): Searching sysdb with >[(&(objectClass=sudoRule)(|(sudoUser=ALL)(sudoUser=my_user)(sudoUser=#1600001)(sudoUser=%utilisateur_a)(sudoUser=%adupont)(sudoUser=+*)))] >(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event >"ltdb_callback": 0x1cb9000 > >(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Added timed event >"ltdb_timeout": 0x1cb9240 > >(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Destroying timer >event 0x1cb9240 "ltdb_timeout" > >(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [ldb] (0x4000): Ending timer event >0x1cb9000 "ltdb_callback" > >(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [sudosrv_get_sudorules_from_cache] >(0x0400): Returning 0 rules for [my_user at my_domain.com] >(Fri Mar 27 14:12:36 2015) [sssd[sudo]] [reset_idle_timer] (0x4000): Idle >timer re-set for client [0x1cb30e0][18] > > >My client config : >[domain/my_domain.com] >debug_level = 6 >cache_credentials = True >krb5_store_password_if_offline = True >krb5_realm = MY_IDMDOMAIN.COM >ipa_domain = my_domain.com >id_provider = ipa >auth_provider = ipa >access_provider = ipa >ipa_hostname = myserver.my_domain.com >chpass_provider = ipa >ipa_server = _srv_, idm.my_domain.com >ldap_tls_cacert = /etc/ipa/ca.crt >[sssd] >services = nss, pam, ssh, sudo >config_file_version = 2 > >domains = addcnet.com >[nss] > >[pam] > >[sudo] >debug_level = 9 > >[autofs] > >[ssh] > >[pac] > >---- >server redhat : LINUX 6.4 rhel 6.4 has old version of sssd which does not have native ipa sudo provider. You will need to configure sudo with sudo_provider = ldap. Please follow instructions in manual page "sssd-sudo" LS From rcritten at redhat.com Fri Mar 27 14:08:21 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Mar 2015 10:08:21 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: References: <55148136.8040003@redhat.com> <5514C804.4040207@redhat.com> Message-ID: <55156455.7090401@redhat.com> Prasun Gera wrote: > > The passwords will only show if they are in {crypt} format. If the > password is changed in IPA it will use the default 389-ds password > scheme which is a salted SHA. > > > Yes, that's right. If the password is changed in IPA afterwards, it will > stop working for NIS clients. This is the expected behaviour and that's > fine. > > > > It may be, though I didn't think this was > the case, that the password is being re-hashed during kerberos key > generation. > > > The kerberos keys for these users shouldn't be generated at all right ? > So far I have been using the special webui page (/ipa/migration) to > elevate old users to regular IPA users. The migration webui page needs > the plaintext password in order to generate the kerberos keys. Until the > migration step is complete, there are no kerberos keys. And that seems > all right. i.e. Elevation to IPA users should happen only intentionally. Keys can be generated in migration in two ways: by the migration web UI or by sssd. I'm guessing you were unaware of this second method and that is how the keys are being created. > How long will you need to keep these legacy systems? This sharing of the > password hashes is one of the (many) reasons people are migrating > from NIS. > > > These clients are actually not even that old. Most of them are on Ubuntu > 12.04 or thereabouts. IPA client support on Ubuntu systems seems to be a > bit buggy. I did manage to get it to work with ppas for ipa and sssd > after some minor changes. This has improved in 14.04 from what I read, > and it might be a better idea to bring the clients up to that before > migrating. I'd suggest using nss_ldap over NIS. You can also manually configure Kerberos and have basic functionality as long as nscld doesn't drive you crazy. AFAIK there is just one guy donating his time to create the ppas for Debian for all the related IPA client and server packages, in his spare time. I imagine he has to pick his battles carefully. > > A fix may be to change the 389-ds password hashing scheme to crypt but > that may just let these NIS systems linger forever. So it's the typical > balance of usability vs security. > > > I don't think the problem is the hashing scheme itself. The old users' > passwords were encrypted using MD5 and that's how I had imported them. > Changing the scheme to something else after importing won't affect these > passwords anyway right ? Or do you mean that if I change 389-ds's scheme > to MD5 now, even if these users are elevated to IPA users, their hashes > will continue to be visible from NIS clients. I thought the encryption > scheme itself, and whether on not NIS clients see the encrypted password > were two separate issues. It's not the encryption type, it is how it is encoded in 389-ds. When you migrated the passwords they were stored as {crypt}hash. When the password is changed in 389-ds it becomes {SSHA}hash. The NIS configuration for slapi-nis only provides those passwords prefixed with {crypt} (because NIS can only grok that format). rob From guertin at middlebury.edu Fri Mar 27 14:23:27 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Fri, 27 Mar 2015 14:23:27 +0000 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <20150326164019.GD7785@p.redhat.com> References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> <1427298281.8302.62.camel@willson.usersys.redhat.com> <55134C60.3060505@redhat.com> <20150326082321.GI3550@p.redhat.com> <20150326164019.GD7785@p.redhat.com> Message-ID: <42855eae690c458aabe8f9dc7978f222@greyhound.middlebury.edu> >To see why the login fails it would be good to >know how you try to log in (I assume ssh) and which authentication method >is used (password, ssh key, Kerberos ticket). >Additionally the SSSD log files might be needed, most important here are the >logs from the PAM and PAC responders and the domain log. Yes, this is SSH. There are a few hints in the log files on the client: sssd_ipa.middlebury.edu.log: (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 12 (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xe7f410], connected[1], ops[0xe80680], ldap[0xe641d0] (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Protocol error(2), (null) (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_id_op_done] (0x4000): releasing operation connection (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xe7f410], connected[1], ops[(nil)], ldap[0xe641d0] Sssd_nss.log: (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x418850:1:juser at middlebury.edu] (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [middlebury.edu][4097][1][name=juser] (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x6b5a10 (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x418850:1:juser at middlebury.edu] (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x6b5a10 (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x6b0aa0 (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 1432158221 error message: Account info lookup failed (Fri Mar 27 09:29:14 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider Error: 3, 1432158221, Account info lookup failed Will try to return what we have in cache (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x418850:1:juser at middlebury.edu] I don't see any errors in sssd_pam.log, sssd_pac.log, or sssd_ssh.log. Is this an indication that something is wrong with the trust relationship? If so, why is it happening on this client but not the other one? Any why are the servers working properly? David Guertin From sbose at redhat.com Fri Mar 27 15:18:29 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 27 Mar 2015 16:18:29 +0100 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <42855eae690c458aabe8f9dc7978f222@greyhound.middlebury.edu> References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> <1427298281.8302.62.camel@willson.usersys.redhat.com> <55134C60.3060505@redhat.com> <20150326082321.GI3550@p.redhat.com> <20150326164019.GD7785@p.redhat.com> <42855eae690c458aabe8f9dc7978f222@greyhound.middlebury.edu> Message-ID: <20150327151829.GC29843@p.redhat.com> On Fri, Mar 27, 2015 at 02:23:27PM +0000, Guertin, David S. wrote: > >To see why the login fails it would be good to > >know how you try to log in (I assume ssh) and which authentication method > >is used (password, ssh key, Kerberos ticket). > >Additionally the SSSD log files might be needed, most important here are the > >logs from the PAM and PAC responders and the domain log. > > Yes, this is SSH. There are a few hints in the log files on the client: > > sssd_ipa.middlebury.edu.log: > > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_send] (0x0400): Executing extended operation > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_send] (0x2000): ldap_extended_operation sent, msgid = 12 > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xe7f410], connected[1], ops[0xe80680], ldap[0xe641d0] > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_EXTENDED] > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_exop_done] (0x0400): ldap_extended_operation result: Protocol error(2), (null) The most likely reason for 'Protocol error' is that the server this client is connected to does not support the special LDAP extended operation used by SSSD on IPA clients to get the data for users and groups from trusted domains. And the most likely reason for this is that ipa-adtrust-install is not run on that server. Please note that while 'ipa trust-add ...' must be only run once on one of the IPA servers, ipa-adtrust-install must be run on all, e.g. to enable the LDAP extended operation mentioned above. You can check if the exop is enabled on the servers by running ldapsearch -h localhost -x -b '' -s base|grep 2.16.840.1.113730.3.8.10.4 on each server. YOu should see 1, for RHEL-7.1 even 2 lines of output. > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [ipa_s2n_get_user_done] (0x0040): s2n exop request failed. > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_id_op_done] (0x4000): releasing operation connection > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [acctinfo_callback] (0x0100): Request processed. Returned 3,1432158221,Account info lookup failed > (Fri Mar 27 09:29:14 2015) [sssd[be[ipa.middlebury.edu]]] [sdap_process_result] (0x2000): Trace: sh[0xe7f410], connected[1], ops[(nil)], ldap[0xe641d0] > > Sssd_nss.log: > > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x418850:1:juser at middlebury.edu] > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for [middlebury.edu][4097][1][name=juser] > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_add_timeout] (0x2000): 0x6b5a10 > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x418850:1:juser at middlebury.edu] > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_remove_timeout] (0x2000): 0x6b5a10 > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_dispatch] (0x4000): dbus conn: 0x6b0aa0 > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sbus_dispatch] (0x4000): Dispatching. > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_get_reply] (0x1000): Got reply from Data Provider - DP error code: 3 errno: 1432158221 error message: Account info lookup failed > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [nss_cmd_getby_dp_callback] (0x0040): Unable to get information from Data Provider > Error: 3, 1432158221, Account info lookup failed > Will try to return what we have in cache > (Fri Mar 27 09:29:14 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x418850:1:juser at middlebury.edu] > > I don't see any errors in sssd_pam.log, sssd_pac.log, or sssd_ssh.log. > > Is this an indication that something is wrong with the trust relationship? If so, why is it happening on this client but not the other one? Any why are the servers working properly? Maybe the clients are connected to different servers and only one of them has the exop enabled? The servers itself lookup the AD users and groups directly from the AD DC. Since the users are available on the server and one client is already working I expect that the trust relationship is fine. HTH bye, Sumit > > David Guertin From sramling at redhat.com Fri Mar 27 15:32:53 2015 From: sramling at redhat.com (Sankar Ramlingam) Date: Fri, 27 Mar 2015 21:02:53 +0530 Subject: [Freeipa-users] Fwd: Unexpected IPA Crashes In-Reply-To: <833d0e26-2a27-4b71-8dc5-c4cd0eb51f92@zimbra.bytesource.net> References: <833d0e26-2a27-4b71-8dc5-c4cd0eb51f92@zimbra.bytesource.net> Message-ID: <55157825.9050807@redhat.com> On 03/27/2015 01:42 PM, David Kreuter wrote: > No, there are no entries with "segfaulter" neither in /var/log/messags > nor in journalctr. > > Meanwhile we encountered several directory server hangs and I was able > to produce the stacktrace. Perhpas you can have a look. Hi David, You seem to have the latest/released version of 389-ds-base. You can probably try an upgrade to get the latest of other dependent components and 389-ds-base-debuginfo. Thanks, -Sankar R. > > ------------------------------------------------------------------------ > *From: *"David Kreuter" > *To: *"freeipa-users" > *Sent: *Thursday, 26 March, 2015 11:18:59 PM > *Subject: *Unexpected IPA Crashes > > We have been using FreeIPA since two years and were more than happy. > But since two weeks we are facing unexpected crashed and can not > really debug the strange behaviours. The crashes are definitely not > caused by connecting a new system or changing the LDAP schema heavily. > Following IPA is used: > > Name : ipa-server > > Arch : x86_64 > > Version : 3.3.3 > > Release : 28.0.1.el7.centos.3 > > Size : 4.1 M > > > I have followed the troubleshooting > guide http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting > and activated logging and activated the core dumping. Unfortunately, I > cannot provide you any core dump, because it is not created after the > ipa servers crashes. I'm sure the dirsrv is causing the problem, > because when i restart the 389, then ipa works fine for a while. > Currently I have activated the replication log level 8192. The error > log shows no suspicious error or any fatal error. Following 389* > versions are used: > > > Installed Packages > > 389-ds-base.x86_64 1.3.3.1-15.el7_1 > @/389-ds-base-1.3.3.1-15.el7_1.x86_64 > > 389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo > > 389-ds-base-libs.x86_64 1.3.3.1-15.el7_1 > > > Can you please provide some hint how I can debug this problem in more > detail. Btw, the ipa infrastructure consist of one master and one > replica. The server was also crashing, when the replica server was > turned off. Do you thing an upgrade would solve the problem as the > last resort? > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sramling at redhat.com Fri Mar 27 15:39:30 2015 From: sramling at redhat.com (Sankar Ramlingam) Date: Fri, 27 Mar 2015 21:09:30 +0530 Subject: [Freeipa-users] passwordStorageScheme In-Reply-To: References: Message-ID: <551579B2.3070605@redhat.com> On 03/27/2015 06:21 PM, Andy Thompson wrote: > Relative newb here :) I'm doing some research trying to sort out the password storage scheme being used on the freeipa LDAP instance. From everything I can find it uses ssha but can be changed to ssha-512. But when I try to change that attribute on the cn=config object like referenced here https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/8.2/html/Administration_Guide/User_Account_Management.html#Configuring_a_Global_Password_Policy_Using_the_Command_Line-Password_Policy_Attributes > > It comes back with wrong attribute type. I realize that doc points to the RHDS so it might be valid for the ipa ds? Hi Andy, The value has to be SHA512. Its not SHA-512. /usr/bin/ldapmodify -x -p 1189 -h localhost -D "cn=Directory Manager" -w XXXXX << EOF > dn: cn=config > changetype: modify > replace: passwordStorageScheme > passwordStorageScheme: SHA-512 > EOF modifying entry "cn=config" ldap_modify: Operations error (1) additional info: passwordStorageScheme: invalid scheme - SHA-512. Valid schemes are: CLEAR, CRYPT, MD5, SHA, SHA256, SHA384, SHA512, SMD5, SSHA, SSHA256, SSHA384, SSHA512 /usr/bin/ldapmodify -x -p 1189 -h localhost -D "cn=Directory Manager" -w XXXXX << EOF dn: cn=config changetype: modify replace: passwordStorageScheme passwordStorageScheme: SHA512 EOF modifying entry "cn=config" Hope this helps. Thanks, -Sankar R. > > So I guess my question is what hash is used by freeipa to store password hashes and is it configurable? > > > *** This communication may contain privileged and/or confidential information. It is intended solely for the use of the addressee. If you are not the intended recipient, you are strictly prohibited from disclosing, copying, distributing or using any of this information. If you received this communication in error, please contact the sender immediately and destroy the material in its entirety, whether electronic or hard copy. *** > > From yamakasi.014 at gmail.com Fri Mar 27 16:07:55 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Fri, 27 Mar 2015 17:07:55 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <55142A54.3010502@redhat.com> References: <54F9EF07.70807@redhat.com> <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> <55142A54.3010502@redhat.com> Message-ID: I'm almost there but what happens when I regenerate a certificate for the ldap server I get the following when I visit it through the loadbalancer: no alternative certificate subject name matches target host name 'ldap-01.domain....' I think this is strange as the certificate shows the ldap under the altnames for HTTP/ldap-01 but there is indeed no ldap-01 as altname but only on the certificate itself. 2015-03-26 16:48 GMT+01:00 Rob Crittenden : > Matt . wrote: >> HI Rob, >> >> Yes something is wrong there I guess. > > In any case, it doesn't apply to what you're trying to do. > >> But still, I actually need to add a SAN to the webserver cert, which >> is different I think than the services at least. >> >> So the question there is... how ? > > What webserver cert? Are you trying to load balance the IPA services via > DNS? > > Not knowing what you want, I'm just answering what you are ASKING. That > is not the same as giving a proper answer. I have the feeling you want > to load balance IPA in general which isn't going to work without a ton > of (ongoing) manual effort. Even Microsoft recommends against trying > this in its AD environment: http://support.microsoft.com/en-us/kb/325608 > > In any case, the instructions I've already provided still apply. > > If you want to replace the Apache webserver cert you'll just need to do > a couple of things first which has the potential of completely breaking > IPA, so you'll need to be careful. > > Before you do anything, backup *.db in /etc/httpd/alias. > > Stop tracking the Apache cert in certmonger: > > # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert > > Delete the existing cert: > > # certutil -D -d /etc/httpd/alias -n Server-Cert > > Like I said, destructive. > > Finally use certmonger to get a new cert that includes a SAN. The syntax > is slightly different than before, mostly because I'm just guessing in > the dark because you aren't including enough details into what you're > trying. > > # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com > -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt > > In this case the IPA server is ipa1.example.com and you're creating a > SAN for ipa.example.com. > > Restart httpd. > > Note that this doesn't solve the Kerberos problem so cli access will > still not work as expected. The UI _might_ work using forms-based > authentication. > > I'd strongly urge you to think about the top of this e-mail before > proceeding onto the bottom. > > rob > >> >> Cheers, >> >> Matt >> >> 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> When digging around I see this documentation: >>>> >>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>>> >>>> I would except that server.example.com is not going to be accepted by >>>> IPA when you visit the webgui like that ? >>> >>> These are SRV records for the ldap service. Think of it as discovery for >>> who provides ldap service in the domain. It isn't something used by a >>> web browser. >>> >>> I'm no DNS expert (by far) but this example looks a little wonky. I'd >>> think it should be example.com and not server.example.com. But in any >>> case it is irrelevant to a browser. >>> >>> rob >>> > From sdutina at gmail.com Fri Mar 27 17:00:43 2015 From: sdutina at gmail.com (Srdjan Dutina) Date: Fri, 27 Mar 2015 17:00:43 +0000 Subject: [Freeipa-users] Active Directory Kerberos authentication on older versions of IPA clients Message-ID: Hi, I created the following test environment: 1. IPA server: v4.1.3 on Centos 7 2. Two-way trust with Active directory domain - Windows server 2012 R2 3. Connected multiple IPA clients: - Fedora 21 - v4.1.3 - Centos 7 - v3.3.3 - Centos 6.6 v.3.0.0 to IPA domain. Using Kerberos ticket for AD user, I'm able to ssh to IPA server and Fedora client, but not to Centos clients, which have older IPA client versions. These clients just skip gssapi-with-mic auth and continue to password login (which is successful). Just to add that I can obtain Kerberos ticket using 'kinit' command for AD user from all clients and also get user and group IDs using 'id' command. Additionally, is it possible to join Centos 5 client to latest IPA server? Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Fri Mar 27 17:08:24 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Fri, 27 Mar 2015 18:08:24 +0100 Subject: [Freeipa-users] Active Directory Kerberos authentication on older versions of IPA clients In-Reply-To: References: Message-ID: <20150327170824.GQ10622@hendrix.redhat.com> On Fri, Mar 27, 2015 at 05:00:43PM +0000, Srdjan Dutina wrote: > Hi, > > I created the following test environment: > > 1. IPA server: v4.1.3 on Centos 7 > 2. Two-way trust with Active directory domain - Windows server 2012 R2 > 3. Connected multiple IPA clients: > - Fedora 21 - v4.1.3 > - Centos 7 - v3.3.3 > - Centos 6.6 v.3.0.0 > > to IPA domain. > > Using Kerberos ticket for AD user, I'm able to ssh to IPA server and Fedora > client, but not to Centos clients, which have older IPA client versions. > These clients just skip gssapi-with-mic auth and continue to password login > (which is successful). > > Just to add that I can obtain Kerberos ticket using 'kinit' command for AD > user from all clients and also get user and group IDs using 'id' command. > > Additionally, is it possible to join Centos 5 client to latest IPA server? > > Thank you. Sounds a bit like the auth_to_local rules might be acting up, did you configure krb5.conf according to http://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5.conf ? From guertin at middlebury.edu Fri Mar 27 17:16:20 2015 From: guertin at middlebury.edu (Guertin, David S.) Date: Fri, 27 Mar 2015 17:16:20 +0000 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <20150327151829.GC29843@p.redhat.com> References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> <1427298281.8302.62.camel@willson.usersys.redhat.com> <55134C60.3060505@redhat.com> <20150326082321.GI3550@p.redhat.com> <20150326164019.GD7785@p.redhat.com> <42855eae690c458aabe8f9dc7978f222@greyhound.middlebury.edu> <20150327151829.GC29843@p.redhat.com> Message-ID: <748eaa3346f04ae9bdd2909804c8c8b3@greyhound.middlebury.edu> >The most likely reason for 'Protocol error' is that the server this client is >connected to does not support the special LDAP extended operation used by >SSSD on IPA clients to get the data for users and groups from trusted >domains. And the most likely reason for this is that ipa-adtrust-install is not >run on that server. Please note that while 'ipa trust-add ...' must be only run >once on one of the IPA servers, ipa-adtrust-install must be run on all, e.g. to >enable the LDAP extended operation mentioned above. > >You can check if the exop is enabled on the servers by running > >ldapsearch -h localhost -x -b '' -s base|grep 2.16.840.1.113730.3.8.10.4 > >on each server. YOu should see 1, for RHEL-7.1 even 2 lines of output. You are correct; I had not run ipa-adtrust-install on the replica servers. I have done that, and now the ldapsearch command works correctly and the "Protocol error" statement is gone from the logs. But there was something else going on and users still could not log in to the client. The log files indicated that there was a permissions problem with /tmp. I changed it to root: root 777, and now logins are working. Thanks! David Guertin From prasun.gera at gmail.com Fri Mar 27 17:20:12 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Fri, 27 Mar 2015 13:20:12 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: <55156455.7090401@redhat.com> References: <55148136.8040003@redhat.com> <5514C804.4040207@redhat.com> <55156455.7090401@redhat.com> Message-ID: > > Keys can be generated in migration in two ways: by the migration web UI > or by sssd. I'm guessing you were unaware of this second method and that > is how the keys are being created. > > That's what I suspected too. But it doesn't look like SSSD is generating keys. At least not right away. I SSHed to one of the clients with ipa-client installed as well as to the ipa-server, and that didn't change anything right away. That's what I was trying to figure out. i.e Which event triggers key generation ? > I'd suggest using nss_ldap over NIS. You can also manually configure > Kerberos and have basic functionality as long as nscld doesn't drive you > crazy. > Thanks. I'll look into it. > > It's not the encryption type, it is how it is encoded in 389-ds. When > you migrated the passwords they were stored as {crypt}hash. When the > password is changed in 389-ds it becomes {SSHA}hash. The NIS > configuration for slapi-nis only provides those passwords prefixed with > {crypt} (because NIS can only grok that format). > rob > Yeah that sounds like a possible fix, although a less than ideal one. Is it possible to change it back to {SSHA} after all the clients have been migrated suitably ? How would one force all the existing users' passwords to be converted to {SSHA} once slapi-nis is no longer needed ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Fri Mar 27 17:36:26 2015 From: sbose at redhat.com (Sumit Bose) Date: Fri, 27 Mar 2015 18:36:26 +0100 Subject: [Freeipa-users] Clients are reading AD info inconsistently In-Reply-To: <748eaa3346f04ae9bdd2909804c8c8b3@greyhound.middlebury.edu> References: <5511E49A.2050101@redhat.com> <24041f9f15f44f67b95852d6c400b7f4@greyhound.middlebury.edu> <1427298281.8302.62.camel@willson.usersys.redhat.com> <55134C60.3060505@redhat.com> <20150326082321.GI3550@p.redhat.com> <20150326164019.GD7785@p.redhat.com> <42855eae690c458aabe8f9dc7978f222@greyhound.middlebury.edu> <20150327151829.GC29843@p.redhat.com> <748eaa3346f04ae9bdd2909804c8c8b3@greyhound.middlebury.edu> Message-ID: <20150327173626.GE29843@p.redhat.com> On Fri, Mar 27, 2015 at 05:16:20PM +0000, Guertin, David S. wrote: > >The most likely reason for 'Protocol error' is that the server this client is > >connected to does not support the special LDAP extended operation used by > >SSSD on IPA clients to get the data for users and groups from trusted > >domains. And the most likely reason for this is that ipa-adtrust-install is not > >run on that server. Please note that while 'ipa trust-add ...' must be only run > >once on one of the IPA servers, ipa-adtrust-install must be run on all, e.g. to > >enable the LDAP extended operation mentioned above. > > > >You can check if the exop is enabled on the servers by running > > > >ldapsearch -h localhost -x -b '' -s base|grep 2.16.840.1.113730.3.8.10.4 > > > >on each server. YOu should see 1, for RHEL-7.1 even 2 lines of output. > > You are correct; I had not run ipa-adtrust-install on the replica servers. I have done that, and now the > ldapsearch command works correctly and the "Protocol error" statement is gone from the logs. But > there was something else going on and users still could not log in to the client. > > The log files indicated that there was a permissions problem with /tmp. I changed it to root: root 777, and > now logins are working. Thanks! Thank you for the feedback. Please note that /tmp/ should be 1777 (sticky bit set) so that only owners can delete files. bye, Sumit > > David Guertin > From rcritten at redhat.com Fri Mar 27 17:57:24 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Mar 2015 13:57:24 -0400 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> <55142A54.3010502@redhat.com> Message-ID: <55159A04.1040807@redhat.com> Matt . wrote: > I'm almost there but what happens when I regenerate a certificate for > the ldap server I get the following when I visit it through the > loadbalancer: > > no alternative certificate subject name matches target host name > 'ldap-01.domain....' > > I think this is strange as the certificate shows the ldap under the > altnames for HTTP/ldap-01 but there is indeed no ldap-01 as altname > but only on the certificate itself. It turns out that NSS implements cert checking very strictly following RFC 2818 while OpenSSL is a bit more lax about it. The RFC states that if there is a subjectAltName then only that is used to validate the hostname. And in fact, it discourages using the subject at all and ONLY relying on the subjectAltName, though it does recognize that it is current practice (and was that way in 2000 as well). So you need to request your new cert with TWO names: the host name and the alternate name. That should make the cert work anyway. rob > > > > 2015-03-26 16:48 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> HI Rob, >>> >>> Yes something is wrong there I guess. >> >> In any case, it doesn't apply to what you're trying to do. >> >>> But still, I actually need to add a SAN to the webserver cert, which >>> is different I think than the services at least. >>> >>> So the question there is... how ? >> >> What webserver cert? Are you trying to load balance the IPA services via >> DNS? >> >> Not knowing what you want, I'm just answering what you are ASKING. That >> is not the same as giving a proper answer. I have the feeling you want >> to load balance IPA in general which isn't going to work without a ton >> of (ongoing) manual effort. Even Microsoft recommends against trying >> this in its AD environment: http://support.microsoft.com/en-us/kb/325608 >> >> In any case, the instructions I've already provided still apply. >> >> If you want to replace the Apache webserver cert you'll just need to do >> a couple of things first which has the potential of completely breaking >> IPA, so you'll need to be careful. >> >> Before you do anything, backup *.db in /etc/httpd/alias. >> >> Stop tracking the Apache cert in certmonger: >> >> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert >> >> Delete the existing cert: >> >> # certutil -D -d /etc/httpd/alias -n Server-Cert >> >> Like I said, destructive. >> >> Finally use certmonger to get a new cert that includes a SAN. The syntax >> is slightly different than before, mostly because I'm just guessing in >> the dark because you aren't including enough details into what you're >> trying. >> >> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com >> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt >> >> In this case the IPA server is ipa1.example.com and you're creating a >> SAN for ipa.example.com. >> >> Restart httpd. >> >> Note that this doesn't solve the Kerberos problem so cli access will >> still not work as expected. The UI _might_ work using forms-based >> authentication. >> >> I'd strongly urge you to think about the top of this e-mail before >> proceeding onto the bottom. >> >> rob >> >>> >>> Cheers, >>> >>> Matt >>> >>> 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >>>> Matt . wrote: >>>>> When digging around I see this documentation: >>>>> >>>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>>>> >>>>> I would except that server.example.com is not going to be accepted by >>>>> IPA when you visit the webgui like that ? >>>> >>>> These are SRV records for the ldap service. Think of it as discovery for >>>> who provides ldap service in the domain. It isn't something used by a >>>> web browser. >>>> >>>> I'm no DNS expert (by far) but this example looks a little wonky. I'd >>>> think it should be example.com and not server.example.com. But in any >>>> case it is irrelevant to a browser. >>>> >>>> rob >>>> >> From coy.hile at coyhile.com Fri Mar 27 19:33:48 2015 From: coy.hile at coyhile.com (Coy Hile) Date: Fri, 27 Mar 2015 15:33:48 -0400 Subject: [Freeipa-users] How to add 'generic' service? Message-ID: <641EBD7A-61CB-4124-B8E1-CFFAF8D0524A@coyhile.com> I?m rebuilding my existing heimdal realm using FreeIPA, and right now I?m having difficulty creating the service principal afs/realm-name at REALM. When I use ipa service-add, I get output thusly: [root at ipa-us-east-2 ~]# ipa service-add afs/coyhile.com at COYHILE.COM ipa: ERROR: The host 'coyhile.com' does not exist to add a service to. [root at ipa-us-east-2 ~]# ipa service-add afs/coyhile.com at COYHILE.COM --force ipa: ERROR: The host 'coyhile.com' does not exist to add a service to. It?s an arbitrary principal; it really shouldn?t matter? So, being a knowledgable administrator of both MIT and Heimdal KDCs, I decided to break out kadmin. kadmin.local: ank -randkey -e aes256-cts:normal afs/coyhile.com at COYHILE.COM WARNING: no policy specified for afs/coyhile.com at COYHILE.COM; defaulting to no policy add_principal: Kerberos database constraints violated while creating "afs/coyhile.com at COYHILE.COM?. This brings up two questions: Firstly, is there some secret sauce I have to use to make ipa do my bidding here? On a related note is there a way to restrict enctypes? Since everything that I?m dealing with is either recent Linux, recent Illumos, or (gag!) sufficiently recent Windows, I?d like to restrict everything to AES only and get rid of des3 and arcfour-hmac. -- Coy Hile coy.hile at coyhile.com From rcritten at redhat.com Fri Mar 27 19:53:56 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Fri, 27 Mar 2015 15:53:56 -0400 Subject: [Freeipa-users] How to add 'generic' service? In-Reply-To: <641EBD7A-61CB-4124-B8E1-CFFAF8D0524A@coyhile.com> References: <641EBD7A-61CB-4124-B8E1-CFFAF8D0524A@coyhile.com> Message-ID: <5515B554.5070106@redhat.com> Coy Hile wrote: > I?m rebuilding my existing heimdal realm using FreeIPA, and right now I?m having difficulty creating the service principal afs/realm-name at REALM. When I use ipa service-add, I get output thusly: > > [root at ipa-us-east-2 ~]# ipa service-add afs/coyhile.com at COYHILE.COM > ipa: ERROR: The host 'coyhile.com' does not exist to add a service to. > [root at ipa-us-east-2 ~]# ipa service-add afs/coyhile.com at COYHILE.COM --force > ipa: ERROR: The host 'coyhile.com' does not exist to add a service to. > > It?s an arbitrary principal; it really shouldn?t matter? You need to create the host coyhile.com first. > So, being a knowledgable administrator of both MIT and Heimdal KDCs, I decided to break out kadmin. > > > kadmin.local: ank -randkey -e aes256-cts:normal afs/coyhile.com at COYHILE.COM > WARNING: no policy specified for afs/coyhile.com at COYHILE.COM; defaulting to no policy > add_principal: Kerberos database constraints violated while creating "afs/coyhile.com at COYHILE.COM?. Probably same reason. We don't recommend using kadmin.local in general. > > This brings up two questions: > > Firstly, is there some secret sauce I have to use to make ipa do my bidding here? On a related note is there a way to restrict enctypes? Since everything that I?m dealing with is either recent Linux, recent Illumos, or (gag!) sufficiently recent Windows, I?d like to restrict everything to AES only and get rid of des3 and arcfour-hmac. You can manage the default and enabled encryption types in cn=EXAMPLE.COM,cn=kerberos,dc=example,dc=com I'm not sure if the KDC reads these on the fly so you may want to restart it after modifying the values. Or you can control what encryption types are used in keytabs using the -e option to ipa-getkeytab. A couple of keytabs are issued during install that will have other keys so you may want/need to fetch new keytabs if you change the defaults. rob From simo at redhat.com Fri Mar 27 20:10:24 2015 From: simo at redhat.com (Simo Sorce) Date: Fri, 27 Mar 2015 16:10:24 -0400 Subject: [Freeipa-users] How to add 'generic' service? In-Reply-To: <641EBD7A-61CB-4124-B8E1-CFFAF8D0524A@coyhile.com> References: <641EBD7A-61CB-4124-B8E1-CFFAF8D0524A@coyhile.com> Message-ID: <1427487024.8302.128.camel@willson.usersys.redhat.com> On Fri, 2015-03-27 at 15:33 -0400, Coy Hile wrote: > I?m rebuilding my existing heimdal realm using FreeIPA, and right now > I?m having difficulty creating the service principal > afs/realm-name at REALM. When I use ipa service-add, I get output thusly: > > [root at ipa-us-east-2 ~]# ipa service-add afs/coyhile.com at COYHILE.COM > ipa: ERROR: The host 'coyhile.com' does not exist to add a service to. > [root at ipa-us-east-2 ~]# ipa service-add afs/coyhile.com at COYHILE.COM --force > ipa: ERROR: The host 'coyhile.com' does not exist to add a service to. > > It?s an arbitrary principal; it really shouldn?t matter? We should probably add a RFE to decide how to handle/support these cases officially, but see later. > So, being a knowledgable administrator of both MIT and Heimdal KDCs, I > decided to break out kadmin. > > > kadmin.local: ank -randkey -e aes256-cts:normal > afs/coyhile.com at COYHILE.COM > WARNING: no policy specified for afs/coyhile.com at COYHILE.COM; > defaulting to no policy > add_principal: Kerberos database constraints violated while creating > "afs/coyhile.com at COYHILE.COM?. Our DAL plugin, normally, prevents you from adding principals via the kadmin interface because kadmin does not know how to create a properly functional user or service object. It would also create them in the wrong place (under cn=kerberos,). > This brings up two questions: > > Firstly, is there some secret sauce I have to use to make ipa do my > bidding here? Glad you asked, there actually is an non orthodox, non supported, secret way :-) But use it only for principals you know are really not user principals or normal service principals. The trick is to use kadmin.local with the switch: -x ipa-setup-override-restrictions > On a related note is there a way to restrict enctypes? Yes, you can do that by setting the appropriate supported and default enctypes in LDAP. They are in cn=YOUR.REALM,cn=kerberos, in the attributes krbDefaultEncSaltTypes and krbSupportedEncSaltTypes Unfortunately we do not expose this configuration via the UI. > Since everything that I?m dealing with is either recent Linux, > recent Illumos, or (gag!) sufficiently recent Windows, I?d like to > restrict everything to AES only and get rid of des3 and arcfour-hmac. Good idea, in the IETF Kitten WG we are also starting the process to deprecate RC4 and 3DES and we have a ticket to stop using them by default in FreeIPA too: https://fedorahosted.org/freeipa/ticket/4740 HTH, Simo. -- Simo Sorce * Red Hat, Inc * New York From dpal at redhat.com Fri Mar 27 20:34:10 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 27 Mar 2015 16:34:10 -0400 Subject: [Freeipa-users] Fwd: Unexpected IPA Crashes In-Reply-To: <55157825.9050807@redhat.com> References: <833d0e26-2a27-4b71-8dc5-c4cd0eb51f92@zimbra.bytesource.net> <55157825.9050807@redhat.com> Message-ID: <5515BEC2.50106@redhat.com> On 03/27/2015 11:32 AM, Sankar Ramlingam wrote: > On 03/27/2015 01:42 PM, David Kreuter wrote: >> No, there are no entries with "segfaulter" neither in >> /var/log/messags nor in journalctr. >> >> Meanwhile we encountered several directory server hangs and I was >> able to produce the stacktrace. Perhpas you can have a look. > Hi David, > You seem to have the latest/released version of 389-ds-base. You > can probably try an upgrade to get the latest of other dependent > components and 389-ds-base-debuginfo. Yes. Please add this package and try to capture the stack trace again. We will then be able to see where the issue is. > > Thanks, > -Sankar R. > >> >> ------------------------------------------------------------------------ >> *From: *"David Kreuter" >> *To: *"freeipa-users" >> *Sent: *Thursday, 26 March, 2015 11:18:59 PM >> *Subject: *Unexpected IPA Crashes >> >> We have been using FreeIPA since two years and were more than happy. >> But since two weeks we are facing unexpected crashed and can not >> really debug the strange behaviours. The crashes are definitely not >> caused by connecting a new system or changing the LDAP schema >> heavily. Following IPA is used: >> >> Name : ipa-server >> >> Arch : x86_64 >> >> Version : 3.3.3 >> >> Release : 28.0.1.el7.centos.3 >> >> Size : 4.1 M >> >> >> I have followed the troubleshooting guide >> http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting >> and activated logging and activated the core dumping. Unfortunately, >> I cannot provide you any core dump, because it is not created after >> the ipa servers crashes. I'm sure the dirsrv is causing the problem, >> because when i restart the 389, then ipa works fine for a while. >> Currently I have activated the replication log level 8192. The error >> log shows no suspicious error or any fatal error. Following 389* >> versions are used: >> >> >> Installed Packages >> >> 389-ds-base.x86_64 1.3.3.1-15.el7_1 >> @/389-ds-base-1.3.3.1-15.el7_1.x86_64 >> >> 389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo >> >> 389-ds-base-libs.x86_64 1.3.3.1-15.el7_1 >> >> >> Can you please provide some hint how I can debug this problem in more >> detail. Btw, the ipa infrastructure consist of one master and one >> replica. The server was also crashing, when the replica server was >> turned off. Do you thing an upgrade would solve the problem as the >> last resort? >> >> >> >> >> > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sylvation.com Fri Mar 27 20:52:12 2015 From: steve at sylvation.com (Steve Neuharth) Date: Fri, 27 Mar 2015 15:52:12 -0500 Subject: [Freeipa-users] using dogtag outside of freeIPA? Message-ID: Hello, Is it possible or perhaps not recommended to use the dogtag API and/or UI on a FreeIPA system without using the freeIPA CLI or UI? I have a requirement to submit a certificate to a service without kerberos and without client software installed using a RESTful API. Dogtag API is very well documented and I do not want to associate all my certificates with a Kerberos principal because it adds complexity to the cert signing process. I just need to sign a cert without the FreeIPA overhead. I tried to get to the Dogtag web UI through the url http://ipa.example.com/ca/ee/ca but I get an unauthenticated web page (no password prompt) and broken image links. This tells me that perhaps the Dogtag UI in a FreeIPA installation is not meant to be used without FreeIPA. Is that correct? I know this is a weird use case and not necessarily a FreeIPA problem but if someone could advise, I'd greatly appreciate it. --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Fri Mar 27 20:55:59 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 27 Mar 2015 16:55:59 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: References: <55148136.8040003@redhat.com> <5514C804.4040207@redhat.com> <55156455.7090401@redhat.com> Message-ID: <5515C3DF.5020701@redhat.com> On 03/27/2015 01:20 PM, Prasun Gera wrote: > > > Keys can be generated in migration in two ways: by the migration > web UI > or by sssd. I'm guessing you were unaware of this second method > and that > is how the keys are being created. > > > That's what I suspected too. But it doesn't look like SSSD is > generating keys. At least not right away. I SSHed to one of the > clients with ipa-client installed as well as to the ipa-server, and > that didn't change anything right away. That's what I was trying to > figure out. i.e Which event triggers key generation ? > > I'd suggest using nss_ldap over NIS. You can also manually configure > Kerberos and have basic functionality as long as nscld doesn't > drive you > crazy. > > > Thanks. I'll look into it. > > > It's not the encryption type, it is how it is encoded in 389-ds. When > you migrated the passwords they were stored as {crypt}hash. When the > password is changed in 389-ds it becomes {SSHA}hash. The NIS > configuration for slapi-nis only provides those passwords prefixed > with > {crypt} (because NIS can only grok that format). > > > rob > > > Yeah that sounds like a possible fix, although a less than ideal one. > Is it possible to change it back to {SSHA} after all the clients have > been migrated suitably ? How would one force all the existing users' > passwords to be converted to {SSHA} once slapi-nis is no longer needed ? > > > The idea is that you tel lall the users to either login via migration page or via SSSD. If your server is in a migration mode the migration page should be available and SSSD should detect that server is in migration mode. In this case any authentication via SSSD will end up creating proper hashes for Kerberos. I suspect this is when the conversion of the LDAP hashes happens too. You suggested that this is not the case but I am not sure that the test was 100 correct. Please try: - check that migration mode is on - check that user does not have kerberos password only LDAP hash from NIS migration - ssh into a box that runs SSSD with such user, authenticate As a result you should see Kerberos hash created for this user and I suspect the LDAP hash is converted at the same time. -- 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 Fri Mar 27 20:57:52 2015 From: dpal at redhat.com (Dmitri Pal) Date: Fri, 27 Mar 2015 16:57:52 -0400 Subject: [Freeipa-users] using dogtag outside of freeIPA? In-Reply-To: References: Message-ID: <5515C450.5050404@redhat.com> On 03/27/2015 04:52 PM, Steve Neuharth wrote: > Hello, > > Is it possible or perhaps not recommended to use the dogtag API and/or > UI on a FreeIPA system without using the freeIPA CLI or UI? I have a > requirement to submit a certificate to a service without kerberos and > without client software installed using a RESTful API. Dogtag API is > very well documented and I do not want to associate all my > certificates with a Kerberos principal because it adds complexity to > the cert signing process. I just need to sign a cert without the > FreeIPA overhead. > > I tried to get to the Dogtag web UI through the url > http://ipa.example.com/ca/ee/ca but I get an unauthenticated web page > (no password prompt) and broken image links. This tells me that > perhaps the Dogtag UI in a FreeIPA installation is not meant to be > used without FreeIPA. Is that correct? > > I know this is a weird use case and not necessarily a FreeIPA problem > but if someone could advise, I'd greatly appreciate it. For now you should use Dogtag by itself for this use case without IPA. We are working on making it easier for this use case to be possible via IPA but it is not there yet. > --steve > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sipazzo at yahoo.com Fri Mar 27 22:42:02 2015 From: sipazzo at yahoo.com (sipazzo) Date: Fri, 27 Mar 2015 15:42:02 -0700 Subject: [Freeipa-users] Need to replace cert for ipa servers In-Reply-To: <55132C18.8050406@redhat.com> Message-ID: <1427496122.60501.YahooMailBasic@web122503.mail.ne1.yahoo.com> Rob, thank you,you have been so helpful. This appears to have worked in my sandbox environment. I was able to get the new certs for the directory server and apache, stop tracking and remove the old Go Daddy certs, put my original CA certs in the correct locations and import into the databases, then configure the services to use them. I am going to move some clients into sandbox next week(we have rhel5, 6 and SOlaris)and see how they handle the new config before rolling out to prod environment and other ipa servers. Thank you for everything. -------------------------------------------- On Wed, 3/25/15, Rob Crittenden wrote: Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers To: "sipazzo" , "freeipa-users at redhat.com" Date: Wednesday, March 25, 2015, 2:43 PM sipazzo wrote: > Ok I finally was able to get a sandbox environment up to test the cert > replacement. When I ran this stepgot to the cert request steps: > ipa-getcert request -d /etc/dirsrv/slapd-IPADOMAIN-COM -n Server-Cert -p > /etc/dirsrv/slapd-IPADOMAIN-COM/pwdfile.txt -C > '/usr/lib64/ipa/certmonger/restart_dirsrv IPADOMAIN-COM' -N > CN=idm2-corp.ipadomain.com -K ldap/ipa2-corp.ipadomain.com at IPADOMAIN.COM > > I got a message saying the cert at same location is already used by > request with nickname "20140729215511" , same when I ran it for > /etc/httpd/alias. I continued on anyway but when I get to this step: You need to tell certmonger to stop tracking the existing GoDaddy certs, not that they would have been renewable anyway. You may also need to remove them from the NSS database(s) using something like: # certutil -D -n 'nickname' -d /path/to/db I think the subject will be different enough that it may be ok as-is. The other errors are due to the fact that no certificate was issued. rob > >? # certutil -V -u V -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM > > I get an error: > certutil: could not find certificate named "Server-Cert": > PR_FILE_NOT_FOUND_ERROR: File not found > > Although running certutil -L -d /etc/dirsrv/slapd-IPADOMAIN-COM/, > returns this: > > Certificate Nickname? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???Trust > Attributes >? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ??? > SSL,S/MIME,JAR/XPI > > GD_CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,C,C > IPADOMAIN.COM IPA CA? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? CT,, > NWF_GD? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? ???u,u,u > > > Showing that the IPA Dogtag cert is now listed whereas it was not > previously. > > > ------------------------------------------------------------------------ > *From:* sipazzo > *To:* Rob Crittenden ; "freeipa-users at redhat.com" > > *Sent:* Friday, March 13, 2015 1:32 PM > *Subject:* Re: [Freeipa-users] Fw: Need to replace cert for ipa servers > > This environment is over 350 servers, many of which are in production so > I may have to wait a bit for change management approval to attempt to > resolve this issue, particularly if you think it might break something. > I will keep you updated on my progress. Thank you much. > > > > ------------------------------------------------------------------------ > *From:* sipazzo > *To:* Rob Crittenden > *Cc:* "freeipa-users at redhat.com" > *Sent:* Friday, March 13, 2015 9:21 AM > *Subject:* Re: [Freeipa-users] Fw: Need to replace cert for ipa servers > > > > > > -----Original Message----- > From: freeipa-users-bounces at redhat.com > > [mailto:freeipa-users-bounces at redhat.com > ] On Behalf Of Rob Crittenden > Sent: Thursday, March 12, 2015 1:52 PM > To: sipazzo; freeipa-users at redhat.com > Subject: Re: [Freeipa-users] Fw: Need to replace cert for ipa servers > > sipazzo wrote: >> I do have other CAs (just not the master but it is available offline >> if >> needed) > > To be clear, all IPA servers are masters, some just run more services > than others. It sounds like you have at least one CA available which > should be sufficient. > >> Directory server is running >> The apache web server is running and I can get to the gui ipa >> cert-show 1 works > > Ok. I guess the place to start is to get certs for Apache and 389-ds, > then we can see about using these new certs. > > In the thread you showed that the IPA 389-ds doesn't have a Server-Cert > nickname. You'll want to do the same for /etc/httpd/alias before running > the following commands otherwise you could end up with non-functional > server. > > These should get IPA certs for 389-ds and Apache. You'll need to edit > these commands to match your environment: > > # ipa-getcert request -d /etc/httpd/alias -n Server-Cert -p > /etc/httpd/alias/pwdfile.txt -C /usr/lib64/ipa/certmonger/restart_httpd > -N CN=ipa.example.com -K HTTP/ipa.example.com at EXAMPLE.COM > > > # ipa-getcert request -d /etc/dirsrv/slapd-EXAMPLE-COM -n Server-Cert -p > /etc/dirsrv/slapd-EXAMPLE-COM/pwdfile.txt -C > '/usr/lib64/ipa/certmonger/restart_dirsrv EXAMPLE-COM' -N > CN=ipa.example.com -K ldap/ipa.example.com at EXAMPLE.COM > > > I'd do them one at a time and wait until the cert is issued and tracked. > This will restart both Apache and 389-ds but it shouldn't affect > operation because the certs won't be used yet. > > You then need to get the old CA cert and put it into the right places. > Since it is already in the PKI-IPA NSS database let's fetch it from > there. For giggles you should probably save whatever the contents of > /etc/ipa/ca.crt are before-hand. > > # certutil -L -d /etc/dirsrv/slapd-PKI-IPA -n 'IPADOMAIN.COM IPA CA' -a >> /etc/ipa/ca.crt > > Now add that to the Apache and 389-ds databases: > > # certutil -A -n 'IPADOMAIN.COM IPA CA' -d /etc/httpd/alias -t CT,C, -a > -i /etc/ipa/ca.crt # certutil -A -n 'IPADOMAIN.COM IPA CA' -d > /etc/dirsrv/slapd-EXAMPLE-COM -t CT,, -a -i /etc/ipa/ca.crt > > Next add it to /etc/pki/nssdb if it isn't already there: > > # certutil -A -n 'IPA CA' -d /etc/pki/nssdb -t CT,C,C -a -i /etc/ipa/ca.crt > > Next, verify that the newly issued certs are trusted: > > # certutil -V -u V -n Server-Cert -d /etc/httpd/alias # certutil -V -u V > -n Server-Cert -d /etc/dirsrv/slapd-EXAMPLE-COM > > Both should return: > certutil: certificate is valid > > Next is to configure the services to use the new certs. I'd stop IPA to > do this: ipactl stop > > Edit /etc/httpd/conf.d/nss.conf and change the NSSNickname to Server-Cert > > Edit /etc/dirsrv/slapd-EXAMPLE-COM/dse.ldif and set nsSSLPersonalitySSL > to Server-Cert > > Now try to start the world: ipactl start > > Run a few commands: > > # ipa user-show admin > # ipa cert-show 1 > > Both should work. > > Assuming all has gone well to this point, copy /etc/ipa/ca.crt to > /usr/share/ipa/html/ca.crt > > Finally run: ipa-ldap-updater --upgrade > > This should load the new CA certificate into LDAP. > > This has the potential to break a whole bunch of your clients. It is > probably enough to just copy over the new CA cert to the right > location(s) on the clients. The mechanics of this depend on the OS. > >> Are the TLS errors due to the mismatch in certs between slapd-PKI-CA >> and slapd-NETWORKFLEET-COM? > > No, has nothing to do with the CA at all. The client doesn't have (or > trust) the CA that issued the LDAP server cert. > > rob > >> >> >> -----Original Message----- >> >> >> From: freeipa-users-bounces at redhat.com > >> > >> [mailto:freeipa-users-bounces at redhat.com > >> >] On Behalf Of Rob Crittenden >> Sent: Wednesday, March 11, 2015 7:20 PM >> To: sipazzo; freeipa-users at redhat.com >> > >> Subject: Re: [Freeipa-users] Need to replace cert for ipa servers >> >> sipazzo wrote: >>> Thanks Rob, I apologize that error was probably not helpful. This is >>> what I see when running install in debug mode: >>> >>> Verifying that ipa2-corp.networkfleet.com (realm EXAMPLE.COM) is an >>> IPA server Init LDAP connection with: >>> ldap://ipa2-corp.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> Verifying that ipa1-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >>> server Init LDAP connection with: ldap://ipa1-xo.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> Verifying that ipa1-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >>> server Init LDAP connection with: ldap://ipa1-io.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> Verifying that ipa2-io.networkfleet.com (realm EXAMPLE.COM) is an IPA >>> server Init LDAP connection with: ldap://ipa2-io.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> Verifying that ipa2-xo.networkfleet.com (realm EXAMPLE.COM) is an IPA >>> server Init LDAP connection with: ldap://ipa2-xo.networkfleet.com:389 >>> LDAP Error: Connect error: TLS error -8179:Peer's Certificate issuer >>> is not recognized. >>> >>> The certificates are very confusing to me. I don't understand how >>> things are working when we have a set of GoDaddy certs in >>> slapd-NETWORKFLEET-COM and a set of the Dogtag certs in slapd-PKI-CA. >>> The cert in /usr/share/ipa/html/ca.crt looks like the original one >>> issued by the Dogtag cert system and matches the ones on the clients. >>> Not to further confuse things but the original master server that >>> signed all these certs was taken offline months ago due to some >>> issues it was having. I do still have access to it if necessary. >>> >>> As far as why the godaddy certs were swapped out for the Dogtag certs >>> it was originally for something as simple as the untrusted >>> certificate dialogue when accessing the ipa gui. I did not swap out >>> the certs so am unsure of exactly what happened. There is no real >>> need to use the GoDaddy certs as far as I am concerned. I just want >>> the best solution to the issues I am seeing as I am in kind of a bind >>> with the GoDaddy cert being revoked and needing to be replaced and >>> the master Dogtag certificate server offline. We have a mixed >>> environment with Rhel 5, 6 and Solaris clients so are not using sssd > in all cases. >>> >>> I know this is asking a lot but appreciate any help you can give. >> >> What is the current state of things? Does your IPA Apache server work? >> Is 389-ds up and running? Do you have a working IPA CA? >> >> Does ipa cert-show 1 work? >> >> If the answer is yes to all then we should be able to generate new >> certs for all the services. >> >> 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 >> > > -- > 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 yamakasi.014 at gmail.com Fri Mar 27 23:02:22 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 28 Mar 2015 00:02:22 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <55159A04.1040807@redhat.com> References: <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> <55142A54.3010502@redhat.com> <55159A04.1040807@redhat.com> Message-ID: Hi Rob, Thanks for the explanation. I understand your solution, I just thought that was "the dirty" way :) Thanks for your effort! Cheers, Matt 2015-03-27 18:57 GMT+01:00 Rob Crittenden : > Matt . wrote: >> I'm almost there but what happens when I regenerate a certificate for >> the ldap server I get the following when I visit it through the >> loadbalancer: >> >> no alternative certificate subject name matches target host name >> 'ldap-01.domain....' >> >> I think this is strange as the certificate shows the ldap under the >> altnames for HTTP/ldap-01 but there is indeed no ldap-01 as altname >> but only on the certificate itself. > > It turns out that NSS implements cert checking very strictly following > RFC 2818 while OpenSSL is a bit more lax about it. > > The RFC states that if there is a subjectAltName then only that is used > to validate the hostname. And in fact, it discourages using the subject > at all and ONLY relying on the subjectAltName, though it does recognize > that it is current practice (and was that way in 2000 as well). > > So you need to request your new cert with TWO names: the host name and > the alternate name. That should make the cert work anyway. > > rob > >> >> >> >> 2015-03-26 16:48 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> HI Rob, >>>> >>>> Yes something is wrong there I guess. >>> >>> In any case, it doesn't apply to what you're trying to do. >>> >>>> But still, I actually need to add a SAN to the webserver cert, which >>>> is different I think than the services at least. >>>> >>>> So the question there is... how ? >>> >>> What webserver cert? Are you trying to load balance the IPA services via >>> DNS? >>> >>> Not knowing what you want, I'm just answering what you are ASKING. That >>> is not the same as giving a proper answer. I have the feeling you want >>> to load balance IPA in general which isn't going to work without a ton >>> of (ongoing) manual effort. Even Microsoft recommends against trying >>> this in its AD environment: http://support.microsoft.com/en-us/kb/325608 >>> >>> In any case, the instructions I've already provided still apply. >>> >>> If you want to replace the Apache webserver cert you'll just need to do >>> a couple of things first which has the potential of completely breaking >>> IPA, so you'll need to be careful. >>> >>> Before you do anything, backup *.db in /etc/httpd/alias. >>> >>> Stop tracking the Apache cert in certmonger: >>> >>> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert >>> >>> Delete the existing cert: >>> >>> # certutil -D -d /etc/httpd/alias -n Server-Cert >>> >>> Like I said, destructive. >>> >>> Finally use certmonger to get a new cert that includes a SAN. The syntax >>> is slightly different than before, mostly because I'm just guessing in >>> the dark because you aren't including enough details into what you're >>> trying. >>> >>> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com >>> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt >>> >>> In this case the IPA server is ipa1.example.com and you're creating a >>> SAN for ipa.example.com. >>> >>> Restart httpd. >>> >>> Note that this doesn't solve the Kerberos problem so cli access will >>> still not work as expected. The UI _might_ work using forms-based >>> authentication. >>> >>> I'd strongly urge you to think about the top of this e-mail before >>> proceeding onto the bottom. >>> >>> rob >>> >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >>>>> Matt . wrote: >>>>>> When digging around I see this documentation: >>>>>> >>>>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>>>>> >>>>>> I would except that server.example.com is not going to be accepted by >>>>>> IPA when you visit the webgui like that ? >>>>> >>>>> These are SRV records for the ldap service. Think of it as discovery for >>>>> who provides ldap service in the domain. It isn't something used by a >>>>> web browser. >>>>> >>>>> I'm no DNS expert (by far) but this example looks a little wonky. I'd >>>>> think it should be example.com and not server.example.com. But in any >>>>> case it is irrelevant to a browser. >>>>> >>>>> rob >>>>> >>> > From janellenicole80 at gmail.com Sat Mar 28 00:22:15 2015 From: janellenicole80 at gmail.com (Janelle) Date: Fri, 27 Mar 2015 19:22:15 -0500 Subject: [Freeipa-users] anonymous binds limits? Message-ID: <5515F437.4030506@gmail.com> Hello, Just wondering if there is an easy way to increase anonymous binds on the back end for non Kerberos clients? I have seen some mention of it, and that IPA has limits, can't can't find a lot of detail? Thank you ~J From yamakasi.014 at gmail.com Sat Mar 28 09:17:47 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 28 Mar 2015 10:17:47 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: <55159A04.1040807@redhat.com> References: <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> <55142A54.3010502@redhat.com> <55159A04.1040807@redhat.com> Message-ID: Rob, As I was responding a little bit late last night, the following come to mind. As you say I need to request my cert with two names, how do you mean ? I'm using curl at the moment so figuring that out. As the same issues happens in the GUI itself I think this might be a problem. When I access ldap-01 directly it complains @ the services tab on some servicehosts that are in there, and some not. I think this is not a simple PTR or A record fix, I'm curious how to do. Cheers, Matt 2015-03-27 18:57 GMT+01:00 Rob Crittenden : > Matt . wrote: >> I'm almost there but what happens when I regenerate a certificate for >> the ldap server I get the following when I visit it through the >> loadbalancer: >> >> no alternative certificate subject name matches target host name >> 'ldap-01.domain....' >> >> I think this is strange as the certificate shows the ldap under the >> altnames for HTTP/ldap-01 but there is indeed no ldap-01 as altname >> but only on the certificate itself. > > It turns out that NSS implements cert checking very strictly following > RFC 2818 while OpenSSL is a bit more lax about it. > > The RFC states that if there is a subjectAltName then only that is used > to validate the hostname. And in fact, it discourages using the subject > at all and ONLY relying on the subjectAltName, though it does recognize > that it is current practice (and was that way in 2000 as well). > > So you need to request your new cert with TWO names: the host name and > the alternate name. That should make the cert work anyway. > > rob > >> >> >> >> 2015-03-26 16:48 GMT+01:00 Rob Crittenden : >>> Matt . wrote: >>>> HI Rob, >>>> >>>> Yes something is wrong there I guess. >>> >>> In any case, it doesn't apply to what you're trying to do. >>> >>>> But still, I actually need to add a SAN to the webserver cert, which >>>> is different I think than the services at least. >>>> >>>> So the question there is... how ? >>> >>> What webserver cert? Are you trying to load balance the IPA services via >>> DNS? >>> >>> Not knowing what you want, I'm just answering what you are ASKING. That >>> is not the same as giving a proper answer. I have the feeling you want >>> to load balance IPA in general which isn't going to work without a ton >>> of (ongoing) manual effort. Even Microsoft recommends against trying >>> this in its AD environment: http://support.microsoft.com/en-us/kb/325608 >>> >>> In any case, the instructions I've already provided still apply. >>> >>> If you want to replace the Apache webserver cert you'll just need to do >>> a couple of things first which has the potential of completely breaking >>> IPA, so you'll need to be careful. >>> >>> Before you do anything, backup *.db in /etc/httpd/alias. >>> >>> Stop tracking the Apache cert in certmonger: >>> >>> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert >>> >>> Delete the existing cert: >>> >>> # certutil -D -d /etc/httpd/alias -n Server-Cert >>> >>> Like I said, destructive. >>> >>> Finally use certmonger to get a new cert that includes a SAN. The syntax >>> is slightly different than before, mostly because I'm just guessing in >>> the dark because you aren't including enough details into what you're >>> trying. >>> >>> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com >>> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt >>> >>> In this case the IPA server is ipa1.example.com and you're creating a >>> SAN for ipa.example.com. >>> >>> Restart httpd. >>> >>> Note that this doesn't solve the Kerberos problem so cli access will >>> still not work as expected. The UI _might_ work using forms-based >>> authentication. >>> >>> I'd strongly urge you to think about the top of this e-mail before >>> proceeding onto the bottom. >>> >>> rob >>> >>>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >>>>> Matt . wrote: >>>>>> When digging around I see this documentation: >>>>>> >>>>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>>>>> >>>>>> I would except that server.example.com is not going to be accepted by >>>>>> IPA when you visit the webgui like that ? >>>>> >>>>> These are SRV records for the ldap service. Think of it as discovery for >>>>> who provides ldap service in the domain. It isn't something used by a >>>>> web browser. >>>>> >>>>> I'm no DNS expert (by far) but this example looks a little wonky. I'd >>>>> think it should be example.com and not server.example.com. But in any >>>>> case it is irrelevant to a browser. >>>>> >>>>> rob >>>>> >>> > From sdutina at gmail.com Sat Mar 28 09:41:11 2015 From: sdutina at gmail.com (Srdjan Dutina) Date: Sat, 28 Mar 2015 09:41:11 +0000 Subject: [Freeipa-users] Active Directory Kerberos authentication on older versions of IPA clients In-Reply-To: References: Message-ID: Hi Jakub, Thanks for quick response. Yes, there were acting up. I tried to configure them the other day but obviously misconfigured something. Thanks again! -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Sat Mar 28 09:52:23 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Sat, 28 Mar 2015 10:52:23 +0100 Subject: [Freeipa-users] subjectAlternitiveName for webservice In-Reply-To: References: <55019DA1.6060302@redhat.com> <5501A8AC.8050403@redhat.com> <550AD766.5020504@redhat.com> <550C3104.5050500@redhat.com> <55140EA2.9060306@redhat.com> <55142A54.3010502@redhat.com> <55159A04.1040807@redhat.com> Message-ID: Rob, I just saw your message on IRC from a couple of hours ago... timedifference ;) Thanks, Matt 2015-03-28 10:17 GMT+01:00 Matt . : > Rob, > > As I was responding a little bit late last night, the following come to mind. > > As you say I need to request my cert with two names, how do you mean ? > I'm using curl at the moment so figuring that out. > > As the same issues happens in the GUI itself I think this might be a > problem. When I access ldap-01 directly it complains @ the services > tab on some servicehosts that are in there, and some not. > > I think this is not a simple PTR or A record fix, I'm curious how to do. > > Cheers, > > Matt > > 2015-03-27 18:57 GMT+01:00 Rob Crittenden : >> Matt . wrote: >>> I'm almost there but what happens when I regenerate a certificate for >>> the ldap server I get the following when I visit it through the >>> loadbalancer: >>> >>> no alternative certificate subject name matches target host name >>> 'ldap-01.domain....' >>> >>> I think this is strange as the certificate shows the ldap under the >>> altnames for HTTP/ldap-01 but there is indeed no ldap-01 as altname >>> but only on the certificate itself. >> >> It turns out that NSS implements cert checking very strictly following >> RFC 2818 while OpenSSL is a bit more lax about it. >> >> The RFC states that if there is a subjectAltName then only that is used >> to validate the hostname. And in fact, it discourages using the subject >> at all and ONLY relying on the subjectAltName, though it does recognize >> that it is current practice (and was that way in 2000 as well). >> >> So you need to request your new cert with TWO names: the host name and >> the alternate name. That should make the cert work anyway. >> >> rob >> >>> >>> >>> >>> 2015-03-26 16:48 GMT+01:00 Rob Crittenden : >>>> Matt . wrote: >>>>> HI Rob, >>>>> >>>>> Yes something is wrong there I guess. >>>> >>>> In any case, it doesn't apply to what you're trying to do. >>>> >>>>> But still, I actually need to add a SAN to the webserver cert, which >>>>> is different I think than the services at least. >>>>> >>>>> So the question there is... how ? >>>> >>>> What webserver cert? Are you trying to load balance the IPA services via >>>> DNS? >>>> >>>> Not knowing what you want, I'm just answering what you are ASKING. That >>>> is not the same as giving a proper answer. I have the feeling you want >>>> to load balance IPA in general which isn't going to work without a ton >>>> of (ongoing) manual effort. Even Microsoft recommends against trying >>>> this in its AD environment: http://support.microsoft.com/en-us/kb/325608 >>>> >>>> In any case, the instructions I've already provided still apply. >>>> >>>> If you want to replace the Apache webserver cert you'll just need to do >>>> a couple of things first which has the potential of completely breaking >>>> IPA, so you'll need to be careful. >>>> >>>> Before you do anything, backup *.db in /etc/httpd/alias. >>>> >>>> Stop tracking the Apache cert in certmonger: >>>> >>>> # ipa-getcert stop-tracking -d /etc/httpd/alias -n Server-Cert >>>> >>>> Delete the existing cert: >>>> >>>> # certutil -D -d /etc/httpd/alias -n Server-Cert >>>> >>>> Like I said, destructive. >>>> >>>> Finally use certmonger to get a new cert that includes a SAN. The syntax >>>> is slightly different than before, mostly because I'm just guessing in >>>> the dark because you aren't including enough details into what you're >>>> trying. >>>> >>>> # ipa-getcert -d /etc/httpd/alias -n Server-Cert -N CN=ipa1.example.com >>>> -K HTTP/ipa1.example.com -D ipa.example.com -p /etc/httpd/alias/pwdfile.txt >>>> >>>> In this case the IPA server is ipa1.example.com and you're creating a >>>> SAN for ipa.example.com. >>>> >>>> Restart httpd. >>>> >>>> Note that this doesn't solve the Kerberos problem so cli access will >>>> still not work as expected. The UI _might_ work using forms-based >>>> authentication. >>>> >>>> I'd strongly urge you to think about the top of this e-mail before >>>> proceeding onto the bottom. >>>> >>>> rob >>>> >>>>> >>>>> Cheers, >>>>> >>>>> Matt >>>>> >>>>> 2015-03-26 14:50 GMT+01:00 Rob Crittenden : >>>>>> Matt . wrote: >>>>>>> When digging around I see this documentation: >>>>>>> >>>>>>> http://docs.fedoraproject.org/en-US/Fedora/17/html/FreeIPA_Guide/load-balancing.html >>>>>>> >>>>>>> I would except that server.example.com is not going to be accepted by >>>>>>> IPA when you visit the webgui like that ? >>>>>> >>>>>> These are SRV records for the ldap service. Think of it as discovery for >>>>>> who provides ldap service in the domain. It isn't something used by a >>>>>> web browser. >>>>>> >>>>>> I'm no DNS expert (by far) but this example looks a little wonky. I'd >>>>>> think it should be example.com and not server.example.com. But in any >>>>>> case it is irrelevant to a browser. >>>>>> >>>>>> rob >>>>>> >>>> >> From gjn at gjn.priv.at Sat Mar 28 15:11:35 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Sat, 28 Mar 2015 16:11:35 +0100 Subject: [Freeipa-users] Freeipa Server down !! Message-ID: <3126552.348nSDbtq8@techz> Hello, is the freeipa.org Server down i have only a Proxy Error Reason: Error reading from remote server -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From g.fer.ordas at unicyber.co.uk Sat Mar 28 17:53:49 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Sat, 28 Mar 2015 10:53:49 -0700 Subject: [Freeipa-users] IPA Client Install on Amazon Linux In-Reply-To: References: <551507AE.3070009@unicyber.co.uk> Message-ID: <5516EAAD.1030701@unicyber.co.uk> Yogesh you do not need to explain me anything. Most people around here are on the same boat and working on this stuff already for quite awhile. I forgot to mention this is for a PROPER sssd run, still you will need all those below as you will get some issues sorted (specially sudo related) So...you need the following If I remember well..: system-arch --> system Architecture libipa_hbac-1.9.2-129.el6.-system_arch-.rpm sssd-client-1.9.2-129.el6.-system_arch-.rpm sssd-1.9.2-129.el6_5.4.-system_arch-.rpm sudo-1.8.6p3-12.el6.-system_arch- I haven't installed the freeIPA client but I have run sssd successfully for a 389-ds server and the above combination worked all right, specially the sudo bit which was a bit of a hell. To get to that point I spent a number of fun days thanks to the limitations provided by amazon on their packages. Do not forget to install the epel and try to look for either "ipa" or "ipa-server" as I doubt that will be called freeipa at all.(I haven't tested that though.) Gonzalo On 27/03/2015 01:03, Yogesh Sharma wrote: > Gonzalo, > > We have some running servers on Amazon Linux and it would be difficult > to migrate all those to CentOS or RHEL as of now. Hence If you can > provide the package's version then it would really help us till the > time we do migration. > > For sure all over new Servers are going to be CentOS or RHEL. > > / > Best Regards, > __________________________________________ > / > /Yogesh Sharma > / > /Email: yks0000 at gmail.com | Web: > www.initd.in / > > RHCE, VCE-CIA, RackSpace Cloud U > My LinkedIn Profile > > > On Fri, Mar 27, 2015 at 1:03 PM, Gonzalo Fernandez Ordas > > wrote: > > Yogesh > > My personal experience using AWS Linux and LDAP is not a good one > and mostly an utter nightmare in relation to packages. > Personally I would recommend you to keep away from AWS Linux and > get a Centos, Fedora or Redhat. > Still, if you want to go ahead, I can give you the right versions > for a couple of packages as the default sudo given by Amazon > simply DOES NOT work (no idea what they have done to it..) > > Thanks > > On 27/03/2015 00:03, Yogesh Sharma wrote: >> Hello, >> >> Is there any repo available for Amazon Linux to install IPA >> Client OR below is the only way to do as found from freeipa-user >> mail archive. >> >> http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html >> >> >> Thanks for the help. >> / >> Best Regards, >> __________________________________________ >> / >> /Yogesh Sharma >> / >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rcritten at redhat.com Sat Mar 28 18:46:50 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sat, 28 Mar 2015 14:46:50 -0400 Subject: [Freeipa-users] Freeipa Server down !! In-Reply-To: <3126552.348nSDbtq8@techz> References: <3126552.348nSDbtq8@techz> Message-ID: <5516F71A.2090201@redhat.com> G?nther J. Niederwimmer wrote: > Hello, > > is the freeipa.org Server down i have only a Proxy Error > > Reason: Error reading from remote server > Should be back up now. rob From sramling at redhat.com Sun Mar 29 08:35:29 2015 From: sramling at redhat.com (Sankar Ramlingam) Date: Sun, 29 Mar 2015 14:05:29 +0530 Subject: [Freeipa-users] passwordStorageScheme In-Reply-To: References: <551579B2.3070605@redhat.com> , <5515961E.5020408@redhat.com> <20b1982dbd804ac6aac0ec95eb047918@TCCCORPEXCH02.TCC.local> <55159A9F.6090204@redhat.com> Message-ID: <5517B951.2060007@redhat.com> On 03/28/2015 12:32 AM, Andy Thompson wrote: > >> -----Original Message----- >> From: Sankar Ramlingam [mailto:sramling at redhat.com] >> Sent: Friday, March 27, 2015 2:00 PM >> To: Andy Thompson >> Subject: Re: [Freeipa-users] passwordStorageScheme >> >> On 03/27/2015 11:17 PM, Andy Thompson wrote: >>>> Can you show me the output for this command? >>>> ldapsearch -LLL -x -p $PORT -h localhost -D "cn=Directory Manager" -w >>>> xxxxx -b "cn=config" |grep -i passwordStorageScheme >>> Returns >>> >>> passwordStorageScheme: SSHA >>> >>> >>>> Also, can you paste me the content of pw.ldif file? and tell me what >>> dn: cn=config >>> changetype: modify >>> replace: passwordStorageScheme >>> passwordStorageScheme: SHA512 >> It looks like some whitespace characters in your ldif file. Can you recreate the >> ldif file with no special/whitespace characters? or can you run ldapmodify >> from command line and change the value directly? . >> >> I copied your ldif file content and it failed for me too. Then, I tried copying my >> ldif file and it was a success. Pasting the content here... >> >> dn: cn=config >> changetype: modify >> replace: passwordStorageScheme >> passwordStorageScheme: SHA512 >> EOF >> > Thanks much for the assist. Haven't ever run into that before. Hi Andy, So, I understand it was a problem with the LDIF file. I hope the problem is solved now. Please confirm. Thanks, -Sankar R. > > -andy From yamakasi.014 at gmail.com Sun Mar 29 08:47:57 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Sun, 29 Mar 2015 10:47:57 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? Message-ID: Hi Guys, Now my Certification issues are solved for using a loadbalancer in front of my ipa servers I get the following: Unable to verify your Kerberos credentials and in my logs: Additional pre-authentication required. This happens when I connect throught my loadbalancers, I see my server coming ni with the right IP. When I access my ipa server directly, not using the loadbalancer IP between it, my kerberos Ticket is valid. I get the feeling that when I use my loadbalancers and because of that I get a 301 redirect it needs a preauth. I see some issues on mailinglists but it doesn't fit my situation. Why wants it the preauth when I already have a valid ticket and my redirect is followed by CURL and posted the right way ? I hope someone has an idea. Thanks, Matt From fedora at obfusc8.org Sun Mar 29 10:35:14 2015 From: fedora at obfusc8.org (Peter Fern) Date: Sun, 29 Mar 2015 21:35:14 +1100 Subject: [Freeipa-users] Freeipa Server down !! In-Reply-To: <5516F71A.2090201@redhat.com> References: <3126552.348nSDbtq8@techz> <5516F71A.2090201@redhat.com> Message-ID: <5517D562.3050103@obfusc8.org> On 29/03/15 05:46, Rob Crittenden wrote: > Should be back up now. > > rob Appears to be dead again. From bentech4you at gmail.com Sun Mar 29 14:18:08 2015 From: bentech4you at gmail.com (Ben .T.George) Date: Sun, 29 Mar 2015 17:18:08 +0300 Subject: [Freeipa-users] how can i give set of users to one particular host In-Reply-To: <5511AAA4.5040408@redhat.com> References: <551169C8.1030005@redhat.com> <5511A587.1040101@redhat.com> <5511A6EC.8050002@redhat.com> <5511AAA4.5040408@redhat.com> Message-ID: HI i have compiled the pam_access modules successfuly and copied access.conf to /etc/security folder. i included other account required pam_access.so and added -:ben ben at infra.com:ALL but still user ben can able to access the machine anyone achieved this? On Tue, Mar 24, 2015 at 9:19 PM, Rob Crittenden wrote: > Ben .T.George wrote: > > please anyone share bit more information on this like real example > > As we've said many times before, we have very little real experience on > Solaris. We do the best we can and sometimes that is going to be in the > form of bread crumbs that may be usable to finding your way to a solution. > > Access control via PAM is a very-well understood problem on Solaris. > Once you have users and groups via nss then IPA is largely out of the > equation. The OS vendor or Solaris-specific groups will know how to do > this far better than us. > > If you find a detailed answer I'd be happy to add it to the freeIPA wiki. > > rob > > > > > On Tue, Mar 24, 2015 at 9:03 PM, Rob Crittenden > > wrote: > > > > Dmitri Pal wrote: > > > On 03/24/2015 01:15 PM, Ben .T.George wrote: > > >> Hi > > >> > > >> current stage is AD users can able to login to solaris box. But i > > >> don't up to what level i can control the user. > > >> > > >> i don't think to there is much pan modules in solaris. still i > cannot > > >> able to make home directory with pam. > > > > > > I think pam_groupdn (if available on Solaris) might help but I > could not > > > find a clear example to share with you here. > > > > I'd suggest looking at pam_access. > > > > rob > > > > > > > >> > > >> > > >> > > >> On Tue, Mar 24, 2015 at 4:42 PM, Dmitri Pal > > >> >> wrote: > > >> > > >> On 03/24/2015 07:20 AM, Ben .T.George wrote: > > >>> HI > > >>> > > >>> i am using IPA 3.3 and my client is solaris 10. > > >>> > > >>> how can i give only some set of users to this client without > > >>> creating user group in ad? > > >>> > > >>> thanks & Regards, > > >>> Ben > > >>> > > >>> > > >> > > >> You can create a group in IPA and make Solaris check that > > group at > > >> the access phase of PAM if Solaris is capable of checking > groups > > >> this way. > > >> > > >> -- > > >> 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 gokulnathb at gmail.com Sun Mar 29 15:50:22 2015 From: gokulnathb at gmail.com (Gokul) Date: Sun, 29 Mar 2015 10:50:22 -0500 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS Message-ID: Hi, I am tried to run some of my user cases with FreeIPA. Have FreeIPA to do only SSH key management in LDAP and PKI management. The understand that every request is kerberized and it has the DNS is must configuration. Can I have FreeIPA to run only SSH Key management with LDAP and a PKI server with dogtag? Thank you Gokul -------------- next part -------------- An HTML attachment was scrubbed... URL: From yks0000 at gmail.com Sun Mar 29 17:14:34 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Sun, 29 Mar 2015 22:44:34 +0530 Subject: [Freeipa-users] IPA Client Install on Amazon Linux In-Reply-To: <5516EAAD.1030701@unicyber.co.uk> References: <551507AE.3070009@unicyber.co.uk> <5516EAAD.1030701@unicyber.co.uk> Message-ID: Thanks Gonzalo. Appreciate your help here, Let me try this. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Sat, Mar 28, 2015 at 11:23 PM, Gonzalo Fernandez Ordas < g.fer.ordas at unicyber.co.uk> wrote: > Yogesh > > you do not need to explain me anything. Most people around here are on > the same boat and working on this stuff already for quite awhile. > > I forgot to mention this is for a PROPER sssd run, still you will need all > those below as you will get some issues sorted (specially sudo related) > > So...you need the following If I remember well..: > > system-arch --> system Architecture > > libipa_hbac-1.9.2-129.el6.-system_arch-.rpm > sssd-client-1.9.2-129.el6.-system_arch-.rpm > sssd-1.9.2-129.el6_5.4.-system_arch-.rpm > sudo-1.8.6p3-12.el6.-system_arch- > > I haven't installed the freeIPA client but I have run sssd successfully > for a 389-ds server and the above combination worked all right, specially > the sudo bit which was a bit of a hell. > To get to that point I spent a number of fun days thanks to the > limitations provided by amazon on their packages. > > Do not forget to install the epel and try to look for either "ipa" or > "ipa-server" as I doubt that will be called freeipa at all.(I haven't > tested that though.) > > Gonzalo > > > On 27/03/2015 01:03, Yogesh Sharma wrote: > > Gonzalo, > > We have some running servers on Amazon Linux and it would be difficult > to migrate all those to CentOS or RHEL as of now. Hence If you can provide > the package's version then it would really help us till the time we do > migration. > > For sure all over new Servers are going to be CentOS or RHEL. > > > > > * Best Regards, __________________________________________ * > > *Yogesh Sharma * > *Email: yks0000 at gmail.com | Web: www.initd.in > * > > RHCE, VCE-CIA, RackSpace Cloud U > [image: My LinkedIn Profile] > > > On Fri, Mar 27, 2015 at 1:03 PM, Gonzalo Fernandez Ordas < > g.fer.ordas at unicyber.co.uk> wrote: > >> Yogesh >> >> My personal experience using AWS Linux and LDAP is not a good one and >> mostly an utter nightmare in relation to packages. >> Personally I would recommend you to keep away from AWS Linux and get a >> Centos, Fedora or Redhat. >> Still, if you want to go ahead, I can give you the right versions for a >> couple of packages as the default sudo given by Amazon simply DOES NOT work >> (no idea what they have done to it..) >> >> Thanks >> >> On 27/03/2015 00:03, Yogesh Sharma wrote: >> >> Hello, >> >> Is there any repo available for Amazon Linux to install IPA Client OR >> below is the only way to do as found from freeipa-user mail archive. >> >> http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html >> >> >> Thanks for the help. >> >> >> >> * Best Regards, __________________________________________ * >> >> *Yogesh Sharma * >> >> >> >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokulnathb at gmail.com Sun Mar 29 17:44:43 2015 From: gokulnathb at gmail.com (Gokulnath) Date: Sun, 29 Mar 2015 12:44:43 -0500 Subject: [Freeipa-users] IPA Client Install on Amazon Linux In-Reply-To: References: <551507AE.3070009@unicyber.co.uk> <5516EAAD.1030701@unicyber.co.uk> Message-ID: <9153EF11-75C1-4D59-9A4F-C42E03E283C2@gmail.com> Quick question, if you have used Deion for ldap and Sudo, are all connections through Kerberos ? And all client and registered hosts will be in the same domain ? Gokul Sent from iPhone > On Mar 29, 2015, at 12:14 PM, Yogesh Sharma wrote: > > Thanks Gonzalo. Appreciate your help here, Let me try this. > > > Best Regards, > __________________________________________ > Yogesh Sharma > Email: yks0000 at gmail.com | Web: www.initd.in > > RHCE, VCE-CIA, RackSpace Cloud U > > > >> On Sat, Mar 28, 2015 at 11:23 PM, Gonzalo Fernandez Ordas wrote: >> Yogesh >> >> you do not need to explain me anything. Most people around here are on the same boat and working on this stuff already for quite awhile. >> >> I forgot to mention this is for a PROPER sssd run, still you will need all those below as you will get some issues sorted (specially sudo related) >> >> So...you need the following If I remember well..: >> >> system-arch --> system Architecture >> >> libipa_hbac-1.9.2-129.el6.-system_arch-.rpm >> sssd-client-1.9.2-129.el6.-system_arch-.rpm >> sssd-1.9.2-129.el6_5.4.-system_arch-.rpm >> sudo-1.8.6p3-12.el6.-system_arch- >> >> I haven't installed the freeIPA client but I have run sssd successfully for a 389-ds server and the above combination worked all right, specially the sudo bit which was a bit of a hell. >> To get to that point I spent a number of fun days thanks to the limitations provided by amazon on their packages. >> >> Do not forget to install the epel and try to look for either "ipa" or "ipa-server" as I doubt that will be called freeipa at all.(I haven't tested that though.) >> >> Gonzalo >> >> >>> On 27/03/2015 01:03, Yogesh Sharma wrote: >>> Gonzalo, >>> >>> We have some running servers on Amazon Linux and it would be difficult to migrate all those to CentOS or RHEL as of now. Hence If you can provide the package's version then it would really help us till the time we do migration. >>> >>> For sure all over new Servers are going to be CentOS or RHEL. >>> >>> >>> Best Regards, >>> __________________________________________ >>> Yogesh Sharma >>> Email: yks0000 at gmail.com | Web: www.initd.in >>> >>> RHCE, VCE-CIA, RackSpace Cloud U >>> >>> >>> >>>> On Fri, Mar 27, 2015 at 1:03 PM, Gonzalo Fernandez Ordas wrote: >>>> Yogesh >>>> >>>> My personal experience using AWS Linux and LDAP is not a good one and mostly an utter nightmare in relation to packages. >>>> Personally I would recommend you to keep away from AWS Linux and get a Centos, Fedora or Redhat. >>>> Still, if you want to go ahead, I can give you the right versions for a couple of packages as the default sudo given by Amazon simply DOES NOT work (no idea what they have done to it..) >>>> >>>> Thanks >>>> >>>>> On 27/03/2015 00:03, Yogesh Sharma wrote: >>>>> Hello, >>>>> >>>>> Is there any repo available for Amazon Linux to install IPA Client OR below is the only way to do as found from freeipa-user mail archive. >>>>> >>>>> http://www.redhat.com/archives/freeipa-users/2013-October/msg00058.html >>>>> >>>>> >>>>> Thanks for the help. >>>>> >>>>> Best Regards, >>>>> __________________________________________ >>>>> Yogesh Sharma > > -- > 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 gjn at gjn.priv.at Sun Mar 29 22:00:02 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 30 Mar 2015 00:00:02 +0200 Subject: [Freeipa-users] ipa-cliebt-automount problem Message-ID: <8655203.PnWfBp0T1z@techz> Hello, My automount is not working correct? I have a centos 7 with "cr" Update, this is IPA 4.1 and sssd 1.12 I have this Error in the logs automount[1899]: lookup_read_map: lookup(sss): getautomntent_r: No such file or directory Is this correct with IPA 4.1 /etc/sysconfig/autofs and /etc/autofs_ldap_auth.config was not configured with ipa-client-automount, or have I to do this manual? -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From joseluismantilla at gmail.com Sat Mar 28 15:19:11 2015 From: joseluismantilla at gmail.com (Jose Luis Mantilla) Date: Sat, 28 Mar 2015 10:19:11 -0500 Subject: [Freeipa-users] Steps for automount Message-ID: Can someone help me please? I would like that anyone write the steps only with 2 machines (server ipa with nfs, and ipa client), I executed the guide but isn't make it, I think that need some steps!!. There are 2 machines, server2.example.com (with ipa server and NFS) and desktop2.example.com (only with ipa-client) My steps: Server After install ipa-server. 1) Add service with web UI 2) Add automount location with Location=test key=/jmantilla description=-ro,soft,server2.example.com: /home/remoteusers/jmantilla User=jmantilla Home directory=/home/remoteusers/jmantilla Configuring automount on server system --Auto.master /home/remoteusers /etc/auto.ipa --auto.ipa jmantilla -rw server2.example.com:/home/remoteusers/jmantilla After #kinit admin I don't need to run: #ipa-getkeytab -s server2.example.com -p nfs/server2.example.com -k /etc/krb5.keytab #ipa-getkeytab -s server2.example.com -p nfs/server2.example.com -k /root/nfs-client.keytab #( echo rkt /root/nfs-client.keytab; echo wkt /etc/krb5.keytab) |ktutil My server and client and in an IPA domain, the keytabs should only be generated to /etc/krb5.keytab on the IPA server. (Ipa domain) Verifying [root at server2 ~]# ipa service-show nfs/server2.example.com Principal: nfs/server2.example.com at EXAMPLE.COM Keytab: True Managed by: server2.example.com Client #kinit admin #ipa-client-automount --location=test #ipa-getkeytab -s server2.example.com -p nfs/server2.example.com -k /etc/krb5.keytab #ipa-getkeytab -s server2.example.com -p nfs/server2.example.com -k /tmp/nfs.keytab #( echo rkt /tmp/nfs.keytab; echo wkt /etc/krb5.keytab) |ktutil #service rpcgssd start #/etc/init.d/rpcbind restart #/etc/init.d/rpcidmapd restart #authconfig --update --enablesssd --enablesssdauth --enablemkhomedir #/etc/init.d/sshd restart #vim /etc/sssd/sssd.conf ... [domain/EXAMPLE.COM] ... krb5_renewable_lifetime = 50d krb5_renew_interavl = 3600 #/etc/init.d/sssd restart Testing [root at server2 ~]# ssh cboyle at desktop2 cboyle at desktop2's password: Last login: Tue Mar 17 21:13:49 2015 from server2.example.com -sh-4.1$ And nothing!! (what happened) What I need to do it? Thanks [image: Verificacion de certificado] Click to verify *Ing. Jos? Luis Mantilla G.*Red Hat Certified Instructor / Examiner RHEL *6, 7*RHCE - RHCV - RHCI - RHCX - RHCSA Developer PHP, Member TeamQA Centos Cell phone: (1) 832-908-6210 Public GPG Key = FC3B3963 United States - Houston Texas -2015 -------------- next part -------------- An HTML attachment was scrubbed... URL: From joseluismantilla at gmail.com Sat Mar 28 16:22:41 2015 From: joseluismantilla at gmail.com (Jose Luis Mantilla) Date: Sat, 28 Mar 2015 11:22:41 -0500 Subject: [Freeipa-users] Steps for automount In-Reply-To: References: Message-ID: Adding below mail: [root at server2 home]# ssh jmantilla at desktop2 jmantilla at desktop2's password: Creating home directory for jmantilla. Last login: Sat Mar 28 11:05:48 2015 from server2.example.com Could not chdir to home directory /home/remoteusers/jmantilla: No such file or directory -sh-4.1$ pwd / [root at server2 home]# getent passwd jmantilla jmantilla:*:6001:6001:Jose Mantilla:/home/remoteusers/jmantilla:/bin/sh Service nfs is running Service autofs is stopped What can I do? [image: Verificacion de certificado] Click to verify *Ing. Jos? Luis Mantilla G.*Red Hat Certified Instructor / Examiner RHEL *6, 7*RHCE - RHCV - RHCI - RHCX - RHCSA Developer PHP, Member TeamQA Centos Cell phone: (1) 832-908-6210 Public GPG Key = FC3B3963 United States - Houston Texas -2015 On Sat, Mar 28, 2015 at 10:19 AM, Jose Luis Mantilla < joseluismantilla at gmail.com> wrote: > Can someone help me please? > > I would like that anyone write the steps only with 2 machines (server ipa > with nfs, and ipa client), I executed the guide but isn't make it, I think > that need some steps!!. > > There are 2 machines, server2.example.com (with ipa server and NFS) and > desktop2.example.com (only with ipa-client) > > My steps: > Server > After install ipa-server. > 1) Add service with web UI > 2) Add automount location with > Location=test > key=/jmantilla description=-ro,soft,server2.example.com: > /home/remoteusers/jmantilla > > User=jmantilla > Home directory=/home/remoteusers/jmantilla > > Configuring automount on server system > --Auto.master > /home/remoteusers /etc/auto.ipa > --auto.ipa > jmantilla -rw server2.example.com:/home/remoteusers/jmantilla > > After > #kinit admin > I don't need to run: > #ipa-getkeytab -s server2.example.com -p nfs/server2.example.com -k > /etc/krb5.keytab > #ipa-getkeytab -s server2.example.com -p nfs/server2.example.com -k > /root/nfs-client.keytab > #( echo rkt /root/nfs-client.keytab; echo wkt /etc/krb5.keytab) |ktutil > My server and client and in an IPA domain, the keytabs should only be > generated to /etc/krb5.keytab on the IPA server. (Ipa domain) > > Verifying > [root at server2 ~]# ipa service-show nfs/server2.example.com > Principal: nfs/server2.example.com at EXAMPLE.COM > Keytab: True > Managed by: server2.example.com > > Client > #kinit admin > #ipa-client-automount --location=test > #ipa-getkeytab -s server2.example.com -p nfs/server2.example.com -k > /etc/krb5.keytab > #ipa-getkeytab -s server2.example.com -p nfs/server2.example.com -k > /tmp/nfs.keytab > #( echo rkt /tmp/nfs.keytab; echo wkt /etc/krb5.keytab) |ktutil > #service rpcgssd start > #/etc/init.d/rpcbind restart > #/etc/init.d/rpcidmapd restart > #authconfig --update --enablesssd --enablesssdauth --enablemkhomedir > #/etc/init.d/sshd restart > #vim /etc/sssd/sssd.conf > ... > [domain/EXAMPLE.COM] > ... > krb5_renewable_lifetime = 50d > krb5_renew_interavl = 3600 > > #/etc/init.d/sssd restart > > Testing > [root at server2 ~]# ssh cboyle at desktop2 > cboyle at desktop2's password: > Last login: Tue Mar 17 21:13:49 2015 from server2.example.com > -sh-4.1$ > > And nothing!! (what happened) > What I need to do it? > > Thanks > > > [image: Verificacion de certificado] > > Click to verify > > > *Ing. Jos? Luis Mantilla G.*Red Hat Certified Instructor / Examiner RHEL > *6, 7*RHCE - RHCV - RHCI - RHCX - RHCSA > Developer PHP, Member TeamQA Centos > Cell phone: (1) 832-908-6210 > Public GPG Key = FC3B3963 > > United States - Houston Texas -2015 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andy.Thompson at e-tcc.com Sun Mar 29 22:51:03 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Sun, 29 Mar 2015 22:51:03 +0000 Subject: [Freeipa-users] passwordStorageScheme In-Reply-To: <5517B951.2060007@redhat.com> References: <551579B2.3070605@redhat.com> , <5515961E.5020408@redhat.com> <20b1982dbd804ac6aac0ec95eb047918@TCCCORPEXCH02.TCC.local> <55159A9F.6090204@redhat.com> <5517B951.2060007@redhat.com> Message-ID: <80e52d6370014388b0c836b504ebb88e@TCCCORPEXCH02.TCC.local> > -----Original Message----- > From: Sankar Ramlingam [mailto:sramling at redhat.com] > Sent: Sunday, March 29, 2015 4:35 AM > To: Andy Thompson > Cc: freeipa-users at redhat.com > Subject: Re: [Freeipa-users] passwordStorageScheme > > On 03/28/2015 12:32 AM, Andy Thompson wrote: > > > >> -----Original Message----- > >> From: Sankar Ramlingam [mailto:sramling at redhat.com] > >> Sent: Friday, March 27, 2015 2:00 PM > >> To: Andy Thompson > >> Subject: Re: [Freeipa-users] passwordStorageScheme > >> > >> On 03/27/2015 11:17 PM, Andy Thompson wrote: > >>>> Can you show me the output for this command? > >>>> ldapsearch -LLL -x -p $PORT -h localhost -D "cn=Directory Manager" > >>>> -w xxxxx -b "cn=config" |grep -i passwordStorageScheme > >>> Returns > >>> > >>> passwordStorageScheme: SSHA > >>> > >>> > >>>> Also, can you paste me the content of pw.ldif file? and tell me > >>>> what > >>> dn: cn=config > >>> changetype: modify > >>> replace: passwordStorageScheme > >>> passwordStorageScheme: SHA512 > >> It looks like some whitespace characters in your ldif file. Can you > >> recreate the ldif file with no special/whitespace characters? or can > >> you run ldapmodify from command line and change the value directly? . > >> > >> I copied your ldif file content and it failed for me too. Then, I > >> tried copying my ldif file and it was a success. Pasting the content here... > >> > >> dn: cn=config > >> changetype: modify > >> replace: passwordStorageScheme > >> passwordStorageScheme: SHA512 > >> EOF > >> > > Thanks much for the assist. Haven't ever run into that before. > Hi Andy, > > So, I understand it was a problem with the LDIF file. I hope the problem is > solved now. > Please confirm. > Yes the problem is solved. Was just some extra spaces or something not visible to the eye that snuck in when I copied and pasted it from a document I've been compiling on all of my setup and testing. Thanks again -andy From dpal at redhat.com Mon Mar 30 01:38:01 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 29 Mar 2015 21:38:01 -0400 Subject: [Freeipa-users] anonymous binds limits? In-Reply-To: <5515F437.4030506@gmail.com> References: <5515F437.4030506@gmail.com> Message-ID: <5518A8F9.6010507@redhat.com> On 03/27/2015 08:22 PM, Janelle wrote: > Hello, > > Just wondering if there is an easy way to increase anonymous binds on > the back end for non Kerberos clients? > I have seen some mention of it, and that IPA has limits, can't can't > find a lot of detail? > > Thank you > ~J > I am not sure I understand what you are asking. What do you mean by "increase anonymous binds" ? Increase timeout? Or you want to allow anonymous binds? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Mar 30 01:41:40 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 29 Mar 2015 21:41:40 -0400 Subject: [Freeipa-users] ipa-cliebt-automount problem In-Reply-To: <8655203.PnWfBp0T1z@techz> References: <8655203.PnWfBp0T1z@techz> Message-ID: <5518A9D4.3080802@redhat.com> On 03/29/2015 06:00 PM, G?nther J. Niederwimmer wrote: > Hello, > > My automount is not working correct? > > I have a centos 7 with "cr" Update, this is IPA 4.1 and sssd 1.12 > > I have this Error in the logs > > automount[1899]: lookup_read_map: lookup(sss): getautomntent_r: No such file or > directory > > Is this correct with IPA 4.1 > > /etc/sysconfig/autofs and /etc/autofs_ldap_auth.config was not configured with > ipa-client-automount, or have I to do this manual? Do you have libsss_autofs installed? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Mar 30 01:44:03 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 29 Mar 2015 21:44:03 -0400 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS In-Reply-To: References: Message-ID: <5518AA63.5070403@redhat.com> On 03/29/2015 11:50 AM, Gokul wrote: > Hi, > > I am tried to run some of my user cases with FreeIPA. > > Have FreeIPA to do only SSH key management in LDAP and PKI management. > > The understand that every request is kerberized and it has the DNS is > must configuration. > > Can I have FreeIPA to run only SSH Key management with LDAP and a PKI > server with dogtag? > > Thank you > Gokul > > You can't turn off Kerberos. You would need Kerberos for administration. But other clients can take advantage of LDAP and SSH only. However you are significantly limiting your functionality and capabilities. Kerberos is really the key of the solution. What is the reason you try to avoid using it? -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Mon Mar 30 01:45:05 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 29 Mar 2015 21:45:05 -0400 Subject: [Freeipa-users] Freeipa Server down !! In-Reply-To: <5517D562.3050103@obfusc8.org> References: <3126552.348nSDbtq8@techz> <5516F71A.2090201@redhat.com> <5517D562.3050103@obfusc8.org> Message-ID: <5518AAA1.2070601@redhat.com> On 03/29/2015 06:35 AM, Peter Fern wrote: > On 29/03/15 05:46, Rob Crittenden wrote: >> Should be back up now. >> >> rob > > Appears to be dead again. > It is in fact down again. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Mar 30 01:48:29 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 29 Mar 2015 21:48:29 -0400 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: References: Message-ID: <5518AB6D.1020606@redhat.com> On 03/29/2015 04:47 AM, Matt . wrote: > Hi Guys, > > Now my Certification issues are solved for using a loadbalancer in > front of my ipa servers I get the following: > > Unable to verify your Kerberos credentials > > and in my logs: > > Additional pre-authentication required. > > This happens when I connect throught my loadbalancers, I see my server > coming ni with the right IP. > > When I access my ipa server directly, not using the loadbalancer IP > between it, my kerberos Ticket is valid. > > I get the feeling that when I use my loadbalancers and because of that > I get a 301 redirect it needs a preauth. I see some issues on > mailinglists but it doesn't fit my situation. > > Why wants it the preauth when I already have a valid ticket and my > redirect is followed by CURL and posted the right way ? Can you describe the sequence? What do you do? From the client you try IPA CLI and this is where you see the problem even with the valid ticket or is the flow different? > I hope someone has an idea. > > Thanks, > > Matt > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Mar 30 01:55:20 2015 From: dpal at redhat.com (Dmitri Pal) Date: Sun, 29 Mar 2015 21:55:20 -0400 Subject: [Freeipa-users] Steps for automount In-Reply-To: References: Message-ID: <5518AD08.7050509@redhat.com> On 03/28/2015 12:22 PM, Jose Luis Mantilla wrote: > Adding below mail: > > [root at server2 home]# ssh jmantilla at desktop2 > jmantilla at desktop2's password: > Creating home directory for jmantilla. > Last login: Sat Mar 28 11:05:48 2015 from server2.example.com > > Could not chdir to home directory /home/remoteusers/jmantilla: No such > file or directory > -sh-4.1$ pwd > / > > [root at server2 home]# getent passwd jmantilla > jmantilla:*:6001:6001:Jose Mantilla:/home/remoteusers/jmantilla:/bin/sh > > Service nfs is running > Service autofs is stopped > > What can I do? Why are you trying to do it manually? Steps: Install the server. Configure your NFS server. Do you plan to use Kerberos authentication for automount? If so then you need to issue keytab for the NFS principal for NFS server. NFS principal/keytab is not not needed on the client, client uses host keytab. So on the client install the client using ipa-client-install, then you can configure automount on it. Freeipa.org is down at the moment but when it is back i nthe morning please check HOWTOs there, I recall there wore instructions about NFS. > **Verificacion de certificado > > Click to verify > > > > ** > > *Ing. Jos? Luis Mantilla G. > *Red Hat Certified Instructor / Examiner RHEL***6, 7 > *RHCE - RHCV - RHCI - RHCX - RHCSA* > *Developer PHP, Member TeamQA Centos* > *Cell phone: (1) 832-908-6210 > Public GPG Key = FC3B3963 > > > United States - Houston Texas -2015 > > > On Sat, Mar 28, 2015 at 10:19 AM, Jose Luis Mantilla > > wrote: > > Can someone help me please? > > I would like that anyone write the steps only with 2 machines > (server ipa with nfs, and ipa client), I executed the guide but > isn't make it, I think that need some steps!!. > > There are 2 machines, server2.example.com > (with ipa server and NFS) and > desktop2.example.com (only with > ipa-client) > > My steps: > Server > After install ipa-server. > 1) Add service with web UI > 2) Add automount location with > Location=test > key=/jmantilla > description=-ro,soft,server2.example.com:/home/remoteusers/jmantilla > > User=jmantilla > Home directory=/home/remoteusers/jmantilla > > Configuring automount on server system > --Auto.master > /home/remoteusers /etc/auto.ipa > --auto.ipa > jmantilla -rw server2.example.com:/home/remoteusers/jmantilla > > After > #kinit admin > I don't need to run: > #ipa-getkeytab -s server2.example.com > -p nfs/server2.example.com -k > /etc/krb5.keytab > #ipa-getkeytab -s server2.example.com > -p nfs/server2.example.com -k > /root/nfs-client.keytab > #( echo rkt /root/nfs-client.keytab; echo wkt /etc/krb5.keytab) > |ktutil > My server and client and in an IPA domain, the keytabs should only > be generated to /etc/krb5.keytab on the IPA server. (Ipa domain) > > Verifying > [root at server2 ~]# ipa service-show nfs/server2.example.com > > Principal: nfs/server2.example.com at EXAMPLE.COM > > Keytab: True > Managed by: server2.example.com > > Client > #kinit admin > #ipa-client-automount --location=test > #ipa-getkeytab -s server2.example.com > -p nfs/server2.example.com -k > /etc/krb5.keytab > #ipa-getkeytab -s server2.example.com > -p nfs/server2.example.com -k > /tmp/nfs.keytab > #( echo rkt /tmp/nfs.keytab; echo wkt /etc/krb5.keytab) |ktutil > #service rpcgssd start > #/etc/init.d/rpcbind restart > #/etc/init.d/rpcidmapd restart > #authconfig --update --enablesssd --enablesssdauth --enablemkhomedir > #/etc/init.d/sshd restart > #vim /etc/sssd/sssd.conf > ... > [domain/EXAMPLE.COM ] > ... > krb5_renewable_lifetime = 50d > krb5_renew_interavl = 3600 > > #/etc/init.d/sssd restart > > Testing > [root at server2 ~]# ssh cboyle at desktop2 > cboyle at desktop2's password: > Last login: Tue Mar 17 21:13:49 2015 from server2.example.com > > -sh-4.1$ > > And nothing!! (what happened) > What I need to do it? > > Thanks > > **Verificacion de certificado > > Click to verify > > > > ** > > *Ing. Jos? Luis Mantilla G. > *Red Hat Certified Instructor / Examiner RHEL***6, 7 > *RHCE - RHCV - RHCI - RHCX - RHCSA* > *Developer PHP, Member TeamQA Centos* > *Cell phone: (1) 832-908-6210 > Public GPG Key = FC3B3963 > > > United States - Houston Texas -2015 > > > > -- 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 Mar 30 02:23:32 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 29 Mar 2015 22:23:32 -0400 Subject: [Freeipa-users] Freeipa Server down !! In-Reply-To: <5518AAA1.2070601@redhat.com> References: <3126552.348nSDbtq8@techz> <5516F71A.2090201@redhat.com> <5517D562.3050103@obfusc8.org> <5518AAA1.2070601@redhat.com> Message-ID: <5518B3A4.1070705@redhat.com> Dmitri Pal wrote: > On 03/29/2015 06:35 AM, Peter Fern wrote: >> On 29/03/15 05:46, Rob Crittenden wrote: >>> Should be back up now. >>> >>> rob >> >> Appears to be dead again. >> > It is in fact down again. > The quote is exceeded in the openshift gear. I cleaned up a log file which should buy a bit of time. rob From rcritten at redhat.com Mon Mar 30 02:25:07 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Sun, 29 Mar 2015 22:25:07 -0400 Subject: [Freeipa-users] ipa-cliebt-automount problem In-Reply-To: <5518A9D4.3080802@redhat.com> References: <8655203.PnWfBp0T1z@techz> <5518A9D4.3080802@redhat.com> Message-ID: <5518B403.9040907@redhat.com> Dmitri Pal wrote: > On 03/29/2015 06:00 PM, G?nther J. Niederwimmer wrote: >> Hello, >> >> My automount is not working correct? >> >> I have a centos 7 with "cr" Update, this is IPA 4.1 and sssd 1.12 >> >> I have this Error in the logs >> >> automount[1899]: lookup_read_map: lookup(sss): getautomntent_r: No >> such file or >> directory >> >> Is this correct with IPA 4.1 >> >> /etc/sysconfig/autofs and /etc/autofs_ldap_auth.config was not >> configured with >> ipa-client-automount, or have I to do this manual? > Do you have libsss_autofs installed? The default is to configure automount using SSSD so no configuration in those files is expected. What isn't working? rob From gokulnathb at gmail.com Mon Mar 30 02:27:39 2015 From: gokulnathb at gmail.com (Gokulnath) Date: Sun, 29 Mar 2015 21:27:39 -0500 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS In-Reply-To: <5518AA63.5070403@redhat.com> References: <5518AA63.5070403@redhat.com> Message-ID: Thanks for getting back. 1. As security Kerberos can ticket and in memory can be taken and that session key Can be used to gain access every where. Primarily this because the plan is to use the solution in cloud. 2. Can I disable DNS as well? And have IPA to run only ldap, ssh key rotation and pki ? 3. As during the install, DNS and Kerberos are getting installed and configured. I would really appreciate if you can get back. Thank you Gokul Sent from iPhone > On Mar 29, 2015, at 8:44 PM, Dmitri Pal wrote: > >> On 03/29/2015 11:50 AM, Gokul wrote: >> Hi, >> >> I am tried to run some of my user cases with FreeIPA. >> >> Have FreeIPA to do only SSH key management in LDAP and PKI management. >> >> The understand that every request is kerberized and it has the DNS is must configuration. >> >> Can I have FreeIPA to run only SSH Key management with LDAP and a PKI server with dogtag? >> >> Thank you >> Gokul > You can't turn off Kerberos. You would need Kerberos for administration. > But other clients can take advantage of LDAP and SSH only. > However you are significantly limiting your functionality and capabilities. > Kerberos is really the key of the solution. > > What is the reason you try to avoid using it? > > > -- > 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 yamakasi.014 at gmail.com Mon Mar 30 02:56:11 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Mon, 30 Mar 2015 04:56:11 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: <5518AB6D.1020606@redhat.com> References: <5518AB6D.1020606@redhat.com> Message-ID: Hi, I just tot home and typing from my cell so i'm suite short in words Create keytab for ldap-01.domain Kinit with that to ldap.domain Curl against ldap.domain Get a 301 which I manage from curl (goes well) Get kerberos ticket error now I don't kinit anymore so re-use my existing ticket and curl against ldap-01.domain and I'm accepted and can execute stuff. My ssl is OK, ticket also it seems. Thanks M. Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : > On 03/29/2015 04:47 AM, Matt . wrote: > >> Hi Guys, >> >> Now my Certification issues are solved for using a loadbalancer in >> front of my ipa servers I get the following: >> >> Unable to verify your Kerberos credentials >> >> and in my logs: >> >> Additional pre-authentication required. >> >> This happens when I connect throught my loadbalancers, I see my server >> coming ni with the right IP. >> >> When I access my ipa server directly, not using the loadbalancer IP >> between it, my kerberos Ticket is valid. >> >> I get the feeling that when I use my loadbalancers and because of that >> I get a 301 redirect it needs a preauth. I see some issues on >> mailinglists but it doesn't fit my situation. >> >> Why wants it the preauth when I already have a valid ticket and my >> redirect is followed by CURL and posted the right way ? >> > > Can you describe the sequence? > What do you do? > > From the client you try IPA CLI and this is where you see the problem even > with the valid ticket or is the flow different? > > I hope someone has an idea. >> >> Thanks, >> >> Matt >> >> > > -- > 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 ftweedal at redhat.com Mon Mar 30 03:25:00 2015 From: ftweedal at redhat.com (Fraser Tweedale) Date: Mon, 30 Mar 2015 13:25:00 +1000 Subject: [Freeipa-users] using dogtag outside of freeIPA? In-Reply-To: References: Message-ID: <20150330032500.GD5632@dhcp-40-8.bne.redhat.com> On Fri, Mar 27, 2015 at 03:52:12PM -0500, Steve Neuharth wrote: > Hello, > > Is it possible or perhaps not recommended to use the dogtag API and/or UI > on a FreeIPA system without using the freeIPA CLI or UI? I have a > requirement to submit a certificate to a service without kerberos and > without client software installed using a RESTful API. Dogtag API is very > well documented and I do not want to associate all my certificates with a > Kerberos principal because it adds complexity to the cert signing process. > I just need to sign a cert without the FreeIPA overhead. > > I tried to get to the Dogtag web UI through the url > http://ipa.example.com/ca/ee/ca but I get an unauthenticated web page (no > password prompt) and broken image links. This tells me that perhaps the > Dogtag UI in a FreeIPA installation is not meant to be used without > FreeIPA. Is that correct? > The page being unauthenticated is normal - anyone can submit a certificate request; it is then enqueued for a CA admin or agent to review and approve/reject. Alternatively, you can configure a certificate profile to authenticate against the IPA directory for automatic approval (but the overall interface will still be unauthenticated). The certificate and key for admin access to Dogtag (so you can approve certificate requests) are found in /root/ca-agent.p12 on the FreeIPA server. > I know this is a weird use case and not necessarily a FreeIPA problem but > if someone could advise, I'd greatly appreciate it. > --steve > -- > 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 g.fer.ordas at unicyber.co.uk Mon Mar 30 04:36:00 2015 From: g.fer.ordas at unicyber.co.uk (g.fer.ordas at unicyber.co.uk) Date: Mon, 30 Mar 2015 05:36:00 +0100 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <901732470.4546498.1427358670169.JavaMail.zimbra@redhat.com> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> <55137570.2070606@redhat.com> <5513974F.2080608@unicyber.co.uk> <901732470.4546498.1427358670169.JavaMail.zimbra@redhat.com> Message-ID: <7c60faba985b3343bd87c1ef16ad9814@unicyber.co.uk> Hey Guys Not sure if I am missing any bit.... but this was the thing in the end: http://generations.menteyarte.org/archives/195-freeipa-server-and-SSSD-on-Ubuntu.html I managed to have it working and I have documented all those nasty bits which might save people's time. The whole weekend gone but for the less has been productive. I am including the SUDO bit which is usually a pain in my experience.. Thanks On 2015-03-26 08:31, Jakub Hrozek wrote: > If you have SSSD 1.9.6 or newer all the sudo configuration boils down > to including 'sss' for 'sudoers' in nsswitch.conf and > sudo_provider=ipa in sssd.conf. > > You also need a reasonably recent sudo itself. Posting versions of > SSSD and sudo would help. > > ----- Original Message ----- > From: "Gonzalo Fernandez Ordas" > To: "Rob Crittenden" , dpal at redhat.com > Cc: freeipa-users at redhat.com > Sent: Thursday, 26 March, 2015 6:21:19 AM > Subject: Re: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed > from AD > > I have to test a few options to see how I can overcome that issue. > A pity as I nearly got everything setup in full. > Any findings I will get back to the list as this might be relevant for > other users. > > > On 25/03/2015 19:56, Rob Crittenden wrote: >> Gonzalo Fernandez Ordas wrote: >>> Exactly the document i was having a look at. >>> In simple words,is possible to work this around and how,? >>> Otherwise i have to drop freeipa and get back to 389_ds as still >>> seems >>> fully ldap sssd compatible. >>> >>> Have you got any doc clearly stating how to get this done? >>> I really invested many days on reaching this far being sudo the last >>> tiny bit to get sorted which is hugely frustrated. >> How to configure sudo largely depends on the version of SSSD you have >> in >> Ubuntu. I'm not sure how configuring SSSD is going to affect your >> choice >> of server though. If you still use SSSD the same problem will exist >> regardless, right? >> >> rob >> >>> Thanks for all the support >>> Sent from Type Mail >>> >>> On Mar 25, 2015, at 5:35 PM, Dmitri Pal >> > wrote: >>> >>> On 03/25/2015 08:32 PM, g.fer.ordas at unicyber.co.uk wrote: >>> >>> Hi >>> >>> I am setting up a plain and simple sssd service against my >>> FreeIPA >>> Server. >>> The FreeIPA Server is a Centos 7.1 box with IPA version 4.1 >>> and the >>> client box is ubuntu: Ubuntu 12.04.5 LTS >>> >>> The Users and Credentials are being Synched out of an AD >>> Server >>> (the >>> passwords happened to be transferred using the PassSync >>> Service) >>> >>> Now.. I wanted to setup a very simple sssd service (not the >>> FreeIPA >>> client service) >>> And so far I succeeded on synching the users along with the >>> passwords >>> using SSSD. >>> >>> Now, Trying to get the sudo access sorted I cannot see that >>> working, >>> and I came across some documentation mentioning SSSD is NOT >>> currently >>> supporting IPA schema for the SUDOers >>> if that is the case >>> >>> Can anybody point me to the right document or procedure in >>> terms of >>> getting also the sudoers installed? >>> >>> Would be possible , somehow, to have this sorted WITHOUT >>> using the >>> ipa-client? >>> >>> many thanks! >>> >>> >>> >>> >>> http://www.freeipa.org/images/7/77/Freeipa30_SSSD_SUDO_Integration.pdf >>> >>> >>> >> From andrew.holway at gmail.com Mon Mar 30 07:28:12 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Mon, 30 Mar 2015 09:28:12 +0200 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS In-Reply-To: References: <5518AA63.5070403@redhat.com> Message-ID: Hi, As far as I understand it Kerberos service tickets are granted for a user to access a particular principle (host/service at REALM) and cannot be reused. Kerberos uses symmetric key cryptography so, if someone were able to access the memory of the machine, then they may indeed be able to snoop your user password although I am quite sure passwords are kept hashed in the Keytab. If you are so worried that someone would go to the trouble hack the virtualisation layer and copy chunks of memory then you should really be reconsidering your use of cloud services. People hacking kerberos will be the least of your problems if you have data that is that sensitive on there. If you could point me to some documentation on the specific attack you are trying to mitigate that would be nice. Thanks, Andrew On 30 March 2015 at 04:27, Gokulnath wrote: > Thanks for getting back. > > 1. As security Kerberos can ticket and in memory can be taken and that > session key > Can be used to gain access every where. Primarily this because the plan is > to use the solution in cloud. > > 2. Can I disable DNS as well? And have IPA to run only ldap, ssh key > rotation and pki ? > > 3. As during the install, DNS and Kerberos are getting installed and > configured. > > I would really appreciate if you can get back. > > Thank you > Gokul > Sent from iPhone > > > On Mar 29, 2015, at 8:44 PM, Dmitri Pal wrote: > > > >> On 03/29/2015 11:50 AM, Gokul wrote: > >> Hi, > >> > >> I am tried to run some of my user cases with FreeIPA. > >> > >> Have FreeIPA to do only SSH key management in LDAP and PKI management. > >> > >> The understand that every request is kerberized and it has the DNS is > must configuration. > >> > >> Can I have FreeIPA to run only SSH Key management with LDAP and a PKI > server with dogtag? > >> > >> Thank you > >> Gokul > > You can't turn off Kerberos. You would need Kerberos for administration. > > But other clients can take advantage of LDAP and SSH only. > > However you are significantly limiting your functionality and > capabilities. > > Kerberos is really the key of the solution. > > > > What is the reason you try to avoid using it? > > > > > > -- > > 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 > > -- > 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 mbasti at redhat.com Mon Mar 30 07:32:27 2015 From: mbasti at redhat.com (Martin Basti) Date: Mon, 30 Mar 2015 09:32:27 +0200 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS In-Reply-To: References: <5518AA63.5070403@redhat.com> Message-ID: <5518FC0B.60104@redhat.com> On 30/03/15 04:27, Gokulnath wrote: > Thanks for getting back. > > 1. As security Kerberos can ticket and in memory can be taken and that session key > Can be used to gain access every where. Primarily this because the plan is to use the solution in cloud. > > 2. Can I disable DNS as well? And have IPA to run only ldap, ssh key rotation and pki ? IPA clients require properly configured DNS, if you plan to use only server IMO it should work. > > 3. As during the install, DNS and Kerberos are getting installed and configured. DNS is optional part of installation, by default DNS is not installed. > > I would really appreciate if you can get back. > > Thank you > Gokul > Sent from iPhone > >> On Mar 29, 2015, at 8:44 PM, Dmitri Pal wrote: >> >>> On 03/29/2015 11:50 AM, Gokul wrote: >>> Hi, >>> >>> I am tried to run some of my user cases with FreeIPA. >>> >>> Have FreeIPA to do only SSH key management in LDAP and PKI management. >>> >>> The understand that every request is kerberized and it has the DNS is must configuration. >>> >>> Can I have FreeIPA to run only SSH Key management with LDAP and a PKI server with dogtag? >>> >>> Thank you >>> Gokul >> You can't turn off Kerberos. You would need Kerberos for administration. >> But other clients can take advantage of LDAP and SSH only. >> However you are significantly limiting your functionality and capabilities. >> Kerberos is really the key of the solution. >> >> What is the reason you try to avoid using it? >> >> >> -- >> 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 -- Martin Basti From pspacek at redhat.com Mon Mar 30 07:33:13 2015 From: pspacek at redhat.com (Petr Spacek) Date: Mon, 30 Mar 2015 09:33:13 +0200 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS In-Reply-To: References: <5518AA63.5070403@redhat.com> Message-ID: <5518FC39.7040909@redhat.com> On 30.3.2015 09:28, Andrew Holway wrote: > Hi, > > As far as I understand it Kerberos service tickets are granted for a user > to access a particular principle (host/service at REALM) and cannot be reused. > Kerberos uses symmetric key cryptography so, if someone were able to access > the memory of the machine, then they may indeed be able to snoop your user > password although I am quite sure passwords are kept hashed in the Keytab. > > If you are so worried that someone would go to the trouble hack the > virtualisation layer and copy chunks of memory then you should really be > reconsidering your use of cloud services. People hacking kerberos will be > the least of your problems if you have data that is that sensitive on there. > > If you could point me to some documentation on the specific attack you are > trying to mitigate that would be nice. > > Thanks, > > Andrew > > > On 30 March 2015 at 04:27, Gokulnath wrote: > >> Thanks for getting back. >> >> 1. As security Kerberos can ticket and in memory can be taken and that >> session key >> Can be used to gain access every where. Primarily this because the plan is >> to use the solution in cloud. >> >> 2. Can I disable DNS as well? And have IPA to run only ldap, ssh key >> rotation and pki ? >> >> 3. As during the install, DNS and Kerberos are getting installed and >> configured. Let me add that DNS server is an optional component and will not be installed if you do not specify --setup-dns option. In that case you have to add necessary DNS records by hand to make FreeIPA fully functional. Petr^2 Spacek >> I would really appreciate if you can get back. >> >> Thank you >> Gokul >> Sent from iPhone >> >>> On Mar 29, 2015, at 8:44 PM, Dmitri Pal wrote: >>> >>>> On 03/29/2015 11:50 AM, Gokul wrote: >>>> Hi, >>>> >>>> I am tried to run some of my user cases with FreeIPA. >>>> >>>> Have FreeIPA to do only SSH key management in LDAP and PKI management. >>>> >>>> The understand that every request is kerberized and it has the DNS is >> must configuration. >>>> >>>> Can I have FreeIPA to run only SSH Key management with LDAP and a PKI >> server with dogtag? >>>> >>>> Thank you >>>> Gokul >>> You can't turn off Kerberos. You would need Kerberos for administration. >>> But other clients can take advantage of LDAP and SSH only. >>> However you are significantly limiting your functionality and >> capabilities. >>> Kerberos is really the key of the solution. >>> >>> What is the reason you try to avoid using it? From gjn at gjn.priv.at Mon Mar 30 07:59:14 2015 From: gjn at gjn.priv.at (=?ISO-8859-1?Q?G=FCnther_J=2E?= Niederwimmer) Date: Mon, 30 Mar 2015 09:59:14 +0200 Subject: [Freeipa-users] ipa-cliebt-automount problem In-Reply-To: <5518B403.9040907@redhat.com> References: <8655203.PnWfBp0T1z@techz> <5518A9D4.3080802@redhat.com> <5518B403.9040907@redhat.com> Message-ID: <13222105.0pSX6VMD25@techz> Hello, Am Sonntag, 29. M?rz 2015, 22:25:07 schrieb Rob Crittenden: > Dmitri Pal wrote: > > On 03/29/2015 06:00 PM, G?nther J. Niederwimmer wrote: > >> Hello, > >> > >> My automount is not working correct? > >> > >> I have a centos 7 with "cr" Update, this is IPA 4.1 and sssd 1.12 > >> > >> I have this Error in the logs > >> > >> automount[1899]: lookup_read_map: lookup(sss): getautomntent_r: No > >> such file or > >> directory > >> > >> Is this correct with IPA 4.1 > >> > >> /etc/sysconfig/autofs and /etc/autofs_ldap_auth.config was not > >> configured with > >> ipa-client-automount, or have I to do this manual? > > > > Do you have libsss_autofs installed? > > The default is to configure automount using SSSD so no configuration in > those files is expected. > > What isn't working? I mean this Error is not the best Thing ;) automount[1899]: lookup_read_map: lookup(sss): getautomntent_r: No such file or directory I found this in mount ? /etc/auto.misc on /misc type autofs (rw,relatime,fd=6,pgrp=7198,timeout=300,minproto=5,maxproto=5,indirect) -hosts on /net type autofs (rw,relatime,fd=12,pgrp=7198,timeout=300,minproto=5,maxproto=5,indirect) auto.daten on /daten type autofs (rw,relatime,fd=18,pgrp=7198,timeout=300,minproto=5,maxproto=5,indirect) auto.home on /home type autofs (rw,relatime,fd=24,pgrp=7198,timeout=300,minproto=5,maxproto=5,indirect) The first, now I found also the local auto.master in the mount? But the /net mount (nfs4) are not mounted ;) Have I to start any nfs Programms for working -- mit freundlichen Gr??en / best Regards, G?nther J. Niederwimmer From Alexander.Frolushkin at megafon.ru Mon Mar 30 08:09:43 2015 From: Alexander.Frolushkin at megafon.ru (Alexander Frolushkin) Date: Mon, 30 Mar 2015 08:09:43 +0000 Subject: [Freeipa-users] AD users and IPA's sudo Message-ID: <7a399ff0d1b84aae8ac1ff1b8026a9b2@sib-ums01.Megafon.ru> Hello everyone. We have a IPA 3 and AD domain trust. Users from AD successfully logs on to linux servers via ssh and hbac rules works fine with external groups. But not a sudo rules. When rule defines as 'who' IPA users rule works well. If it is defines external group for corresponding AD group which is AD user member of, this user gets user at ad.com is not allowed to run sudo on host.com. This incident will be reported. In debug there is a strings (Mon Mar 30 13:54:00 2015) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry (Mon Mar 30 13:54:00 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=user at ad.com)( sudoUser=#xxxxxxxxxx)(sudoUser=%....cuted.......(sudoUser=%....cuted.....)(sudoUser=+*))(&(dataExpireTimestamp<=1427702040)))] (Mon Mar 30 13:54:00 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0020): Error looking up SUDO rules(Mon Mar 30 13:54:00 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0020): Unable to retr ieve expired sudo rules [5]: Input/output error I've seen a number of closed bugs with similar error message, but at last on this RHEL 6.6 server sssd is fully updated. And sorry for the huge underlined message, it is generated automatically and I have no rights to avoid it in my mails :( With best regards, Alexander Frolushkin, Senior engineer in system administration and database management MegaFon, Siberian branch http://english.corp.megafon.ru/ Cell +79232508764 Phone +79232507764 ________________________________ ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. (c)20mf50 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Mar 30 08:16:47 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 30 Mar 2015 10:16:47 +0200 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <7c60faba985b3343bd87c1ef16ad9814@unicyber.co.uk> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> <55137570.2070606@redhat.com> <5513974F.2080608@unicyber.co.uk> <901732470.4546498.1427358670169.JavaMail.zimbra@redhat.com> <7c60faba985b3343bd87c1ef16ad9814@unicyber.co.uk> Message-ID: <20150330081647.GV10622@hendrix.redhat.com> On Mon, Mar 30, 2015 at 05:36:00AM +0100, g.fer.ordas at unicyber.co.uk wrote: > > Hey Guys > > Not sure if I am missing any bit.... but this was the thing in the end: > > > http://generations.menteyarte.org/archives/195-freeipa-server-and-SSSD-on-Ubuntu.html > > I managed to have it working and I have documented all those nasty bits > which might save people's time. The whole weekend gone but for the less has > been productive. > > I am including the SUDO bit which is usually a pain in my experience.. > > Thanks Thank you very much for documenting this, but wouldn't it be better to use id_provider=ipa instead? Then the configuration would be simpler, less error prone and would authenticate more securely. You don't need to run ipa-client-install on the box, you can generate the client keytab elsewhere and transfer it to the client. From jhrozek at redhat.com Mon Mar 30 08:21:06 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 30 Mar 2015 10:21:06 +0200 Subject: [Freeipa-users] AD users and IPA's sudo In-Reply-To: <7a399ff0d1b84aae8ac1ff1b8026a9b2@sib-ums01.Megafon.ru> References: <7a399ff0d1b84aae8ac1ff1b8026a9b2@sib-ums01.Megafon.ru> Message-ID: <20150330082106.GW10622@hendrix.redhat.com> On Mon, Mar 30, 2015 at 08:09:43AM +0000, Alexander Frolushkin wrote: > Hello everyone. > We have a IPA 3 and AD domain trust. > Users from AD successfully logs on to linux servers via ssh and hbac rules works fine with external groups. But not a sudo rules. > When rule defines as 'who' IPA users rule works well. If it is defines external group for corresponding AD group which is AD user member of, this user gets > user at ad.com is not allowed to run sudo on host.com. This incident will be reported. > > In debug there is a strings > (Mon Mar 30 13:54:00 2015) [sssd[sudo]] [sysdb_search_group_by_gid] (0x0400): No such entry > (Mon Mar 30 13:54:00 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0200): Searching sysdb with [(&(objectClass=sudoRule)(|(sudoUser=ALL)(name=defaults)(sudoUser=user at ad.com)( > sudoUser=#xxxxxxxxxx)(sudoUser=%....cuted.......(sudoUser=%....cuted.....)(sudoUser=+*))(&(dataExpireTimestamp<=1427702040)))] > (Mon Mar 30 13:54:00 2015) [sssd[sudo]] [sudosrv_get_sudorules_query_cache] (0x0020): Error looking up SUDO rules(Mon Mar 30 13:54:00 2015) [sssd[sudo]] [sudosrv_get_rules] (0x0020): Unable to retr > ieve expired sudo rules [5]: Input/output error Looks suspicious. Is there an corresponding LDAP search in the back end log as well? Look for sdap_get_generic perhaps.. > > I've seen a number of closed bugs with similar error message, but at last on this RHEL 6.6 server sssd is fully updated. > > And sorry for the huge underlined message, it is generated automatically and I have no rights to avoid it in my mails :( > > With best regards, > Alexander Frolushkin, > Senior engineer in system administration > and database management > MegaFon, Siberian branch > http://english.corp.megafon.ru/ > Cell +79232508764 > Phone +79232507764 > > > > ________________________________ > > ?????????? ? ???? ????????? ????????????? ????????????? ??? ?????????? ???, ??????? ??? ??????????. ? ????????? ????? ??????????? ???????????????? ??????????, ??????? ?? ????? ???? ???????? ??? ???????????? ???-????, ????? ?????????. ???? ?? ?? ??????? ????? ?????????, ?? ?????????????, ?????????????, ??????????? ??? ??????????????? ?????????? ????????? ??? ??? ????? ????????? ? ?????????. ???? ?? ???????? ??? ????????? ????????, ??????????, ??????????????? ???????? ??????????? ?? ???? ? ??????? ?? ???? ?????????? ???? ????????? ? ????? ????????? ??? ????? ? ??????????. > > The information contained in this communication is intended solely for the use of the individual or entity to whom it is addressed and others authorized to receive it. It may contain confidential or legally privileged information. The contents may not be disclosed or used by anyone other than the addressee. If you are not the intended recipient(s), any use, disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful. If you have received this communication in error please notify us immediately by responding to this email and then delete the e-mail and all attachments and any copies thereof. > > (c)20mf50 > -- > 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 yks0000 at gmail.com Mon Mar 30 08:48:00 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 30 Mar 2015 14:18:00 +0530 Subject: [Freeipa-users] IPA Client using Source Code Message-ID: Hi List, We have trying to install IPA-Client using source code. While installing we are seeing many error out of which most are resolved but stuck at below while doing make. Is there any suggestion to get out of it. I will update if I found anything. gcc -DHAVE_CONFIG_H -I. -I. -I. -DPREFIX=\""/usr/local"\" -DBINDIR=\""/usr/local/bin"\" -DLIBDIR=\""/usr/local/lib"\" -DLIBEXECDIR=\""/usr/local/libexec"\" -DDATADIR=\""/usr/local/share"\" -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3 -DWITH_MOZLDAP -g -O2 -MT ipa-getkeytab.o -MD -MP -MF .deps/ipa-getkeytab.Tpo -c -o ipa-getkeytab.o ipa-getkeytab.c ipa-getkeytab.c:41:18: fatal error: popt.h: No such file or directory #include ^ compilation terminated. make[2]: *** [ipa-getkeytab.o] Error 1 make[2]: Leaving directory `/root/freeipa-1.2.1/ipa-client' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/root/freeipa-1.2.1/ipa-client' make: *** [all] Error 2 *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] -------------- next part -------------- An HTML attachment was scrubbed... URL: From natxo.asenjo at gmail.com Mon Mar 30 09:08:35 2015 From: natxo.asenjo at gmail.com (Natxo Asenjo) Date: Mon, 30 Mar 2015 11:08:35 +0200 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: References: Message-ID: On Mon, Mar 30, 2015 at 10:48 AM, Yogesh Sharma wrote: > Hi List, > > We have trying to install IPA-Client using source code. While installing > we are seeing many error out of which most are resolved but stuck at below > while doing make. > > Is there any suggestion to get out of it. I will update if I found > anything. > > gcc -DHAVE_CONFIG_H -I. -I. -I. -DPREFIX=\""/usr/local"\" > -DBINDIR=\""/usr/local/bin"\" -DLIBDIR=\""/usr/local/lib"\" > -DLIBEXECDIR=\""/usr/local/libexec"\" -DDATADIR=\""/usr/local/share"\" > -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3 > -DWITH_MOZLDAP -g -O2 -MT ipa-getkeytab.o -MD -MP -MF > .deps/ipa-getkeytab.Tpo -c -o ipa-getkeytab.o ipa-getkeytab.c > ipa-getkeytab.c:41:18: fatal error: popt.h: No such file or directory > #include > > in fedora I get these results: $ sudo yum whatprovides "*/popt.h" Loaded plugins: langpacks golang-src-1.3.3-1.fc21.noarch : Golang compiler source tree Repo : fedora Matched from: Filename : /usr/lib/golang/src/cmd/gc/popt.h popt-devel-1.16-5.fc21.i686 : Development files for the popt library Repo : fedora Matched from: Filename : /usr/include/popt.h popt-devel-1.16-5.fc21.x86_64 : Development files for the popt library Repo : fedora Matched from: Filename : /usr/include/popt.h HTH, -- regards, natxo -------------- next part -------------- An HTML attachment was scrubbed... URL: From jhrozek at redhat.com Mon Mar 30 09:09:34 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 30 Mar 2015 11:09:34 +0200 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: References: Message-ID: <20150330090934.GY10622@hendrix.redhat.com> On Mon, Mar 30, 2015 at 02:18:00PM +0530, Yogesh Sharma wrote: > Hi List, > > We have trying to install IPA-Client using source code. Why? > While installing we > are seeing many error out of which most are resolved but stuck at below > while doing make. > > Is there any suggestion to get out of it. I will update if I found anything. > > gcc -DHAVE_CONFIG_H -I. -I. -I. -DPREFIX=\""/usr/local"\" > -DBINDIR=\""/usr/local/bin"\" -DLIBDIR=\""/usr/local/lib"\" > -DLIBEXECDIR=\""/usr/local/libexec"\" -DDATADIR=\""/usr/local/share"\" > -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3 > -DWITH_MOZLDAP -g -O2 -MT ipa-getkeytab.o -MD -MP -MF > .deps/ipa-getkeytab.Tpo -c -o ipa-getkeytab.o ipa-getkeytab.c > ipa-getkeytab.c:41:18: fatal error: popt.h: No such file or directory > #include > ^ libpopt-devel is missing. The easiest way to fetch them all is with yum-builddeps. > compilation terminated. > make[2]: *** [ipa-getkeytab.o] Error 1 > make[2]: Leaving directory `/root/freeipa-1.2.1/ipa-client' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/freeipa-1.2.1/ipa-client' ~~~~~~~~~~~~~ Whoa, are you sure? ipa 1.x? From yks0000 at gmail.com Mon Mar 30 09:23:39 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 30 Mar 2015 14:53:39 +0530 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: <20150330090934.GY10622@hendrix.redhat.com> References: <20150330090934.GY10622@hendrix.redhat.com> Message-ID: Hi Jakub: FreeIPA package is not available in Amazon Linux running on EC2 Instance. We tried to install individually packages but it is breaking at many place. It is not 1.x. We had a directory with this name and I extracted the tar in same folder hence showing like this :). We are using 3.0.2 as of now. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Mon, Mar 30, 2015 at 2:39 PM, Jakub Hrozek wrote: > On Mon, Mar 30, 2015 at 02:18:00PM +0530, Yogesh Sharma wrote: > > Hi List, > > > > We have trying to install IPA-Client using source code. > > Why? > > > While installing we > > are seeing many error out of which most are resolved but stuck at below > > while doing make. > > > > Is there any suggestion to get out of it. I will update if I found > anything. > > > > gcc -DHAVE_CONFIG_H -I. -I. -I. -DPREFIX=\""/usr/local"\" > > -DBINDIR=\""/usr/local/bin"\" -DLIBDIR=\""/usr/local/lib"\" > > -DLIBEXECDIR=\""/usr/local/libexec"\" -DDATADIR=\""/usr/local/share"\" > > -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3 > > -DWITH_MOZLDAP -g -O2 -MT ipa-getkeytab.o -MD -MP -MF > > .deps/ipa-getkeytab.Tpo -c -o ipa-getkeytab.o ipa-getkeytab.c > > ipa-getkeytab.c:41:18: fatal error: popt.h: No such file or directory > > #include > > ^ > > libpopt-devel is missing. The easiest way to fetch them all is with > yum-builddeps. > > > compilation terminated. > > make[2]: *** [ipa-getkeytab.o] Error 1 > > make[2]: Leaving directory `/root/freeipa-1.2.1/ipa-client' > > make[1]: *** [all-recursive] Error 1 > > make[1]: Leaving directory `/root/freeipa-1.2.1/ipa-client' > ~~~~~~~~~~~~~ > Whoa, are you sure? ipa 1.x? > > -- > 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 jhrozek at redhat.com Mon Mar 30 09:35:29 2015 From: jhrozek at redhat.com (Jakub Hrozek) Date: Mon, 30 Mar 2015 11:35:29 +0200 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: References: <20150330090934.GY10622@hendrix.redhat.com> Message-ID: <20150330093529.GZ10622@hendrix.redhat.com> On Mon, Mar 30, 2015 at 02:53:39PM +0530, Yogesh Sharma wrote: > Hi Jakub: > > FreeIPA package is not available in Amazon Linux running on EC2 Instance. > We tried to install individually packages but it is breaking at many place. > > It is not 1.x. We had a directory with this name and I extracted the tar in > same folder hence showing like this :). > We are using 3.0.2 as of now. Then I wonder if it would be more useful to add a repo that already contains the package, from CentOS maybe? You'll get the updates for free.. From yks0000 at gmail.com Mon Mar 30 09:36:31 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 30 Mar 2015 15:06:31 +0530 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: <20150330093529.GZ10622@hendrix.redhat.com> References: <20150330090934.GY10622@hendrix.redhat.com> <20150330093529.GZ10622@hendrix.redhat.com> Message-ID: Sure. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Mon, Mar 30, 2015 at 3:05 PM, Jakub Hrozek wrote: > On Mon, Mar 30, 2015 at 02:53:39PM +0530, Yogesh Sharma wrote: > > Hi Jakub: > > > > FreeIPA package is not available in Amazon Linux running on EC2 Instance. > > We tried to install individually packages but it is breaking at many > place. > > > > It is not 1.x. We had a directory with this name and I extracted the tar > in > > same folder hence showing like this :). > > We are using 3.0.2 as of now. > > Then I wonder if it would be more useful to add a repo that already > contains the package, from CentOS maybe? You'll get the updates for > free.. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gokulnathb at gmail.com Mon Mar 30 11:08:13 2015 From: gokulnathb at gmail.com (Gokulnath) Date: Mon, 30 Mar 2015 06:08:13 -0500 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: <20150330093529.GZ10622@hendrix.redhat.com> References: <20150330090934.GY10622@hendrix.redhat.com> <20150330093529.GZ10622@hendrix.redhat.com> Message-ID: Yes that's right, Fedora works great. Gokul Sent from iPhone > On Mar 30, 2015, at 4:35 AM, Jakub Hrozek wrote: > >> On Mon, Mar 30, 2015 at 02:53:39PM +0530, Yogesh Sharma wrote: >> Hi Jakub: >> >> FreeIPA package is not available in Amazon Linux running on EC2 Instance. >> We tried to install individually packages but it is breaking at many place. >> >> It is not 1.x. We had a directory with this name and I extracted the tar in >> same folder hence showing like this :). >> We are using 3.0.2 as of now. > > Then I wonder if it would be more useful to add a repo that already > contains the package, from CentOS maybe? You'll get the updates for > free.. > > -- > 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 Mon Mar 30 12:39:17 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Mar 2015 08:39:17 -0400 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: References: <5518AB6D.1020606@redhat.com> Message-ID: <551943F5.4030803@redhat.com> On 03/29/2015 10:56 PM, Matt . wrote: > > Hi, > > I just tot home and typing from my cell so i'm suite short in words > > Create keytab for ldap-01.domain > Kinit with that to ldap.domain > Curl against ldap.domain > Get a 301 which I manage from curl (goes well) > Get kerberos ticket error > > now I don't kinit anymore so re-use my existing ticket and curl > against ldap-01.domain and I'm accepted and can execute stuff. > > My ssl is OK, ticket also it seems. > Hard to say without the logs what is going on. However here is a thought: If it is trying to get another ticket it might think that the service is in a different domain. Client libraries have a feature to detect which ticket to use depending on the realm the resource belongs to. May be it is thinking that it is a different realm and thus does not use the ticket it has. > Thanks M. > > Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" >: > > On 03/29/2015 04:47 AM, Matt . wrote: > > Hi Guys, > > Now my Certification issues are solved for using a loadbalancer in > front of my ipa servers I get the following: > > Unable to verify your Kerberos credentials > > and in my logs: > > Additional pre-authentication required. > > This happens when I connect throught my loadbalancers, I see > my server > coming ni with the right IP. > > When I access my ipa server directly, not using the > loadbalancer IP > between it, my kerberos Ticket is valid. > > I get the feeling that when I use my loadbalancers and because > of that > I get a 301 redirect it needs a preauth. I see some issues on > mailinglists but it doesn't fit my situation. > > Why wants it the preauth when I already have a valid ticket and my > redirect is followed by CURL and posted the right way ? > > > Can you describe the sequence? > What do you do? > > From the client you try IPA CLI and this is where you see the > problem even with the valid ticket or is the flow different? > > I hope someone has an idea. > > Thanks, > > Matt > > > > -- > 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 dpal at redhat.com Mon Mar 30 12:48:28 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Mar 2015 08:48:28 -0400 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS In-Reply-To: References: <5518AA63.5070403@redhat.com> Message-ID: <5519461C.2070801@redhat.com> On 03/29/2015 10:27 PM, Gokulnath wrote: > Thanks for getting back. > > 1. As security Kerberos can ticket and in memory can be taken and that session key > Can be used to gain access every where. Primarily this because the plan is to use the solution in cloud. You can use Kerberos in the cloud. It is not worse of better than certs. If you can read memory of a machine you can (potentially) read its keys. But this is the general risk that you take going into the cloud regardless whether you use PKI or Kerberos. In general you do not want to store long term keys in the images but rather add them on the fly when the system is instantiated. The ipa-client-install with OTP registration code provides this capability. It seems that you are trying to overcomplicate things with no obvious reason. If you need help with picking a better approach lest us know what exactly you are trying to accomplish. > > 2. Can I disable DNS as well? And have IPA to run only ldap, ssh key rotation and pki ? > > 3. As during the install, DNS and Kerberos are getting installed and configured. > > I would really appreciate if you can get back. > > Thank you > Gokul > Sent from iPhone > >> On Mar 29, 2015, at 8:44 PM, Dmitri Pal wrote: >> >>> On 03/29/2015 11:50 AM, Gokul wrote: >>> Hi, >>> >>> I am tried to run some of my user cases with FreeIPA. >>> >>> Have FreeIPA to do only SSH key management in LDAP and PKI management. >>> >>> The understand that every request is kerberized and it has the DNS is must configuration. >>> >>> Can I have FreeIPA to run only SSH Key management with LDAP and a PKI server with dogtag? >>> >>> Thank you >>> Gokul >> You can't turn off Kerberos. You would need Kerberos for administration. >> But other clients can take advantage of LDAP and SSH only. >> However you are significantly limiting your functionality and capabilities. >> Kerberos is really the key of the solution. >> >> What is the reason you try to avoid using it? >> >> >> -- >> 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 gokulnathb at gmail.com Mon Mar 30 12:58:53 2015 From: gokulnathb at gmail.com (Gokulnath) Date: Mon, 30 Mar 2015 07:58:53 -0500 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS In-Reply-To: <5519461C.2070801@redhat.com> References: <5518AA63.5070403@redhat.com> <5519461C.2070801@redhat.com> Message-ID: <5745FCE3-8685-4407-99DC-BECB5F4532E9@gmail.com> Thanks for the update. The reason for weigh in the Kerberos option is to have that as an option to disable if needed, security is more important. I had to say this because there was a question on "why I would disable it". I agree that the otp should definitely provide some additional layer of security. Let me test and reply back. Thanks again. Gokul Sent from iPhone > On Mar 30, 2015, at 7:48 AM, Dmitri Pal wrote: > >> On 03/29/2015 10:27 PM, Gokulnath wrote: >> Thanks for getting back. >> >> 1. As security Kerberos can ticket and in memory can be taken and that session key >> Can be used to gain access every where. Primarily this because the plan is to use the solution in cloud. > > You can use Kerberos in the cloud. It is not worse of better than certs. > If you can read memory of a machine you can (potentially) read its keys. > But this is the general risk that you take going into the cloud regardless whether you use PKI or Kerberos. > > In general you do not want to store long term keys in the images but rather add them on the fly when the system is instantiated. > The ipa-client-install with OTP registration code provides this capability. > > It seems that you are trying to overcomplicate things with no obvious reason. > If you need help with picking a better approach lest us know what exactly you are trying to accomplish. > >> >> 2. Can I disable DNS as well? And have IPA to run only ldap, ssh key rotation and pki ? >> >> 3. As during the install, DNS and Kerberos are getting installed and configured. >> >> I would really appreciate if you can get back. >> >> Thank you >> Gokul >> Sent from iPhone >> >>>> On Mar 29, 2015, at 8:44 PM, Dmitri Pal wrote: >>>> >>>> On 03/29/2015 11:50 AM, Gokul wrote: >>>> Hi, >>>> >>>> I am tried to run some of my user cases with FreeIPA. >>>> >>>> Have FreeIPA to do only SSH key management in LDAP and PKI management. >>>> >>>> The understand that every request is kerberized and it has the DNS is must configuration. >>>> >>>> Can I have FreeIPA to run only SSH Key management with LDAP and a PKI server with dogtag? >>>> >>>> Thank you >>>> Gokul >>> You can't turn off Kerberos. You would need Kerberos for administration. >>> But other clients can take advantage of LDAP and SSH only. >>> However you are significantly limiting your functionality and capabilities. >>> Kerberos is really the key of the solution. >>> >>> What is the reason you try to avoid using it? >>> >>> >>> -- >>> 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 sbose at redhat.com Mon Mar 30 13:03:24 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 30 Mar 2015 15:03:24 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: References: <5518AB6D.1020606@redhat.com> Message-ID: <20150330130324.GB8895@p.redhat.com> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote: > Hi, > > I just tot home and typing from my cell so i'm suite short in words > > Create keytab for ldap-01.domain > Kinit with that to ldap.domain > Curl against ldap.domain > Get a 301 which I manage from curl (goes well) > Get kerberos ticket error > > now I don't kinit anymore so re-use my existing ticket and curl against > ldap-01.domain and I'm accepted and can execute stuff. > > My ssl is OK, ticket also it seems. Maybe the output of KRB5_TRACE=/dev/sdtout curl -v .... might help to see what is going on? bye, Sumit > > Thanks M. > Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : > > > On 03/29/2015 04:47 AM, Matt . wrote: > > > >> Hi Guys, > >> > >> Now my Certification issues are solved for using a loadbalancer in > >> front of my ipa servers I get the following: > >> > >> Unable to verify your Kerberos credentials > >> > >> and in my logs: > >> > >> Additional pre-authentication required. > >> > >> This happens when I connect throught my loadbalancers, I see my server > >> coming ni with the right IP. > >> > >> When I access my ipa server directly, not using the loadbalancer IP > >> between it, my kerberos Ticket is valid. > >> > >> I get the feeling that when I use my loadbalancers and because of that > >> I get a 301 redirect it needs a preauth. I see some issues on > >> mailinglists but it doesn't fit my situation. > >> > >> Why wants it the preauth when I already have a valid ticket and my > >> redirect is followed by CURL and posted the right way ? > >> > > > > Can you describe the sequence? > > What do you do? > > > > From the client you try IPA CLI and this is where you see the problem even > > with the valid ticket or is the flow different? > > > > I hope someone has an idea. > >> > >> Thanks, > >> > >> Matt > >> > >> > > > > -- > > 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 > > > -- > 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 Joshua.Gould at osumc.edu Mon Mar 30 13:08:54 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Mon, 30 Mar 2015 09:08:54 -0400 Subject: [Freeipa-users] Troubleshooting SSO Message-ID: SSO works intermittently. I?m having trouble tracing the issue. Here is what I see from /var/log/secure. Where should I look for more detail to figure out why the SSO login is failing? Mar 30 08:47:39 mid-ipa-vp01 sshd[9317]: Starting session: shell on pts/0 for root from 10.34.149.105 port 49725 Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: Setting controlling tty using TIOCSCTTY. Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: PAM: reinitializing credentials Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: permanently_set_uid: 0/0 Mar 30 08:49:05 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 Mar 30 08:50:05 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 Mar 30 08:51:57 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 Mar 30 08:52:57 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 Mar 30 08:53:51 mid-ipa-vp01 sshd[1388]: debug1: Forked child 12621. Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: Set /proc/self/oom_score_adj to 0 Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: inetd sockets after dupping: 3, 3 Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: Connection from 10.80.5.239 port 52982 on 10.127.26.73 port 22 Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.64 Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: no match: PuTTY_Release_0.64 Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Enabling compatibility mode for protocol 2.0 Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Local version string SSH-2.0-OpenSSH_6.6.1 Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SELinux support enabled [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: permanently_set_uid: 74/74 [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEXINIT sent [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEXINIT received [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_NEWKEYS sent [preauth] Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: expecting SSH2_MSG_NEWKEYS [preauth] Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_NEWKEYS received [preauth] Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: KEX done [preauth] Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method none [preauth] Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: attempt 0 failures 0 [preauth] Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: initializing for "adm-faru03 at test.osuwmc" Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: setting PAM_RHOST to "svr-addc-vt01.test.osuwmc" Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: setting PAM_TTY to "ssh" Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method gssapi-with-mic [preauth] Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: attempt 1 failures 0 [preauth] Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: Postponed gssapi-with-mic for adm-faru03 at test.osuwmc from 10.80.5.239 port 52982 ssh2 [preauth] Mar 30 08:53:58 mid-ipa-vp01 sshd[12621]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method password [preauth] Mar 30 08:53:58 mid-ipa-vp01 sshd[12621]: debug1: attempt 2 failures 0 [preauth] Mar 30 08:53:58 mid-ipa-vp01 sshd[12621]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc Mar 30 08:54:00 mid-ipa-vp01 sshd[12621]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc Mar 30 08:54:00 mid-ipa-vp01 sshd[12621]: debug1: PAM: password authentication accepted for adm-faru03 at test.osuwmc Mar 30 08:54:00 mid-ipa-vp01 sshd[12621]: debug1: do_pam_account: called -------------- next part -------------- An HTML attachment was scrubbed... URL: From sbose at redhat.com Mon Mar 30 13:35:16 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 30 Mar 2015 15:35:16 +0200 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: Message-ID: <20150330133516.GC8895@p.redhat.com> On Mon, Mar 30, 2015 at 09:08:54AM -0400, Gould, Joshua wrote: > SSO works intermittently. I?m having trouble tracing the issue. Here is what I see from /var/log/secure. Where should I look for more detail to figure out why the SSO login is failing? assuming you have a valid Kerberos ticket the most probable reason is that libkrb5 cannot properly relate the Kerberos principal from the ticket to the local user name you use at the login prompt. With DEBUG3 you should see some messages containing '*userok*'. If you see failures related to these messages it most probable is this case. Recent versions of SSSD will configure a plugin for libkrb5 which can handle this. But for older version you either have to create a .k5login file in the users home directory containing the Kerberos principal or use auth_to_local directives in /etc/krb5.conf as described in http://www.freeipa.org/page/Active_Directory_trust_setup#Edit_.2Fetc.2Fkrb5.conf HTH bye, Sumit > > Mar 30 08:47:39 mid-ipa-vp01 sshd[9317]: Starting session: shell on pts/0 for root from 10.34.149.105 port 49725 > Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: Setting controlling tty using TIOCSCTTY. > Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: PAM: reinitializing credentials > Mar 30 08:47:39 mid-ipa-vp01 sshd[9322]: debug1: permanently_set_uid: 0/0 > Mar 30 08:49:05 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 > Mar 30 08:50:05 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 > Mar 30 08:51:57 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 > Mar 30 08:52:57 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 > Mar 30 08:53:51 mid-ipa-vp01 sshd[1388]: debug1: Forked child 12621. > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: Set /proc/self/oom_score_adj to 0 > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: inetd sockets after dupping: 3, 3 > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: Connection from 10.80.5.239 port 52982 on 10.127.26.73 port 22 > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.64 > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: no match: PuTTY_Release_0.64 > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Enabling compatibility mode for protocol 2.0 > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: Local version string SSH-2.0-OpenSSH_6.6.1 > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SELinux support enabled [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: permanently_set_uid: 74/74 [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEXINIT sent [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEXINIT received [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_NEWKEYS sent [preauth] > Mar 30 08:53:51 mid-ipa-vp01 sshd[12621]: debug1: expecting SSH2_MSG_NEWKEYS [preauth] > Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: SSH2_MSG_NEWKEYS received [preauth] > Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: KEX done [preauth] > Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method none [preauth] > Mar 30 08:53:52 mid-ipa-vp01 sshd[12621]: debug1: attempt 0 failures 0 [preauth] > Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: initializing for "adm-faru03 at test.osuwmc" > Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: setting PAM_RHOST to "svr-addc-vt01.test.osuwmc" > Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: PAM: setting PAM_TTY to "ssh" > Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method gssapi-with-mic [preauth] > Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: debug1: attempt 1 failures 0 [preauth] > Mar 30 08:53:53 mid-ipa-vp01 sshd[12621]: Postponed gssapi-with-mic for adm-faru03 at test.osuwmc from 10.80.5.239 port 52982 ssh2 [preauth] > Mar 30 08:53:58 mid-ipa-vp01 sshd[12621]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method password [preauth] > Mar 30 08:53:58 mid-ipa-vp01 sshd[12621]: debug1: attempt 2 failures 0 [preauth] > Mar 30 08:53:58 mid-ipa-vp01 sshd[12621]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc > Mar 30 08:54:00 mid-ipa-vp01 sshd[12621]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc > Mar 30 08:54:00 mid-ipa-vp01 sshd[12621]: debug1: PAM: password authentication accepted for adm-faru03 at test.osuwmc > Mar 30 08:54:00 mid-ipa-vp01 sshd[12621]: debug1: do_pam_account: called > -- > 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 Joshua.Gould at osumc.edu Mon Mar 30 14:09:00 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Mon, 30 Mar 2015 10:09:00 -0400 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: <20150330133516.GC8895@p.redhat.com> References: <20150330133516.GC8895@p.redhat.com> Message-ID: I configured the .k5login per the RH docs. $ cat .k5login adm-faru03 at TEST.OSUWMC TEST.OSUWMC\adm-faru03 $ I upped the debugging to DEBUG3 but I can?t make sense of the error. Can you help? I?m getting better but I can?t get this one yet. Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: Connection from 10.80.5.239 port 50824 on 10.127.26.73 port 22 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.64 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: no match: PuTTY_Release_0.64 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: Enabling compatibility mode for protocol 2.0 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: Local version string SSH-2.0-OpenSSH_6.6.1 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: fd 3 setting O_NONBLOCK Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: ssh_sandbox_init: preparing rlimit sandbox Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: Network child is on pid 12794 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: preauth child monitor started Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SELinux support enabled [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: ssh_selinux_change_context: setting context from 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u:system_r:sshd_net_t:s0-s0:c0.c1023' [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: privsep user:group 74:74 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: permanently_set_uid: 74/74 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_KEXINIT sent [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_KEXINIT received [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha 2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchan ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c om,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc ,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysato r.liu.se [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c om,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc ,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysato r.liu.se [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at op enssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac- md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at open ssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.c om,hmac-sha1-96,hmac-md5-96 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at op enssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac- md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at open ssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.c om,hmac-sha1-96,hmac-md5-96 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: reserved 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,dif fie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024- sha1 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes 128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a rcfour128 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes 128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a rcfour128 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: none,zlib [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: none,zlib [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: reserved 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: mac_setup: setup hmac-sha2-256 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: mac_setup: setup hmac-sha2-256 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 120 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive_expect entering: type 121 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 120 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 121 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 120 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive_expect entering: type 121 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 120 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 121 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive_expect entering: type 1 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 0 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_moduli: got parameters: 1024 4096 8192 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 1 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 0 used once, disabling now Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_choose_dh: remaining 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: bits set: 2077/4096 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: bits set: 2021/4096 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_key_sign entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 6 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive_expect entering: type 7 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 6 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_sign Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_sign: signature 0x7f4788d8c440(271) Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 7 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 6 used once, disabling now Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_derive_keys [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: set_newkeys: mode 1 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_NEWKEYS sent [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: expecting SSH2_MSG_NEWKEYS [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: set_newkeys: mode 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_NEWKEYS received [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: KEX done [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method none [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: attempt 0 failures 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_getpwnamallow entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 8 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive_expect entering: type 9 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 8 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_pwnamallow Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: Trying to reverse map address 10.80.5.239. Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: parse_server_config: config reprocess config len 899 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 9 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 8 used once, disabling now Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request: setting up authctxt for adm-faru03 at test.osuwmc [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_start_pam entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 100 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_inform_authserv entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 4 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_inform_authrole entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 80 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request: try method none [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 100 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: initializing for "adm-faru03 at test.osuwmc" Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: setting PAM_RHOST to "svr-addc-vt01.test.osuwmc" Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: setting PAM_TTY to "ssh" Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 100 used once, disabling now Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method gssapi-with-mic [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: attempt 1 failures 0 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request: try method gssapi-with-mic [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 42 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive_expect entering: type 43 [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 4 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_authserv: service=ssh-connection, style= Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 4 used once, disabling now Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 80 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_authrole: role= Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 80 used once, disabling now Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 42 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 43 Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: Postponed gssapi-with-mic for adm-faru03 at test.osuwmc from 10.80.5.239 port 50824 ssh2 [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method password [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug1: attempt 2 failures 0 [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request: try method password [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_auth_password entering [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send entering: type 12 [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive_expect entering: type 13 [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering [preauth] Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive entering Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking request 12 Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: PAM: sshpam_passwd_conv called with 1 messages Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc Mar 30 09:57:25 mid-ipa-vp01 sshd[12793]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc Mar 30 09:57:25 mid-ipa-vp01 sshd[12793]: debug1: PAM: password authentication accepted for adm-faru03 at test.osuwmc On 3/30/15, 9:35 AM, "Sumit Bose" wrote: >assuming you have a valid Kerberos ticket the most probable reason is >that libkrb5 cannot properly relate the Kerberos principal from the >ticket to the local user name you use at the login prompt. With DEBUG3 >you should see some messages containing '*userok*'. If you see failures >related to these messages it most probable is this case. > >Recent versions of SSSD will configure a plugin for libkrb5 which can >handle this. But for older version you either have to create a .k5login >file in the users home directory containing the Kerberos principal or >use auth_to_local directives in /etc/krb5.conf as described in >https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeipa.org_page_A >ctive-5FDirectory-5Ftrust-5Fsetup-23Edit-5F.2Fetc.2Fkrb5.conf&d=AwIDaQ&c=k >9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8z >PbIs_SvJwojC24&m=4CkfthdUOBBXSFdkUzW4imHzEchORW-ZPDVNXQlaZ3A&s=a7-Ti-Mlcie >m4dhsLicRf0Qg6sZDhThV-kMNED2rYug&e= > >HTH > >bye, >Sumit From janellenicole80 at gmail.com Mon Mar 30 14:15:32 2015 From: janellenicole80 at gmail.com (Janelle) Date: Mon, 30 Mar 2015 09:15:32 -0500 Subject: [Freeipa-users] anonymous binds limits? In-Reply-To: <5518A8F9.6010507@redhat.com> References: <5515F437.4030506@gmail.com> <5518A8F9.6010507@redhat.com> Message-ID: <55195A84.5010508@gmail.com> For LDAP-only clients, I see an issue with performance on the dirsrv backends, and much of it has to do with 2 things: 1. Anonymous binds (1000's because of 7000+ hosts) 2. unindexed searches <-- perhaps the biggest problem and working on troubleshooting that and figuring out how to fix it. Thank you ~J On 3/29/15 8:38 PM, Dmitri Pal wrote: > On 03/27/2015 08:22 PM, Janelle wrote: >> Hello, >> >> Just wondering if there is an easy way to increase anonymous binds on >> the back end for non Kerberos clients? >> I have seen some mention of it, and that IPA has limits, can't can't >> find a lot of detail? >> >> Thank you >> ~J >> > I am not sure I understand what you are asking. > What do you mean by "increase anonymous binds" ? > Increase timeout? Or you want to allow anonymous binds? > From lslebodn at redhat.com Mon Mar 30 14:21:37 2015 From: lslebodn at redhat.com (Lukas Slebodnik) Date: Mon, 30 Mar 2015 16:21:37 +0200 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <7c60faba985b3343bd87c1ef16ad9814@unicyber.co.uk> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> <55137570.2070606@redhat.com> <5513974F.2080608@unicyber.co.uk> <901732470.4546498.1427358670169.JavaMail.zimbra@redhat.com> <7c60faba985b3343bd87c1ef16ad9814@unicyber.co.uk> Message-ID: <20150330142137.GG18434@mail.corp.redhat.com> On (30/03/15 05:36), g.fer.ordas at unicyber.co.uk wrote: > >Hey Guys > >Not sure if I am missing any bit.... but this was the thing in the end: > > >http://generations.menteyarte.org/archives/195-freeipa-server-and-SSSD-on-Ubuntu.html > >I managed to have it working and I have documented all those nasty bits which >might save people's time. The whole weekend gone but for the less has been >productive. > >I am including the SUDO bit which is usually a pain in my experience.. > Do you relly have to enabled enumeration? "enumerate = True" It would be good if you could remove it from the post. LS From jpazdziora at redhat.com Mon Mar 30 14:45:43 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 30 Mar 2015 16:45:43 +0200 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: Message-ID: <20150330144543.GA4156@redhat.com> On Mon, Mar 30, 2015 at 09:08:54AM -0400, Gould, Joshua wrote: > SSO works intermittently. I?m having trouble tracing the issue. Here is what I see from /var/log/secure. Where should I look for more detail to figure out why the SSO login is failing? What OS versions is this and how was the machine enrolled -- ipa-client-install, realm join, or some other way? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Mon Mar 30 14:47:30 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Mar 2015 16:47:30 +0200 Subject: [Freeipa-users] Freeipa Server down !! In-Reply-To: <5518B3A4.1070705@redhat.com> References: <3126552.348nSDbtq8@techz> <5516F71A.2090201@redhat.com> <5517D562.3050103@obfusc8.org> <5518AAA1.2070601@redhat.com> <5518B3A4.1070705@redhat.com> Message-ID: <55196202.3060007@redhat.com> On 03/30/2015 04:23 AM, Rob Crittenden wrote: > Dmitri Pal wrote: >> On 03/29/2015 06:35 AM, Peter Fern wrote: >>> On 29/03/15 05:46, Rob Crittenden wrote: >>>> Should be back up now. >>>> >>>> rob >>> >>> Appears to be dead again. >>> >> It is in fact down again. >> > > The quote is exceeded in the openshift gear. I cleaned up a log file > which should buy a bit of time. I got us more space on the OpenShift wiki gear, we should not hit this one again (in near future). Sorry for the inconvenience, Martin From Joshua.Gould at osumc.edu Mon Mar 30 14:50:11 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Mon, 30 Mar 2015 10:50:11 -0400 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: <20150330144543.GA4156@redhat.com> References: <20150330144543.GA4156@redhat.com> Message-ID: It?s actually my IPA server which is also a client, so both are 7.1. My memory is fuzzy as far as the client on the server. Isn?t it setup already as part of the server install? On 3/30/15, 10:45 AM, "Jan Pazdziora" wrote: >On Mon, Mar 30, 2015 at 09:08:54AM -0400, Gould, Joshua wrote: >> SSO works intermittently. I?m having trouble tracing the issue. Here is >>what I see from /var/log/secure. Where should I look for more detail to >>figure out why the SSO login is failing? > >What OS versions is this and how was the machine enrolled -- >ipa-client-install, realm join, or some other way? > >-- >Jan Pazdziora >Principal Software Engineer, Identity Management Engineering, Red Hat From g.fer.ordas at unicyber.co.uk Mon Mar 30 14:51:56 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Mon, 30 Mar 2015 07:51:56 -0700 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <20150330081647.GV10622@hendrix.redhat.com> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> <55137570.2070606@redhat.com> <5513974F.2080608@unicyber.co.uk> <901732470.4546498.1427358670169.JavaMail.zimbra@redhat.com> <7c60faba985b3343bd87c1ef16ad9814@unicyber.co.uk> <20150330081647.GV10622@hendrix.redhat.com> Message-ID: <5519630C.9090301@unicyber.co.uk> Hi Jakub Yes, I can also include that. The configuration I was showing was a simple one, mainly I focused on the library set as it is usually the most problematic part in old distributions, but I will also include your comment as indeed makes more sense. As I was suggesting in the post, sssd is flexible enough admit multiple configurations, once you get a working one you can work on improving it. (Also I wanted to write that asap before I forget any important detail) Your comment is very much appreciated and I will update accordingly Thanks On 30/03/2015 01:16, Jakub Hrozek wrote: > On Mon, Mar 30, 2015 at 05:36:00AM +0100, g.fer.ordas at unicyber.co.uk wrote: >> Hey Guys >> >> Not sure if I am missing any bit.... but this was the thing in the end: >> >> >> http://generations.menteyarte.org/archives/195-freeipa-server-and-SSSD-on-Ubuntu.html >> >> I managed to have it working and I have documented all those nasty bits >> which might save people's time. The whole weekend gone but for the less has >> been productive. >> >> I am including the SUDO bit which is usually a pain in my experience.. >> >> Thanks > Thank you very much for documenting this, but wouldn't it be better to > use id_provider=ipa instead? > > Then the configuration would be simpler, less error prone and would > authenticate more securely. You don't need to run ipa-client-install on > the box, you can generate the client keytab elsewhere and transfer it to > the client. > From jpazdziora at redhat.com Mon Mar 30 14:55:42 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 30 Mar 2015 16:55:42 +0200 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: <20150330144543.GA4156@redhat.com> Message-ID: <20150330145542.GQ4696@redhat.com> On Mon, Mar 30, 2015 at 10:50:11AM -0400, Gould, Joshua wrote: > It?s actually my IPA server which is also a client, so both are 7.1. My > memory is fuzzy as far as the client on the server. Isn?t it setup already > as part of the server install? So you are logging in from the server to the server? But you have Connection from 10.80.5.239 port 52982 on 10.127.26.73 port 22 debug1: Client protocol version 2.0; client software version PuTTY_Release_0.64 in the log -- different IP addresses, and the client looks like Putty, which would mean you try to log in from a Windows machine ... So that test.osuwmc realm -- is that your IPA server's realm, or AD realm? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From sbose at redhat.com Mon Mar 30 14:58:18 2015 From: sbose at redhat.com (Sumit Bose) Date: Mon, 30 Mar 2015 16:58:18 +0200 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: <20150330133516.GC8895@p.redhat.com> Message-ID: <20150330145818.GD8895@p.redhat.com> On Mon, Mar 30, 2015 at 10:09:00AM -0400, Gould, Joshua wrote: > I configured the .k5login per the RH docs. > > $ cat .k5login > adm-faru03 at TEST.OSUWMC > TEST.OSUWMC\adm-faru03 The second line is not needed. Please note that .k5login must only be read-writable for the owner. Can you check by calling klist in a Windows Command window if you got a proper host/... ticket for the IPA host? What version of IPA and SSSD are you using. Can you check if the following works on a IPA host: kinit adm-faru03 at TEST.OSUWMC kvno host/name.of.the.ipa-client.to.login at IPA.REALM ssh -v -l adm-faru03 at test.osuwmc name.of.the.ipa-client.to.login The error messages return by the ssh -v output might help to see why GSSAPI auth failed. bye, Sumit > $ > > > I upped the debugging to DEBUG3 but I can?t make sense of the error. Can > you help? I?m getting better but I can?t get this one yet. > > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: Connection from 10.80.5.239 port > 50824 on 10.127.26.73 port 22 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: Client protocol version > 2.0; client software version PuTTY_Release_0.64 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: no match: > PuTTY_Release_0.64 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: Enabling compatibility > mode for protocol 2.0 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: Local version string > SSH-2.0-OpenSSH_6.6.1 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: fd 3 setting O_NONBLOCK > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: ssh_sandbox_init: > preparing rlimit sandbox > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: Network child is on pid > 12794 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: preauth child monitor > started > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SELinux support enabled > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: > ssh_selinux_change_context: setting context from > 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to > 'system_u:system_r:sshd_net_t:s0-s0:c0.c1023' [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: privsep user:group 74:74 > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: permanently_set_uid: > 74/74 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: list_hostkey_types: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_KEXINIT sent > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_KEXINIT > received [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha > 2-nistp521,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchan > ge-sha1,diffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c > om,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc > ,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysato > r.liu.se [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c > om,aes256-gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc > ,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysato > r.liu.se [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, > umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at op > enssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac- > md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at open > ssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.c > om,hmac-sha1-96,hmac-md5-96 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, > umac-128-etm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at op > enssh.com,hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac- > md5-96-etm at openssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at open > ssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.c > om,hmac-sha1-96,hmac-md5-96 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > none,zlib at openssh.com [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > none,zlib at openssh.com [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > first_kex_follows 0 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > reserved 0 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,dif > fie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024- > sha1 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > ssh-rsa,ssh-dss [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes > 128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a > rcfour128 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes > 128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a > rcfour128 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > none,zlib [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > none,zlib [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > first_kex_follows 0 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: > reserved 0 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: mac_setup: setup > hmac-sha2-256 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: kex: client->server > aes256-ctr hmac-sha2-256 none [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: mac_setup: setup > hmac-sha2-256 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: kex: server->client > aes256-ctr hmac-sha2-256 none [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: kex: > diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 120 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: > mm_request_receive_expect entering: type 121 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 120 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 121 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: kex: > diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 120 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: > mm_request_receive_expect entering: type 121 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 120 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 121 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: > SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 0 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_choose_dh: waiting > for MONITOR_ANS_MODULI [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: > mm_request_receive_expect entering: type 1 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 0 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_moduli: got > parameters: 1024 4096 8192 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 1 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 0 used > once, disabling now > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_choose_dh: remaining > 0 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: > SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: bits set: 2077/4096 > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: expecting > SSH2_MSG_KEX_DH_GEX_INIT [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: bits set: 2021/4096 > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_key_sign entering > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 6 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_key_sign: waiting for > MONITOR_ANS_SIGN [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: > mm_request_receive_expect entering: type 7 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 6 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_sign > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_sign: > signature 0x7f4788d8c440(271) > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 7 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 6 used > once, disabling now > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: > SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_derive_keys [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: set_newkeys: mode 1 > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_NEWKEYS sent > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: expecting > SSH2_MSG_NEWKEYS [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: set_newkeys: mode 0 > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: SSH2_MSG_NEWKEYS > received [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: KEX done [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: userauth-request for > user adm-faru03 at test.osuwmc service ssh-connection method none [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: attempt 0 failures 0 > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_getpwnamallow > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 8 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_getpwnamallow: > waiting for MONITOR_ANS_PWNAM [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: > mm_request_receive_expect entering: type 9 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 8 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_pwnamallow > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: Trying to reverse map > address 10.80.5.239. > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: parse_server_config: > config reprocess config len 899 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_pwnamallow: > sending MONITOR_ANS_PWNAM: 1 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 9 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 8 used > once, disabling now > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request: > setting up authctxt for adm-faru03 at test.osuwmc [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_start_pam entering > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 100 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_inform_authserv > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 4 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_inform_authrole > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 80 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request: > try method none [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: userauth_finish: failure > partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 100 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: initializing for > "adm-faru03 at test.osuwmc" > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: setting PAM_RHOST > to "svr-addc-vt01.test.osuwmc" > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: PAM: setting PAM_TTY to > "ssh" > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 100 used > once, disabling now > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: userauth-request for > user adm-faru03 at test.osuwmc service ssh-connection method gssapi-with-mic > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug1: attempt 1 failures 0 > [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request: > try method gssapi-with-mic [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 42 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: > mm_request_receive_expect entering: type 43 [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering [preauth] > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 4 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_authserv: > service=ssh-connection, style= > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 4 used > once, disabling now > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 80 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_answer_authrole: role= > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: monitor_read: 80 used > once, disabling now > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 42 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 43 > Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: Postponed gssapi-with-mic for > adm-faru03 at test.osuwmc from 10.80.5.239 port 50824 ssh2 [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug1: userauth-request for > user adm-faru03 at test.osuwmc service ssh-connection method password > [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug1: attempt 2 failures 0 > [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug2: input_userauth_request: > try method password [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_auth_password > entering [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_send > entering: type 12 [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_auth_password: > waiting for MONITOR_ANS_AUTHPASSWORD [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: > mm_request_receive_expect entering: type 13 [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering [preauth] > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: mm_request_receive > entering > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: monitor_read: checking > request 12 > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: debug3: PAM: sshpam_passwd_conv > called with 1 messages > Mar 30 09:57:23 mid-ipa-vp01 sshd[12793]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc > Mar 30 09:57:25 mid-ipa-vp01 sshd[12793]: pam_sss(sshd:auth): > authentication success; logname= uid=0 euid=0 tty=ssh ruser= > rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc > Mar 30 09:57:25 mid-ipa-vp01 sshd[12793]: debug1: PAM: password > authentication accepted for adm-faru03 at test.osuwmc > > > > On 3/30/15, 9:35 AM, "Sumit Bose" wrote: > > >assuming you have a valid Kerberos ticket the most probable reason is > >that libkrb5 cannot properly relate the Kerberos principal from the > >ticket to the local user name you use at the login prompt. With DEBUG3 > >you should see some messages containing '*userok*'. If you see failures > >related to these messages it most probable is this case. > > > >Recent versions of SSSD will configure a plugin for libkrb5 which can > >handle this. But for older version you either have to create a .k5login > >file in the users home directory containing the Kerberos principal or > >use auth_to_local directives in /etc/krb5.conf as described in > >https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeipa.org_page_A > >ctive-5FDirectory-5Ftrust-5Fsetup-23Edit-5F.2Fetc.2Fkrb5.conf&d=AwIDaQ&c=k > >9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4&r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8z > >PbIs_SvJwojC24&m=4CkfthdUOBBXSFdkUzW4imHzEchORW-ZPDVNXQlaZ3A&s=a7-Ti-Mlcie > >m4dhsLicRf0Qg6sZDhThV-kMNED2rYug&e= > > > >HTH > > > >bye, > >Sumit > > From g.fer.ordas at unicyber.co.uk Mon Mar 30 14:58:27 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Mon, 30 Mar 2015 07:58:27 -0700 Subject: [Freeipa-users] Ubuntu sssd client -- FreeIPA Server fed from AD In-Reply-To: <20150330142137.GG18434@mail.corp.redhat.com> References: <55122775.5040406@redhat.com> <5513546F.8090302@redhat.com> <949e53ba-e161-4ae2-895e-ed09bfb51920@email.typeapp.com> <55137570.2070606@redhat.com> <5513974F.2080608@unicyber.co.uk> <901732470.4546498.1427358670169.JavaMail.zimbra@redhat.com> <7c60faba985b3343bd87c1ef16ad9814@unicyber.co.uk> <20150330142137.GG18434@mail.corp.redhat.com> Message-ID: <55196493.2000109@unicyber.co.uk> Yes, you are right. I was using the enumerate on my testing I forgot to disable the enumerate when I was templating the configuration. On 30/03/2015 07:21, Lukas Slebodnik wrote: > On (30/03/15 05:36), g.fer.ordas at unicyber.co.uk wrote: >> Hey Guys >> >> Not sure if I am missing any bit.... but this was the thing in the end: >> >> >> http://generations.menteyarte.org/archives/195-freeipa-server-and-SSSD-on-Ubuntu.html >> >> I managed to have it working and I have documented all those nasty bits which >> might save people's time. The whole weekend gone but for the less has been >> productive. >> >> I am including the SUDO bit which is usually a pain in my experience.. >> > Do you relly have to enabled enumeration? > "enumerate = True" > > It would be good if you could remove it from the post. > > LS > From g.fer.ordas at unicyber.co.uk Mon Mar 30 15:04:14 2015 From: g.fer.ordas at unicyber.co.uk (Gonzalo Fernandez Ordas) Date: Mon, 30 Mar 2015 08:04:14 -0700 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: References: Message-ID: <551965EE.6000203@unicyber.co.uk> You need the development package. that should be popt-devel If you are still using amazon you have to modify the sources to include the devel Otherwise if you feel very crafty you can get to a site such us: http://rpm.pbone.net/ and look for the relevant development package which got the same version as your existing binaries.. On 30/03/2015 01:48, Yogesh Sharma wrote: > Hi List, > > We have trying to install IPA-Client using source code. While > installing we are seeing many error out of which most are resolved but > stuck at below while doing make. > > Is there any suggestion to get out of it. I will update if I found > anything. > > gcc -DHAVE_CONFIG_H -I. -I. -I. -DPREFIX=\""/usr/local"\" > -DBINDIR=\""/usr/local/bin"\" -DLIBDIR=\""/usr/local/lib"\" > -DLIBEXECDIR=\""/usr/local/libexec"\" -DDATADIR=\""/usr/local/share"\" > -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3 > -DWITH_MOZLDAP -g -O2 -MT ipa-getkeytab.o -MD -MP -MF > .deps/ipa-getkeytab.Tpo -c -o ipa-getkeytab.o ipa-getkeytab.c > ipa-getkeytab.c:41:18: fatal error: popt.h: No such file or directory > #include > ^ > compilation terminated. > make[2]: *** [ipa-getkeytab.o] Error 1 > make[2]: Leaving directory `/root/freeipa-1.2.1/ipa-client' > make[1]: *** [all-recursive] Error 1 > make[1]: Leaving directory `/root/freeipa-1.2.1/ipa-client' > make: *** [all] Error 2 > > > > / > Best Regards, > __________________________________________ > / > /Yogesh Sharma > / > /Email: yks0000 at gmail.com | Web: > www.initd.in / > > RHCE, VCE-CIA, RackSpace Cloud U > My LinkedIn Profile > > > From Joshua.Gould at osumc.edu Mon Mar 30 15:04:58 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Mon, 30 Mar 2015 11:04:58 -0400 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: <20150330145542.GQ4696@redhat.com> References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> Message-ID: Sorry I mis-read your question! We?re trying SSO from the test domain conroller via ssh (putty) to the test IPA server. Unix.test.osuwmc is the IPA realm. Test.osuwmc is the AD realm. IPA server is RHEL 7.1 Windows AD DC is Windows Server 2008 R2 They have a two way trust and we?re mapping SID?s. Since most of our SID?s are in the 300,000, we chose to add 1M to each SID to make mapping them easy. Right now I have the allow-all rule configured to allow everyone in on every service to every host, just to rule that out. # ipa trust-show Realm name: TEST.OSUWMC Realm name: test.osuwmc Domain NetBIOS name: TEST Domain Security Identifier: S-1-5-21-226267946-722566613-1883572810 Trust direction: Two-way trust Trust type: Active Directory domain # ipa idrange-find --all ---------------- 2 ranges matched ---------------- dn: cn=TEST.OSUWMC_id_range,cn=ranges,cn=etc,dc=unix,dc=test,dc=osuwmc Range name: TEST.OSUWMC_id_range First Posix ID of the range: 1000000 Number of IDs in the range: 900000 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21-226267946-722566613-1883572810 Range type: Active Directory domain range iparangetyperaw: ipa-ad-trust objectclass: ipatrustedaddomainrange, ipaIDrange dn: cn=UNIX.TEST.OSUWMC_id_range,cn=ranges,cn=etc,dc=unix,dc=test,dc=osuwmc Range name: UNIX.TEST.OSUWMC_id_range First Posix ID of the range: 233600000 Number of IDs in the range: 200000 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 100000000 Range type: local domain range iparangetyperaw: ipa-local objectclass: top, ipaIDrange, ipaDomainIDRange ---------------------------- Number of entries returned 2 ---------------------------- # # id adm-faru03 at test.osuwmc uid=1398410(adm-faru03 at test.osuwmc) gid=1398410(adm-faru03 at test.osuwmc) groups=1398410(adm-faru03 at test.osuwmc), 233600008(citrix_users) # On 3/30/15, 10:55 AM, "Jan Pazdziora" wrote: >On Mon, Mar 30, 2015 at 10:50:11AM -0400, Gould, Joshua wrote: >> It?s actually my IPA server which is also a client, so both are 7.1. My >> memory is fuzzy as far as the client on the server. Isn?t it setup >>already >> as part of the server install? > >So you are logging in from the server to the server? But you have > > Connection from 10.80.5.239 port 52982 on 10.127.26.73 port 22 > debug1: Client protocol version 2.0; client software version >PuTTY_Release_0.64 > >in the log -- different IP addresses, and the client looks like Putty, >which would mean you try to log in from a Windows machine ... > >So that test.osuwmc realm -- is that your IPA server's realm, or AD >realm? > >-- >Jan Pazdziora >Principal Software Engineer, Identity Management Engineering, Red Hat From jpazdziora at redhat.com Mon Mar 30 15:08:29 2015 From: jpazdziora at redhat.com (Jan Pazdziora) Date: Mon, 30 Mar 2015 17:08:29 +0200 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> Message-ID: <20150330150829.GR4696@redhat.com> On Mon, Mar 30, 2015 at 11:04:58AM -0400, Gould, Joshua wrote: > > We?re trying SSO from the test domain conroller via ssh (putty) to the > test IPA server. > > Unix.test.osuwmc is the IPA realm. > Test.osuwmc is the AD realm. > > IPA server is RHEL 7.1 > Windows AD DC is Windows Server 2008 R2 > > They have a two way trust and we?re mapping SID?s. Since most of our SID?s > are in the 300,000, we chose to add 1M to each SID to make mapping them > easy. Can you check that /etc/krb5.conf contains line includedir /var/lib/sss/pubconf/krb5.include.d/ and that /var/lib/sss/pubconf/krb5.include.d/localauth_plugin exists and configures module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so ? -- Jan Pazdziora Principal Software Engineer, Identity Management Engineering, Red Hat From sdutina at gmail.com Mon Mar 30 15:12:46 2015 From: sdutina at gmail.com (Srdjan Dutina) Date: Mon, 30 Mar 2015 15:12:46 +0000 Subject: [Freeipa-users] FreeIPA with Active directory Read-only domain controller trust setup Message-ID: Hi, I'm testing FreeIPA (v4.1.3, Centos 7) - AD (2012 R2) trust on branch site where only AD read-only domain controller (RODC) exists. I'm aware that for initial establishing of trust I need access to writable domain controller so IPA can add trust to AD domains and trusts. But after initial setup, can FreeIPA-AD trust continue to function with IPA access to RODC only? Will Kerberos authentication of AD users on IPA domain hosts work? In this case, FreeIPA server should have DNS forward zone configured with RODC as a forwarder to AD? AD users have cached passwords on RODC, so authentication is possible in case of WAN link failure. Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Mon Mar 30 15:17:07 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Mon, 30 Mar 2015 11:17:07 -0400 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: <20150330150829.GR4696@redhat.com> References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> <20150330150829.GR4696@redhat.com> Message-ID: The include is there: # head /etc/krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = UNIX.TEST.OSUWMC dns_lookup_realm = true # ls -l /var/lib/sss/pubconf/krb5.include.d/localauth_plugin -rw-r--r--. 1 root root 118 Mar 30 08:46 /var/lib/sss/pubconf/krb5.include.d/localauth_plugin # grep module /var/lib/sss/pubconf/krb5.include.d/localauth_plugin module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so # Different write-ups had slightly different examples for this line. Would this be the issue? # auth_to_local = RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ auth_to_local = RULE:[1:$1 $0](^ * TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ On 3/30/15, 11:08 AM, "Jan Pazdziora" wrote: >On Mon, Mar 30, 2015 at 11:04:58AM -0400, Gould, Joshua wrote: >> >> We?re trying SSO from the test domain conroller via ssh (putty) to the >> test IPA server. >> >> Unix.test.osuwmc is the IPA realm. > Test.osuwmc is the AD realm. >> >> IPA server is RHEL 7.1 >> Windows AD DC is Windows Server 2008 R2 >> >> They have a two way trust and we?re mapping SID?s. Since most of our >>SID?s >> are in the 300,000, we chose to add 1M to each SID to make mapping them >> easy. > >Can you check that > > /etc/krb5.conf > >contains line > > includedir /var/lib/sss/pubconf/krb5.include.d/ > >and that > > /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > >exists and configures > > module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so > >? > >-- >Jan Pazdziora >Principal Software Engineer, Identity Management Engineering, Red Hat From mkosek at redhat.com Mon Mar 30 15:36:29 2015 From: mkosek at redhat.com (Martin Kosek) Date: Mon, 30 Mar 2015 17:36:29 +0200 Subject: [Freeipa-users] Centralized logging/audit - looking for use cases or experience Message-ID: <55196D7D.20801@redhat.com> Hello list! I have recently started investigating FreeIPA and centralized logging/audit, capturing, processing and visualization of the logs centrally in an ELK instance or similar. This is a pretty loaded topic, audit/centralized log processing is a big task beyond IPA itself, which is also one of the reasons why IPA does not have it's A part yet... Before I go further in the investigation, I wanted to check with you - admins and users of FreeIPA - what would you expect or what are your use cases for the centralized logging/audit of FreeIPA? So far, I had following use cases in mind: * As Admin or Auditor, I want to see all calls to FreeIPA API so that I can audit administrative changes to FreeIPA servers (source - apache log) * As Security Administrator, I want to see all logins in the network so that I can track both successful attempts for audit, but also failed attempts for brute-force attack detection (source - audit log) * As Network Administrator, I want to see replication status of all my FreeIPA replicas so that I can amend the issue in a timely manner and avoid using out-of-sync data (source - dirsrv errors log) * As Infrastructure Administrator, I want to see broken AD Trusts so that I can restore the functionality (source - correlation between different logs, especially SSSD server mode logs) Does this make sense to you? Or do you have any more use cases for centralized FreeIPA logging/audit in mind? Or do you even have some infrastructure in place that you would like to share? Any feedback is highly welcome! Thanks for help. -- Martin Kosek Supervisor, Software Engineering - Identity Management Team Red Hat Inc. From dpal at redhat.com Mon Mar 30 15:50:31 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Mar 2015 11:50:31 -0400 Subject: [Freeipa-users] anonymous binds limits? In-Reply-To: <55195A84.5010508@gmail.com> References: <5515F437.4030506@gmail.com> <5518A8F9.6010507@redhat.com> <55195A84.5010508@gmail.com> Message-ID: <551970C7.3020404@redhat.com> On 03/30/2015 10:15 AM, Janelle wrote: > For LDAP-only clients, I see an issue with performance on the dirsrv > backends, and much of it has to do with 2 things: > > 1. Anonymous binds (1000's because of 7000+ hosts) > 2. unindexed searches <-- perhaps the biggest problem and working on > troubleshooting that and figuring out how to fix it. For that amount of clients we recommend 2-3 replicas. There is documentation on how to create indexes. https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes-Creating_Indexes.html#Creating_Indexes-Creating_Indexes_from_the_Command_Line I am not a DS guru but AFAIU they need to be created on each replica. You need to check what searches are taking long time and then match the attributes that you are looking for with the list of the indexed attributes. The link about will give you the location where the indexes are stored. > > Thank you > ~J > > On 3/29/15 8:38 PM, Dmitri Pal wrote: >> On 03/27/2015 08:22 PM, Janelle wrote: >>> Hello, >>> >>> Just wondering if there is an easy way to increase anonymous binds >>> on the back end for non Kerberos clients? >>> I have seen some mention of it, and that IPA has limits, can't can't >>> find a lot of detail? >>> >>> Thank you >>> ~J >>> >> I am not sure I understand what you are asking. >> What do you mean by "increase anonymous binds" ? >> Increase timeout? Or you want to allow anonymous binds? >> > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Mar 30 15:56:45 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Mar 2015 11:56:45 -0400 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> <20150330150829.GR4696@redhat.com> Message-ID: <5519723D.5060704@redhat.com> On 03/30/2015 11:17 AM, Gould, Joshua wrote: > The include is there: > # head /etc/krb5.conf > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > default_realm = UNIX.TEST.OSUWMC > dns_lookup_realm = true > > # ls -l /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > -rw-r--r--. 1 root root 118 Mar 30 08:46 > /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > # grep module /var/lib/sss/pubconf/krb5.include.d/localauth_plugin > module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so > # > > > > > Different write-ups had slightly different examples for this line. Would > this be the issue? > > # auth_to_local = > RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ > auth_to_local = RULE:[1:$1 $0](^ * > TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ If you use the plugin then this RULE should not be needed. Have you tried commenting it out and restarting SSSD? > > > On 3/30/15, 11:08 AM, "Jan Pazdziora" wrote: > >> On Mon, Mar 30, 2015 at 11:04:58AM -0400, Gould, Joshua wrote: >>> We?re trying SSO from the test domain conroller via ssh (putty) to the >>> test IPA server. >>> >>> Unix.test.osuwmc is the IPA realm. > Test.osuwmc is the AD realm. >>> >>> IPA server is RHEL 7.1 >>> Windows AD DC is Windows Server 2008 R2 >>> >>> They have a two way trust and we?re mapping SID?s. Since most of our >>> SID?s >>> are in the 300,000, we chose to add 1M to each SID to make mapping them >>> easy. >> Can you check that >> >> /etc/krb5.conf >> >> contains line >> >> includedir /var/lib/sss/pubconf/krb5.include.d/ >> >> and that >> >> /var/lib/sss/pubconf/krb5.include.d/localauth_plugin >> >> exists and configures >> >> module = sssd:/usr/lib64/sssd/modules/sssd_krb5_localauth_plugin.so >> >> ? >> >> -- >> Jan Pazdziora >> Principal Software Engineer, Identity Management Engineering, Red Hat > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Mon Mar 30 16:00:18 2015 From: dpal at redhat.com (Dmitri Pal) Date: Mon, 30 Mar 2015 12:00:18 -0400 Subject: [Freeipa-users] FreeIPA with Active directory Read-only domain controller trust setup In-Reply-To: References: Message-ID: <55197312.7030709@redhat.com> On 03/30/2015 11:12 AM, Srdjan Dutina wrote: > Hi, > > I'm testing FreeIPA (v4.1.3, Centos 7) - AD (2012 R2) trust on branch > site where only AD read-only domain controller (RODC) exists. > I'm aware that for initial establishing of trust I need access to > writable domain controller so IPA can add trust to AD domains and trusts. > But after initial setup, can FreeIPA-AD trust continue to function > with IPA access to RODC only? Should work. > Will Kerberos authentication of AD users on IPA domain hosts work? > In this case, FreeIPA server should have DNS forward zone configured > with RODC as a forwarder to AD? Can't help you here. Hopefully somone with DNS knowledge will chime but they might be gone for the day. > AD users have cached passwords on RODC, so authentication is possible > in case of WAN link failure. > > Thanks! > > -- 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 Mar 30 16:02:48 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Mon, 30 Mar 2015 12:02:48 -0400 Subject: [Freeipa-users] anonymous binds limits? In-Reply-To: <551970C7.3020404@redhat.com> References: <5515F437.4030506@gmail.com> <5518A8F9.6010507@redhat.com> <55195A84.5010508@gmail.com> <551970C7.3020404@redhat.com> Message-ID: <551973A8.5090301@redhat.com> Dmitri Pal wrote: > On 03/30/2015 10:15 AM, Janelle wrote: >> For LDAP-only clients, I see an issue with performance on the dirsrv >> backends, and much of it has to do with 2 things: >> >> 1. Anonymous binds (1000's because of 7000+ hosts) >> 2. unindexed searches <-- perhaps the biggest problem and working on >> troubleshooting that and figuring out how to fix it. > > For that amount of clients we recommend 2-3 replicas. > > There is documentation on how to create indexes. > https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes-Creating_Indexes.html#Creating_Indexes-Creating_Indexes_from_the_Command_Line > > > I am not a DS guru but AFAIU they need to be created on each replica. Correct. > > You need to check what searches are taking long time and then match the > attributes that you are looking for with the list of the indexed > attributes. The link about will give you the location where the indexes > are stored. logconv.pl will help find unindexed searches. rob > >> >> Thank you >> ~J >> >> On 3/29/15 8:38 PM, Dmitri Pal wrote: >>> On 03/27/2015 08:22 PM, Janelle wrote: >>>> Hello, >>>> >>>> Just wondering if there is an easy way to increase anonymous binds >>>> on the back end for non Kerberos clients? >>>> I have seen some mention of it, and that IPA has limits, can't can't >>>> find a lot of detail? >>>> >>>> Thank you >>>> ~J >>>> >>> I am not sure I understand what you are asking. >>> What do you mean by "increase anonymous binds" ? >>> Increase timeout? Or you want to allow anonymous binds? >>> >> > > From yks0000 at gmail.com Mon Mar 30 16:48:50 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Mon, 30 Mar 2015 22:18:50 +0530 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: <551965EE.6000203@unicyber.co.uk> References: <551965EE.6000203@unicyber.co.uk> Message-ID: Thanks Sir. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Mon, Mar 30, 2015 at 8:34 PM, Gonzalo Fernandez Ordas < g.fer.ordas at unicyber.co.uk> wrote: > > You need the development package. that should be popt-devel > If you are still using amazon you have to modify the sources to include > the devel > Otherwise if you feel very crafty you can get to a site such us: > http://rpm.pbone.net/ and look for the relevant development package which > got the same version as your existing binaries.. > > On 30/03/2015 01:48, Yogesh Sharma wrote: > >> Hi List, >> >> We have trying to install IPA-Client using source code. While installing >> we are seeing many error out of which most are resolved but stuck at below >> while doing make. >> >> Is there any suggestion to get out of it. I will update if I found >> anything. >> >> gcc -DHAVE_CONFIG_H -I. -I. -I. -DPREFIX=\""/usr/local"\" >> -DBINDIR=\""/usr/local/bin"\" -DLIBDIR=\""/usr/local/lib"\" >> -DLIBEXECDIR=\""/usr/local/libexec"\" -DDATADIR=\""/usr/local/share"\" >> -I/usr/include/mozldap -I/usr/include/nspr4 -I/usr/include/nss3 >> -DWITH_MOZLDAP -g -O2 -MT ipa-getkeytab.o -MD -MP -MF >> .deps/ipa-getkeytab.Tpo -c -o ipa-getkeytab.o ipa-getkeytab.c >> ipa-getkeytab.c:41:18: fatal error: popt.h: No such file or directory >> #include >> ^ >> compilation terminated. >> make[2]: *** [ipa-getkeytab.o] Error 1 >> make[2]: Leaving directory `/root/freeipa-1.2.1/ipa-client' >> make[1]: *** [all-recursive] Error 1 >> make[1]: Leaving directory `/root/freeipa-1.2.1/ipa-client' >> make: *** [all] Error 2 >> >> >> >> / >> Best Regards, >> __________________________________________ >> / >> /Yogesh Sharma >> / >> /Email: yks0000 at gmail.com | Web: www.initd.in >> / >> >> RHCE, VCE-CIA, RackSpace Cloud U >> My LinkedIn Profile >> >> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Mon Mar 30 17:42:10 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Mon, 30 Mar 2015 13:42:10 -0400 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: <5519723D.5060704@redhat.com> References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> <20150330150829.GR4696@redhat.com> <5519723D.5060704@redhat.com> Message-ID: On 3/30/15, 11:56 AM, "Dmitri Pal" wrote: >># auth_to_local = >>RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ >> auth_to_local = RULE:[1:$1 $0](^ * >>TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ >If you use the plugin then this RULE should not be needed. >Have you tried commenting it out and restarting SSSD? I commented out those lines and restarted SSSD. I still was not able to get in with SSO. Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: fd 5 is not O_NONBLOCK Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug1: Forked child 13750. Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: send_rexec_state: entering fd = 8 config len 899 Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: ssh_msg_send: type 0 Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: send_rexec_state: done Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: oom_adjust_restore Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: Set /proc/self/oom_score_adj to 0 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: rexec start in 5 out 5 newsock 5 pipe 7 sock 8 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: inetd sockets after dupping: 3, 3 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: Connection from 10.80.5.239 port 65333 on 10.127.26.73 port 22 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Client protocol version 2.0; client software version PuTTY_Release_0.64 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: no match: PuTTY_Release_0.64 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Enabling compatibility mode for protocol 2.0 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Local version string SSH-2.0-OpenSSH_6.6.1 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: fd 3 setting O_NONBLOCK Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: ssh_sandbox_init: preparing rlimit sandbox Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: Network child is on pid 13751 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: preauth child monitor started Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_change_context: setting context from 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u: system_r:sshd_net_t:s0-s0:c0.c1023' [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: privsep user:group 74:74 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: permanently_set_uid: 74/74 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: list_hostkey_types: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEXINIT sent [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEXINIT received [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha 2-nistp521 ,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,di ffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c om,aes256- gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish- cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [prea uth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c om,aes256- gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish- cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se [prea uth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, umac-128-e tm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm @ope nssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-s ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hm ac-md5-96 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, umac-128-e tm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm @ope nssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-s ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 6,hm ac-md5-96 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: none,zlib at openssh.com [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: reserved 0 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,dif fie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024- sha1 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: ssh-rsa,ssh-dss [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes 128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a rcfour128 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes 128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a rcfour128 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: none,zlib [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: none,zlib [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: first_kex_follows 0 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: reserved 0 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup hmac-sha2-256 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: client->server aes256-ctr hmac-sha2-256 none [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup hmac-sha2-256 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: server->client aes256-ctr hmac-sha2-256 none [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 120 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 121 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 120 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 121 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 120 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 121 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 120 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 121 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 0 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 1 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 0 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_moduli: got parameters: 1024 4096 8192 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 1 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 0 used once, disabling now Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_choose_dh: remaining 0 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: bits set: 2013/4096 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: bits set: 2017/4096 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_key_sign entering [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 6 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 7 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 6 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_sign Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_sign: signature 0x7f60fd611d20(271) Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 7 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 6 used once, disabling now Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_derive_keys [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: set_newkeys: mode 1 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_NEWKEYS sent [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: expecting SSH2_MSG_NEWKEYS [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: set_newkeys: mode 0 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_NEWKEYS received [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: KEX done [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method none [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: attempt 0 failures 0 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_getpwnamallow entering [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 8 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_getpwnamallow: waiting for MONITOR_ANS_PWNAM [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 9 [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 8 Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pwnamallow Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: Trying to reverse map address 10.80.5.239. Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: parse_server_config: config reprocess config len 899 Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pwnamallow: sending MONITOR_ANS_PWNAM: 1 Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 9 Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 8 used once, disabling now Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: setting up authctxt for adm-faru03 at test.osuwmc [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_start_pam entering [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 100 [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_inform_authserv entering [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 4 [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_inform_authrole entering [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 80 [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: try method none [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: userauth_finish: failure partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 100 Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: initializing for "adm-faru03 at test.osuwmc" Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: setting PAM_RHOST to "svr-addc-vt01.test.osuwmc" Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: setting PAM_TTY to "ssh" Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 100 used once, disabling now Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method gssapi-with-mic [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: attempt 1 failures 0 [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: try method gssapi-with-mic [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 42 [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 43 [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 4 Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authserv: service=ssh-connection, style= Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 4 used once, disabling now Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 80 Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authrole: role= Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 80 used once, disabling now Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 42 Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 43 Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: Postponed gssapi-with-mic for adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 ssh2 [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for user adm-faru03 at test.osuwmc service ssh-connection method password [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug1: attempt 2 failures 0 [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: try method password [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password entering [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 12 [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password: waiting for MONITOR_ANS_AUTHPASSWORD [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 13 [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 12 Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: PAM: sshpam_passwd_conv called with 1 messages Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: pam_unix(sshd:auth): authentication failure; logname= uid=0 euid=0 tty=ssh ruser= rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: pam_sss(sshd:auth): authentication success; logname= uid=0 euid=0 tty=ssh ruser= rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug1: PAM: password authentication accepted for adm-faru03 at test.osuwmc Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authpassword: sending result 1 Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 13 Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 102 Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug1: do_pam_account: called Mar 30 13:33:42 mid-ipa-vp01 sshd[13719]: debug1: server_input_global_request: rtype keepalive at openssh.com want_reply 1 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: PAM: do_pam_account pam_acct_mgmt = 0 (Success) Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 103 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: Accepted password for adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 ssh2 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: monitor_child_preauth: adm-faru03 at test.osuwmc has been authenticated by privileged process Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Waiting for new keys Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 26 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_from_blob: 0x7f60fd62ff00(159) Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup hmac-sha2-256 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Waiting for second key Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_from_blob: 0x7f60fd62ff00(159) Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup hmac-sha2-256 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Getting compression state Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Getting Network I/O buffers Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 122 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 123 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password: user authenticated [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_do_pam_account entering [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 102 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 103 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_do_pam_account returning 1 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: Sending new keys: 0x7f60fd61fc90 0x7f60fd610a40 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_to_blob: converting 0x7f60fd61fc90 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_to_blob: converting 0x7f60fd610a40 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: New keys have been sent [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: Sending compression state [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 26 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: Finished sending state [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 122 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive_expect entering: type 123 [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering [preauth] Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: monitor_read_log: child log fd closed Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_share_sync: Share sync Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_share_sync: Share sync end Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: ssh_sandbox_parent_finish: finished Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: temporarily_use_uid: 1398410/1398410 (e=0/0) Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: ssh_gssapi_storecreds: Not a GSSAPI mechanism Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: restore_uid: 0/0 Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: sshd_selinux_setup_variables: setting execution context Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: PAM: establishing credentials Mar 30 13:33:44 mid-ipa-vp01 sshd[13750]: debug3: PAM: opening session Mar 30 13:33:45 mid-ipa-vp01 sshd[13750]: pam_unix(sshd:session): session opened for user adm-faru03 at test.osuwmc by (uid=0) Mar 30 13:33:46 mid-ipa-vp01 sshd[13750]: User child is on pid 13761 Mar 30 13:33:46 mid-ipa-vp01 sshd[13761]: debug1: PAM: establishing credentials Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: sshd_selinux_setup_variables: setting execution context Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: permanently_set_uid: 1398410/1398410 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: set_newkeys: mode 0 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: set_newkeys: mode 1 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: Entering interactive session for SSH2. Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 10 setting O_NONBLOCK Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 11 setting O_NONBLOCK Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: server_init_dispatch_20 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: Received SSH2_MSG_IGNORE Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: server_input_channel_open: ctype session rchan 256 win 16384 max 16384 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: input_session_request Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: channel 0: new [server-session] Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: session_new: allocate (allocated 0 max 10) Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: session_unused: session id 0 unused Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_new: session 0 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_open: channel 0 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_open: session 0: link with channel 0 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: server_input_channel_open: confirm session Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: server_input_channel_req: channel 0 request pty-req reply 1 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_by_channel: session 0 channel 0 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_input_channel_req: session 0 req pty-req Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: Allocating pty. Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_request_send entering: type 28 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_pty_allocate: waiting for MONITOR_ANS_PTY Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 28 Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pty entering Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug2: session_new: allocate (allocated 0 max 10) Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: session_unused: session id 0 unused Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug1: session_new: session 0 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_request_receive_expect entering: type 29 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_request_receive entering Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_setup_pty: setting TTY context on /dev/pts/2 Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_setup_pty: done Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 29 Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pty: tty /dev/pts/2 ptyfd 5 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_pty_req: session 0 alloc /dev/pts/2 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: server_input_channel_req: channel 0 request shell reply 1 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_by_channel: session 0 channel 0 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_input_channel_req: session 0 req shell Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: Starting session: shell on pts/2 for adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 3 setting TCP_NODELAY Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: packet_set_tos: set IP_TOS 0x10 Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: channel 0: rfd 14 isatty Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 14 setting O_NONBLOCK Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: fd 12 is O_NONBLOCK Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug1: Setting controlling tty using TIOCSCTTY. Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_send entering: type 124 Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_receive_expect entering: type 125 Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive entering Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_receive entering Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking request 124 Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send entering: type 125 Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: KRB5CCNAME=FILE:/tmp/krb5cc_1398410_B30vDK Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: SELINUX_ROLE_REQUESTED= Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: SELINUX_LEVEL_REQUESTED= Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: SELINUX_USE_CURRENT_RANGE= Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: XDG_SESSION_ID=10 Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: XDG_RUNTIME_DIR=/run/user/1398410 Just in case, here is my krb5.conf includedir /var/lib/sss/pubconf/krb5.include.d/ [logging] default = FILE:/var/log/krb5libs.log kdc = FILE:/var/log/krb5kdc.log admin_server = FILE:/var/log/kadmind.log [libdefaults] default_realm = UNIX.TEST.OSUWMC dns_lookup_realm = true dns_lookup_kdc = true rdns = false ticket_lifetime = 24h forwardable = yes udp_preference_limit = 0 # default_ccache_name = KEYRING:persistent:%{uid} [realms] UNIX.TEST.OSUWMC = { kdc = mid-ipa-vp01.unix.test.osuwmc:88 master_kdc = mid-ipa-vp01.unix.test.osuwmc:88 admin_server = mid-ipa-vp01.unix.test.osuwmc:749 default_domain = unix.test.osuwmc pkinit_anchors = FILE:/etc/ipa/ca.crt # auth_to_local = RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ # auth_to_local = RULE:[1:$1 $0](^ * TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ auth_to_local = DEFAULT } [domain_realm] .unix.test.osuwmc = UNIX.TEST.OSUWMC unix.test.osuwmc = UNIX.TEST.OSUWMC [dbmodules] UNIX.TEST.OSUWMC = { db_library = ipadb.so } From gokulnathb at gmail.com Mon Mar 30 17:48:37 2015 From: gokulnathb at gmail.com (Gokulnath) Date: Mon, 30 Mar 2015 12:48:37 -0500 Subject: [Freeipa-users] anonymous binds limits? In-Reply-To: <551973A8.5090301@redhat.com> References: <5515F437.4030506@gmail.com> <5518A8F9.6010507@redhat.com> <55195A84.5010508@gmail.com> <551970C7.3020404@redhat.com> <551973A8.5090301@redhat.com> Message-ID: <958D322B-9372-4DD7-9F3C-B4C46368B2A4@gmail.com> Perform vlv indexing on those attributes and tune the directory for memory. Gokul Sent from iPhone > On Mar 30, 2015, at 11:02 AM, Rob Crittenden wrote: > > Dmitri Pal wrote: >>> On 03/30/2015 10:15 AM, Janelle wrote: >>> For LDAP-only clients, I see an issue with performance on the dirsrv >>> backends, and much of it has to do with 2 things: >>> >>> 1. Anonymous binds (1000's because of 7000+ hosts) >>> 2. unindexed searches <-- perhaps the biggest problem and working on >>> troubleshooting that and figuring out how to fix it. >> >> For that amount of clients we recommend 2-3 replicas. >> >> There is documentation on how to create indexes. >> https://access.redhat.com/documentation/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Managing_Indexes-Creating_Indexes.html#Creating_Indexes-Creating_Indexes_from_the_Command_Line >> >> >> I am not a DS guru but AFAIU they need to be created on each replica. > > Correct. > >> >> You need to check what searches are taking long time and then match the >> attributes that you are looking for with the list of the indexed >> attributes. The link about will give you the location where the indexes >> are stored. > > logconv.pl will help find unindexed searches. > > rob > >> >>> >>> Thank you >>> ~J >>> >>>> On 3/29/15 8:38 PM, Dmitri Pal wrote: >>>>> On 03/27/2015 08:22 PM, Janelle wrote: >>>>> Hello, >>>>> >>>>> Just wondering if there is an easy way to increase anonymous binds >>>>> on the back end for non Kerberos clients? >>>>> I have seen some mention of it, and that IPA has limits, can't can't >>>>> find a lot of detail? >>>>> >>>>> Thank you >>>>> ~J >>>> I am not sure I understand what you are asking. >>>> What do you mean by "increase anonymous binds" ? >>>> Increase timeout? Or you want to allow anonymous binds? > > -- > 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 yamakasi.014 at gmail.com Tue Mar 31 05:54:02 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 07:54:02 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: <20150330130324.GB8895@p.redhat.com> References: <5518AB6D.1020606@redhat.com> <20150330130324.GB8895@p.redhat.com> Message-ID: Hi, I tried to trace some stuff but this doesn't give me much more info. What I see at the moment in the /var/log/httpd/acces_log is exactly what happens but without the info I need to get a better view: 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 258 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 259 "https://ldap.domain.local/ipa/json" "-" 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 401 1469 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 401 1469 2015-03-30 15:03 GMT+02:00 Sumit Bose : > On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote: >> Hi, >> >> I just tot home and typing from my cell so i'm suite short in words >> >> Create keytab for ldap-01.domain >> Kinit with that to ldap.domain >> Curl against ldap.domain >> Get a 301 which I manage from curl (goes well) >> Get kerberos ticket error >> >> now I don't kinit anymore so re-use my existing ticket and curl against >> ldap-01.domain and I'm accepted and can execute stuff. >> >> My ssl is OK, ticket also it seems. > > Maybe the output of > > KRB5_TRACE=/dev/sdtout curl -v .... > > might help to see what is going on? > > bye, > Sumit > >> >> Thanks M. >> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : >> >> > On 03/29/2015 04:47 AM, Matt . wrote: >> > >> >> Hi Guys, >> >> >> >> Now my Certification issues are solved for using a loadbalancer in >> >> front of my ipa servers I get the following: >> >> >> >> Unable to verify your Kerberos credentials >> >> >> >> and in my logs: >> >> >> >> Additional pre-authentication required. >> >> >> >> This happens when I connect throught my loadbalancers, I see my server >> >> coming ni with the right IP. >> >> >> >> When I access my ipa server directly, not using the loadbalancer IP >> >> between it, my kerberos Ticket is valid. >> >> >> >> I get the feeling that when I use my loadbalancers and because of that >> >> I get a 301 redirect it needs a preauth. I see some issues on >> >> mailinglists but it doesn't fit my situation. >> >> >> >> Why wants it the preauth when I already have a valid ticket and my >> >> redirect is followed by CURL and posted the right way ? >> >> >> > >> > Can you describe the sequence? >> > What do you do? >> > >> > From the client you try IPA CLI and this is where you see the problem even >> > with the valid ticket or is the flow different? >> > >> > I hope someone has an idea. >> >> >> >> Thanks, >> >> >> >> Matt >> >> >> >> >> > >> > -- >> > 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 >> > > >> -- >> 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 jcholast at redhat.com Tue Mar 31 05:56:53 2015 From: jcholast at redhat.com (Jan Cholasta) Date: Tue, 31 Mar 2015 07:56:53 +0200 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> <20150330150829.GR4696@redhat.com> <5519723D.5060704@redhat.com> Message-ID: <551A3725.10602@redhat.com> Hi, Dne 30.3.2015 v 19:42 Gould, Joshua napsal(a): > > On 3/30/15, 11:56 AM, "Dmitri Pal" wrote: > >>> # auth_to_local = >>> RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ >>> auth_to_local = RULE:[1:$1 $0](^ * >>> TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ >> If you use the plugin then this RULE should not be needed. >> Have you tried commenting it out and restarting SSSD? > > I commented out those lines and restarted SSSD. I still was not able to > get in with SSO. > > Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: fd 5 is not O_NONBLOCK > Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug1: Forked child 13750. > Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: send_rexec_state: > entering fd = 8 config len 899 > Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: ssh_msg_send: type 0 > Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: send_rexec_state: done > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: oom_adjust_restore > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: Set /proc/self/oom_score_adj to 0 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: rexec start in 5 out 5 > newsock 5 pipe 7 sock 8 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: inetd sockets after > dupping: 3, 3 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: Connection from 10.80.5.239 port > 65333 on 10.127.26.73 port 22 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Client protocol version > 2.0; client software version PuTTY_Release_0.64 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: no match: > PuTTY_Release_0.64 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Enabling compatibility > mode for protocol 2.0 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Local version string > SSH-2.0-OpenSSH_6.6.1 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: fd 3 setting O_NONBLOCK > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: ssh_sandbox_init: > preparing rlimit sandbox > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: Network child is on pid > 13751 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: preauth child monitor > started > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > ssh_selinux_change_context: setting context from > 'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u: > system_r:sshd_net_t:s0-s0:c0.c1023' [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: privsep user:group 74:74 > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: permanently_set_uid: > 74/74 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: list_hostkey_types: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEXINIT sent > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEXINIT > received [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha > 2-nistp521 > ,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,di > ffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c > om,aes256- > gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish- > cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [prea > uth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c > om,aes256- > gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish- > cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > [prea > uth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, > umac-128-e > tm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, > hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm > @ope > nssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-s > ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,hm > ac-md5-96 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, > umac-128-e > tm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, > hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm > @ope > nssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-s > ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > 6,hm > ac-md5-96 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > none,zlib at openssh.com [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > none,zlib at openssh.com [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > first_kex_follows 0 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > reserved 0 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,dif > fie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024- > sha1 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > ssh-rsa,ssh-dss [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes > 128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a > rcfour128 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes > 128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a > rcfour128 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > none,zlib [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > none,zlib [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > first_kex_follows 0 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > reserved 0 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup > hmac-sha2-256 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: client->server > aes256-ctr hmac-sha2-256 none [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup > hmac-sha2-256 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: server->client > aes256-ctr hmac-sha2-256 none [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: > diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 120 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 121 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 120 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 121 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: > diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 120 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 121 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 120 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 121 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: > SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 0 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_choose_dh: waiting > for MONITOR_ANS_MODULI [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 1 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 0 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_moduli: got > parameters: 1024 4096 8192 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 1 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 0 used > once, disabling now > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_choose_dh: remaining > 0 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: > SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: bits set: 2013/4096 > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: expecting > SSH2_MSG_KEX_DH_GEX_INIT [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: bits set: 2017/4096 > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_key_sign entering > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 6 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_key_sign: waiting for > MONITOR_ANS_SIGN [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 7 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 6 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_sign > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_sign: > signature 0x7f60fd611d20(271) > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 7 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 6 used > once, disabling now > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: > SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_derive_keys [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: set_newkeys: mode 1 > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_NEWKEYS sent > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: expecting > SSH2_MSG_NEWKEYS [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: set_newkeys: mode 0 > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_NEWKEYS > received [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: KEX done [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for > user adm-faru03 at test.osuwmc service ssh-connection method none [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: attempt 0 failures 0 > [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_getpwnamallow > entering [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 8 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_getpwnamallow: > waiting for MONITOR_ANS_PWNAM [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 9 [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 8 > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pwnamallow > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: Trying to reverse map > address 10.80.5.239. > Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: parse_server_config: > config reprocess config len 899 > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pwnamallow: > sending MONITOR_ANS_PWNAM: 1 > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 9 > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 8 used > once, disabling now > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: > setting up authctxt for adm-faru03 at test.osuwmc [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_start_pam entering > [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 100 [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_inform_authserv > entering [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 4 [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_inform_authrole > entering [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 80 [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: > try method none [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: userauth_finish: failure > partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" > [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 100 > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: initializing for > "adm-faru03 at test.osuwmc" > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: setting PAM_RHOST > to "svr-addc-vt01.test.osuwmc" > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: setting PAM_TTY to > "ssh" > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 100 used > once, disabling now > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for > user adm-faru03 at test.osuwmc service ssh-connection method gssapi-with-mic > [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: attempt 1 failures 0 > [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: > try method gssapi-with-mic [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 42 [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 43 [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 4 > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authserv: > service=ssh-connection, style= > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 4 used > once, disabling now > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 80 > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authrole: role= > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 80 used > once, disabling now > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 42 > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 43 > Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: Postponed gssapi-with-mic for > adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 ssh2 [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for > user adm-faru03 at test.osuwmc service ssh-connection method password > [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug1: attempt 2 failures 0 > [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: > try method password [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password > entering [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 12 [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password: > waiting for MONITOR_ANS_AUTHPASSWORD [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 13 [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 12 > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: PAM: sshpam_passwd_conv > called with 1 messages > Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: pam_unix(sshd:auth): > authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc > Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: pam_sss(sshd:auth): > authentication success; logname= uid=0 euid=0 tty=ssh ruser= > rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc > Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug1: PAM: password > authentication accepted for adm-faru03 at test.osuwmc > Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authpassword: > sending result 1 > Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 13 > Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 102 > Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug1: do_pam_account: called > Mar 30 13:33:42 mid-ipa-vp01 sshd[13719]: debug1: > server_input_global_request: rtype keepalive at openssh.com want_reply 1 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: PAM: do_pam_account > pam_acct_mgmt = 0 (Success) > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 103 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: Accepted password for > adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 ssh2 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: monitor_child_preauth: > adm-faru03 at test.osuwmc has been authenticated by privileged process > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Waiting > for new keys > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 26 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_from_blob: > 0x7f60fd62ff00(159) > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup > hmac-sha2-256 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Waiting > for second key > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_from_blob: > 0x7f60fd62ff00(159) > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup > hmac-sha2-256 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Getting > compression state > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Getting > Network I/O buffers > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 122 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 123 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password: user > authenticated [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_do_pam_account > entering [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 102 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 103 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_do_pam_account > returning 1 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: > Sending new keys: 0x7f60fd61fc90 0x7f60fd610a40 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_to_blob: > converting 0x7f60fd61fc90 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_to_blob: > converting 0x7f60fd610a40 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: New > keys have been sent [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: > Sending compression state [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 26 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: > Finished sending state [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 122 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > mm_request_receive_expect entering: type 123 [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering [preauth] > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: monitor_read_log: child > log fd closed > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_share_sync: Share sync > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_share_sync: Share > sync end > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > ssh_sandbox_parent_finish: finished > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: temporarily_use_uid: > 1398410/1398410 (e=0/0) > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: ssh_gssapi_storecreds: > Not a GSSAPI mechanism > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: restore_uid: 0/0 > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > sshd_selinux_setup_variables: setting execution context > Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: PAM: establishing > credentials > Mar 30 13:33:44 mid-ipa-vp01 sshd[13750]: debug3: PAM: opening session > Mar 30 13:33:45 mid-ipa-vp01 sshd[13750]: pam_unix(sshd:session): session > opened for user adm-faru03 at test.osuwmc by (uid=0) > Mar 30 13:33:46 mid-ipa-vp01 sshd[13750]: User child is on pid 13761 > Mar 30 13:33:46 mid-ipa-vp01 sshd[13761]: debug1: PAM: establishing > credentials > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: > sshd_selinux_setup_variables: setting execution context > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: permanently_set_uid: > 1398410/1398410 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: set_newkeys: mode 0 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: set_newkeys: mode 1 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: Entering interactive > session for SSH2. > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 10 setting O_NONBLOCK > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 11 setting O_NONBLOCK > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: server_init_dispatch_20 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: Received SSH2_MSG_IGNORE > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > server_input_channel_open: ctype session rchan 256 win 16384 max 16384 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: input_session_request > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: channel 0: new > [server-session] > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: session_new: allocate > (allocated 0 max 10) > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: session_unused: session > id 0 unused > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_new: session 0 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_open: channel 0 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_open: session 0: > link with channel 0 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > server_input_channel_open: confirm session > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > server_input_channel_req: channel 0 request pty-req reply 1 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_by_channel: > session 0 channel 0 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > session_input_channel_req: session 0 req pty-req > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: Allocating pty. > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_request_send > entering: type 28 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_pty_allocate: waiting > for MONITOR_ANS_PTY > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 28 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pty entering > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug2: session_new: allocate > (allocated 0 max 10) > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: session_unused: session > id 0 unused > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug1: session_new: session 0 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: > mm_request_receive_expect entering: type 29 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_request_receive > entering > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_setup_pty: > setting TTY context on /dev/pts/2 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_setup_pty: > done > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 29 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pty: tty > /dev/pts/2 ptyfd 5 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_pty_req: session > 0 alloc /dev/pts/2 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > server_input_channel_req: channel 0 request shell reply 1 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_by_channel: > session 0 channel 0 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > session_input_channel_req: session 0 req shell > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: Starting session: shell on pts/2 > for adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 3 setting TCP_NODELAY > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: packet_set_tos: set > IP_TOS 0x10 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: channel 0: rfd 14 isatty > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 14 setting O_NONBLOCK > Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: fd 12 is O_NONBLOCK > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug1: Setting controlling tty > using TIOCSCTTY. > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_send > entering: type 124 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: > mm_request_receive_expect entering: type 125 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > entering > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_receive > entering > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > request 124 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > entering: type 125 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > KRB5CCNAME=FILE:/tmp/krb5cc_1398410_B30vDK > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > SELINUX_ROLE_REQUESTED= > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > SELINUX_LEVEL_REQUESTED= > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > SELINUX_USE_CURRENT_RANGE= > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > XDG_SESSION_ID=10 > Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > XDG_RUNTIME_DIR=/run/user/1398410 > > Just in case, here is my krb5.conf > > includedir /var/lib/sss/pubconf/krb5.include.d/ > > [logging] > default = FILE:/var/log/krb5libs.log > kdc = FILE:/var/log/krb5kdc.log > admin_server = FILE:/var/log/kadmind.log > > [libdefaults] > default_realm = UNIX.TEST.OSUWMC > dns_lookup_realm = true > dns_lookup_kdc = true > rdns = false > ticket_lifetime = 24h > forwardable = yes > udp_preference_limit = 0 > # default_ccache_name = KEYRING:persistent:%{uid} > > [realms] > UNIX.TEST.OSUWMC = { > kdc = mid-ipa-vp01.unix.test.osuwmc:88 > master_kdc = mid-ipa-vp01.unix.test.osuwmc:88 > admin_server = mid-ipa-vp01.unix.test.osuwmc:749 > default_domain = unix.test.osuwmc > pkinit_anchors = FILE:/etc/ipa/ca.crt > # auth_to_local = > RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ > # auth_to_local = RULE:[1:$1 $0](^ * > TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ > auth_to_local = DEFAULT > } > > [domain_realm] > .unix.test.osuwmc = UNIX.TEST.OSUWMC > unix.test.osuwmc = UNIX.TEST.OSUWMC > > [dbmodules] > UNIX.TEST.OSUWMC = { > db_library = ipadb.so > } I'm not sure if this would be of any help to you, but in case you have GSSAPI credential delegation enabled in PuTTY, you also need to allow them to be delegated to the IPA server using: $ ipa host-mod --ok-as-delegate=1 Honza -- Jan Cholasta From pspacek at redhat.com Tue Mar 31 06:48:50 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 31 Mar 2015 08:48:50 +0200 Subject: [Freeipa-users] Can freeIPA work without Kerberos and DNS In-Reply-To: <5745FCE3-8685-4407-99DC-BECB5F4532E9@gmail.com> References: <5518AA63.5070403@redhat.com> <5519461C.2070801@redhat.com> <5745FCE3-8685-4407-99DC-BECB5F4532E9@gmail.com> Message-ID: <551A4352.9020403@redhat.com> On 30.3.2015 14:58, Gokulnath wrote: > Thanks for the update. > > The reason for weigh in the Kerberos option is to have that as an option to disable if needed, security is more important. I had to say this because there was a question on "why I would disable it". I would argue that by using plain LDAP with user+password combination or certificate-based login (private key) you are actually making things worse for scenarios where attacker can have access to memory from time to time. Password and private key are long-term secrets, i.e. are highly sensitive and in described case used for every authentication. In case of Kerberos, long-term secret is used only once to obtain session key (TGT or other ticket) and this session key has limited lifetime so stolen session key gives the attacker access only for a limited time. Anyway, this is just an academic discussion. Do not use cloud services if you are worried about this kind of attacks. Petr^2 Spacek > > I agree that the otp should definitely provide some additional layer of security. > > Let me test and reply back. > > Thanks again. > > Gokul > > Sent from iPhone > >> On Mar 30, 2015, at 7:48 AM, Dmitri Pal wrote: >> >>> On 03/29/2015 10:27 PM, Gokulnath wrote: >>> Thanks for getting back. >>> >>> 1. As security Kerberos can ticket and in memory can be taken and that session key >>> Can be used to gain access every where. Primarily this because the plan is to use the solution in cloud. >> >> You can use Kerberos in the cloud. It is not worse of better than certs. >> If you can read memory of a machine you can (potentially) read its keys. >> But this is the general risk that you take going into the cloud regardless whether you use PKI or Kerberos. >> >> In general you do not want to store long term keys in the images but rather add them on the fly when the system is instantiated. >> The ipa-client-install with OTP registration code provides this capability. >> >> It seems that you are trying to overcomplicate things with no obvious reason. >> If you need help with picking a better approach lest us know what exactly you are trying to accomplish. >> >>> >>> 2. Can I disable DNS as well? And have IPA to run only ldap, ssh key rotation and pki ? >>> >>> 3. As during the install, DNS and Kerberos are getting installed and configured. >>> >>> I would really appreciate if you can get back. >>> >>> Thank you >>> Gokul >>> Sent from iPhone >>> >>>>> On Mar 29, 2015, at 8:44 PM, Dmitri Pal wrote: >>>>> >>>>> On 03/29/2015 11:50 AM, Gokul wrote: >>>>> Hi, >>>>> >>>>> I am tried to run some of my user cases with FreeIPA. >>>>> >>>>> Have FreeIPA to do only SSH key management in LDAP and PKI management. >>>>> >>>>> The understand that every request is kerberized and it has the DNS is must configuration. >>>>> >>>>> Can I have FreeIPA to run only SSH Key management with LDAP and a PKI server with dogtag? >>>>> >>>>> Thank you >>>>> Gokul >>>> You can't turn off Kerberos. You would need Kerberos for administration. >>>> But other clients can take advantage of LDAP and SSH only. >>>> However you are significantly limiting your functionality and capabilities. >>>> Kerberos is really the key of the solution. >>>> >>>> What is the reason you try to avoid using it? From pspacek at redhat.com Tue Mar 31 06:50:21 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 31 Mar 2015 08:50:21 +0200 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: References: <20150330090934.GY10622@hendrix.redhat.com> Message-ID: <551A43AD.6010201@redhat.com> On 30.3.2015 11:23, Yogesh Sharma wrote: > Hi Jakub: > > FreeIPA package is not available in Amazon Linux running on EC2 Instance. > We tried to install individually packages but it is breaking at many place. BTW if you want FreeIPA support in Amazon Linux then please contact Amazon support and tell them about your request. It will make life easier for you and everyone else too (in long-term). Have a nice day! -- Petr^2 Spacek From pspacek at redhat.com Tue Mar 31 06:55:15 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 31 Mar 2015 08:55:15 +0200 Subject: [Freeipa-users] FreeIPA with Active directory Read-only domain controller trust setup In-Reply-To: <55197312.7030709@redhat.com> References: <55197312.7030709@redhat.com> Message-ID: <551A44D3.9080103@redhat.com> On 30.3.2015 18:00, Dmitri Pal wrote: > On 03/30/2015 11:12 AM, Srdjan Dutina wrote: >> Hi, >> >> I'm testing FreeIPA (v4.1.3, Centos 7) - AD (2012 R2) trust on branch site >> where only AD read-only domain controller (RODC) exists. >> I'm aware that for initial establishing of trust I need access to writable >> domain controller so IPA can add trust to AD domains and trusts. >> But after initial setup, can FreeIPA-AD trust continue to function with IPA >> access to RODC only? > > Should work. > >> Will Kerberos authentication of AD users on IPA domain hosts work? >> In this case, FreeIPA server should have DNS forward zone configured with >> RODC as a forwarder to AD? It should not matter as long as the forwarder knows how to resolve all the DNS names. General advice is to pick nearest server if you have access to it and add couple other servers to enable fail-over (if the nearest server fails for some reason). -- Petr^2 Spacek From abokovoy at redhat.com Tue Mar 31 07:05:32 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 31 Mar 2015 10:05:32 +0300 Subject: [Freeipa-users] FreeIPA with Active directory Read-only domain controller trust setup In-Reply-To: <551A44D3.9080103@redhat.com> References: <55197312.7030709@redhat.com> <551A44D3.9080103@redhat.com> Message-ID: <20150331070532.GM3878@redhat.com> On Tue, 31 Mar 2015, Petr Spacek wrote: >On 30.3.2015 18:00, Dmitri Pal wrote: >> On 03/30/2015 11:12 AM, Srdjan Dutina wrote: >>> Hi, >>> >>> I'm testing FreeIPA (v4.1.3, Centos 7) - AD (2012 R2) trust on branch site >>> where only AD read-only domain controller (RODC) exists. >>> I'm aware that for initial establishing of trust I need access to writable >>> domain controller so IPA can add trust to AD domains and trusts. >>> But after initial setup, can FreeIPA-AD trust continue to function with IPA >>> access to RODC only? >> >> Should work. >> >>> Will Kerberos authentication of AD users on IPA domain hosts work? >>> In this case, FreeIPA server should have DNS forward zone configured with >>> RODC as a forwarder to AD? > >It should not matter as long as the forwarder knows how to resolve all the DNS >names. General advice is to pick nearest server if you have access to it and >add couple other servers to enable fail-over (if the nearest server fails for >some reason). In general, user identity lookup for trusted AD users happens via IPA masters -- each IPA client would delegate lookup to IPA master and that one would use closest site discovered in AD to do the lookup. With authentication we are in a bit more complex situation. GSSAPI authentication assumes your Windows client comes already with a service ticket to an IPA client's service. The ticket is obtained by Windows client by first obtaining cross-realm TGT from AD DC and then using this TGT to ask for a service ticket from IPA master (KDC). The latter ticket is then presented to an IPA client's service. When AD user attempts to use their password directly, IPA client will be talking to a discovered AD DC to validate the password and authenticate the user. At this step discovery of AD DC for Kerberos purposes is not done based on site locality, SSSD still has some open ticket to do that if I remember correctly. -- / Alexander Bokovoy From sbose at redhat.com Tue Mar 31 07:30:47 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 31 Mar 2015 09:30:47 +0200 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: <551A3725.10602@redhat.com> References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> <20150330150829.GR4696@redhat.com> <5519723D.5060704@redhat.com> <551A3725.10602@redhat.com> Message-ID: <20150331073047.GG8895@p.redhat.com> On Tue, Mar 31, 2015 at 07:56:53AM +0200, Jan Cholasta wrote: > Hi, > > Dne 30.3.2015 v 19:42 Gould, Joshua napsal(a): > > > >On 3/30/15, 11:56 AM, "Dmitri Pal" wrote: > > > >>># auth_to_local = > >>>RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ > >>> auth_to_local = RULE:[1:$1 $0](^ * > >>>TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ > >>If you use the plugin then this RULE should not be needed. > >>Have you tried commenting it out and restarting SSSD? > > > >I commented out those lines and restarted SSSD. I still was not able to > >get in with SSO. > > > >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: fd 5 is not O_NONBLOCK > >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug1: Forked child 13750. > >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: send_rexec_state: > >entering fd = 8 config len 899 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: ssh_msg_send: type 0 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[12789]: debug3: send_rexec_state: done > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: oom_adjust_restore > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: Set /proc/self/oom_score_adj to 0 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: rexec start in 5 out 5 > >newsock 5 pipe 7 sock 8 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: inetd sockets after > >dupping: 3, 3 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: Connection from 10.80.5.239 port > >65333 on 10.127.26.73 port 22 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Client protocol version > >2.0; client software version PuTTY_Release_0.64 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: no match: > >PuTTY_Release_0.64 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Enabling compatibility > >mode for protocol 2.0 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: Local version string > >SSH-2.0-OpenSSH_6.6.1 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: fd 3 setting O_NONBLOCK > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: ssh_sandbox_init: > >preparing rlimit sandbox > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: Network child is on pid > >13751 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: preauth child monitor > >started > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > >ssh_selinux_change_context: setting context from > >'system_u:system_r:sshd_t:s0-s0:c0.c1023' to 'system_u: > >system_r:sshd_net_t:s0-s0:c0.c1023' [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: privsep user:group 74:74 > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: permanently_set_uid: > >74/74 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: list_hostkey_types: > >ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEXINIT sent > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_KEXINIT > >received [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >curve25519-sha256 at libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha > >2-nistp521 > >,diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,di > >ffie-hellman-group14-sha1,diffie-hellman-group1-sha1 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >ssh-rsa,ecdsa-sha2-nistp256,ssh-ed25519 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c > >om,aes256- > >gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish- > >cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > >[prea > >uth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >aes128-ctr,aes192-ctr,aes256-ctr,arcfour256,arcfour128,aes128-gcm at openssh.c > >om,aes256- > >gcm at openssh.com,chacha20-poly1305 at openssh.com,aes128-cbc,3des-cbc,blowfish- > >cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc at lysator.liu.se > >[prea > >uth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, > >umac-128-e > >tm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, > >hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm > >@ope > >nssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-s > >ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > >6,hm > >ac-md5-96 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >hmac-md5-etm at openssh.com,hmac-sha1-etm at openssh.com,umac-64-etm at openssh.com, > >umac-128-e > >tm at openssh.com,hmac-sha2-256-etm at openssh.com,hmac-sha2-512-etm at openssh.com, > >hmac-ripemd160-etm at openssh.com,hmac-sha1-96-etm at openssh.com,hmac-md5-96-etm > >@ope > >nssh.com,hmac-md5,hmac-sha1,umac-64 at openssh.com,umac-128 at openssh.com,hmac-s > >ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160 at openssh.com,hmac-sha1-9 > >6,hm > >ac-md5-96 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >none,zlib at openssh.com [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >none,zlib at openssh.com [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >first_kex_follows 0 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >reserved 0 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >diffie-hellman-group-exchange-sha256,diffie-hellman-group-exchange-sha1,dif > >fie-hellman-group14-sha1,diffie-hellman-group1-sha1,rsa2048-sha256,rsa1024- > >sha1 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >ssh-rsa,ssh-dss [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes > >128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a > >rcfour128 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >aes256-ctr,aes256-cbc,rijndael-cbc at lysator.liu.se,aes192-ctr,aes192-cbc,aes > >128-ctr,aes128-cbc,blowfish-ctr,blowfish-cbc,3des-ctr,3des-cbc,arcfour256,a > >rcfour128 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >hmac-sha2-256,hmac-sha1,hmac-sha1-96,hmac-md5 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >none,zlib [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >none,zlib [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >first_kex_follows 0 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: > >reserved 0 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup > >hmac-sha2-256 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: client->server > >aes256-ctr hmac-sha2-256 none [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup > >hmac-sha2-256 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: server->client > >aes256-ctr hmac-sha2-256 none [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: > >diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 120 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 121 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 120 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 121 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: kex: > >diffie-hellman-group-exchange-sha256 need=32 dh_need=32 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 120 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 121 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 120 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 121 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: > >SSH2_MSG_KEX_DH_GEX_REQUEST_OLD received [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 0 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_choose_dh: waiting > >for MONITOR_ANS_MODULI [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 1 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 0 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_moduli: got > >parameters: 1024 4096 8192 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 1 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 0 used > >once, disabling now > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_choose_dh: remaining > >0 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: > >SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: bits set: 2013/4096 > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: expecting > >SSH2_MSG_KEX_DH_GEX_INIT [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: bits set: 2017/4096 > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_key_sign entering > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 6 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_key_sign: waiting for > >MONITOR_ANS_SIGN [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 7 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 6 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_sign > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_sign: > >signature 0x7f60fd611d20(271) > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 7 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 6 used > >once, disabling now > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: > >SSH2_MSG_KEX_DH_GEX_REPLY sent [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_derive_keys [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: set_newkeys: mode 1 > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_NEWKEYS sent > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: expecting > >SSH2_MSG_NEWKEYS [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: set_newkeys: mode 0 > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: SSH2_MSG_NEWKEYS > >received [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: KEX done [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for > >user adm-faru03 at test.osuwmc service ssh-connection method none [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug1: attempt 0 failures 0 > >[preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_getpwnamallow > >entering [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 8 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_getpwnamallow: > >waiting for MONITOR_ANS_PWNAM [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 9 [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 8 > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pwnamallow > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug3: Trying to reverse map > >address 10.80.5.239. > >Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: parse_server_config: > >config reprocess config len 899 > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pwnamallow: > >sending MONITOR_ANS_PWNAM: 1 > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 9 > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 8 used > >once, disabling now > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: > >setting up authctxt for adm-faru03 at test.osuwmc [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_start_pam entering > >[preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 100 [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_inform_authserv > >entering [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 4 [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_inform_authrole > >entering [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 80 [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: > >try method none [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: userauth_finish: failure > >partial=0 next methods="publickey,gssapi-keyex,gssapi-with-mic,password" > >[preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 100 > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: initializing for > >"adm-faru03 at test.osuwmc" > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: setting PAM_RHOST > >to "svr-addc-vt01.test.osuwmc" > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: PAM: setting PAM_TTY to > >"ssh" > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 100 used > >once, disabling now > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for > >user adm-faru03 at test.osuwmc service ssh-connection method gssapi-with-mic > >[preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug1: attempt 1 failures 0 > >[preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: > >try method gssapi-with-mic [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 42 [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 43 [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 4 > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authserv: > >service=ssh-connection, style= > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 4 used > >once, disabling now > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 80 > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authrole: role= > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug2: monitor_read: 80 used > >once, disabling now > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 42 > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 43 > >Mar 30 13:33:36 mid-ipa-vp01 sshd[13750]: Postponed gssapi-with-mic for > >adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 ssh2 [preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug1: userauth-request for > >user adm-faru03 at test.osuwmc service ssh-connection method password > >[preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug1: attempt 2 failures 0 > >[preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug2: input_userauth_request: > >try method password [preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password > >entering [preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 12 [preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password: > >waiting for MONITOR_ANS_AUTHPASSWORD [preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 13 [preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 12 > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: debug3: PAM: sshpam_passwd_conv > >called with 1 messages > >Mar 30 13:33:39 mid-ipa-vp01 sshd[13750]: pam_unix(sshd:auth): > >authentication failure; logname= uid=0 euid=0 tty=ssh ruser= > >rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc > >Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: pam_sss(sshd:auth): > >authentication success; logname= uid=0 euid=0 tty=ssh ruser= > >rhost=svr-addc-vt01.test.osuwmc user=adm-faru03 at test.osuwmc > >Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug1: PAM: password > >authentication accepted for adm-faru03 at test.osuwmc > >Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_authpassword: > >sending result 1 > >Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 13 > >Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 102 > >Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:40 mid-ipa-vp01 sshd[13750]: debug1: do_pam_account: called > >Mar 30 13:33:42 mid-ipa-vp01 sshd[13719]: debug1: > >server_input_global_request: rtype keepalive at openssh.com want_reply 1 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: PAM: do_pam_account > >pam_acct_mgmt = 0 (Success) > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 103 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: Accepted password for > >adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 ssh2 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: monitor_child_preauth: > >adm-faru03 at test.osuwmc has been authenticated by privileged process > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Waiting > >for new keys > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 26 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_from_blob: > >0x7f60fd62ff00(159) > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup > >hmac-sha2-256 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Waiting > >for second key > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_from_blob: > >0x7f60fd62ff00(159) > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug2: mac_setup: setup > >hmac-sha2-256 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Getting > >compression state > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_get_keystate: Getting > >Network I/O buffers > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 122 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 123 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_auth_password: user > >authenticated [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_do_pam_account > >entering [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 102 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 103 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_do_pam_account > >returning 1 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: > >Sending new keys: 0x7f60fd61fc90 0x7f60fd610a40 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_to_blob: > >converting 0x7f60fd61fc90 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_newkeys_to_blob: > >converting 0x7f60fd610a40 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: New > >keys have been sent [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: > >Sending compression state [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 26 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_send_keystate: > >Finished sending state [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 122 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > >mm_request_receive_expect entering: type 123 [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering [preauth] > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: monitor_read_log: child > >log fd closed > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_share_sync: Share sync > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: mm_share_sync: Share > >sync end > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > >ssh_sandbox_parent_finish: finished > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: temporarily_use_uid: > >1398410/1398410 (e=0/0) > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: ssh_gssapi_storecreds: > >Not a GSSAPI mechanism > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: restore_uid: 0/0 > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug3: > >sshd_selinux_setup_variables: setting execution context > >Mar 30 13:33:43 mid-ipa-vp01 sshd[13750]: debug1: PAM: establishing > >credentials > >Mar 30 13:33:44 mid-ipa-vp01 sshd[13750]: debug3: PAM: opening session > >Mar 30 13:33:45 mid-ipa-vp01 sshd[13750]: pam_unix(sshd:session): session > >opened for user adm-faru03 at test.osuwmc by (uid=0) > >Mar 30 13:33:46 mid-ipa-vp01 sshd[13750]: User child is on pid 13761 > >Mar 30 13:33:46 mid-ipa-vp01 sshd[13761]: debug1: PAM: establishing > >credentials > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: > >sshd_selinux_setup_variables: setting execution context > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: permanently_set_uid: > >1398410/1398410 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: set_newkeys: mode 0 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: set_newkeys: mode 1 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: Entering interactive > >session for SSH2. > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 10 setting O_NONBLOCK > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 11 setting O_NONBLOCK > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: server_init_dispatch_20 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: Received SSH2_MSG_IGNORE > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > >server_input_channel_open: ctype session rchan 256 win 16384 max 16384 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: input_session_request > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: channel 0: new > >[server-session] > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: session_new: allocate > >(allocated 0 max 10) > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: session_unused: session > >id 0 unused > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_new: session 0 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_open: channel 0 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_open: session 0: > >link with channel 0 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > >server_input_channel_open: confirm session > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > >server_input_channel_req: channel 0 request pty-req reply 1 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_by_channel: > >session 0 channel 0 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > >session_input_channel_req: session 0 req pty-req > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: Allocating pty. > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_request_send > >entering: type 28 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_pty_allocate: waiting > >for MONITOR_ANS_PTY > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 28 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pty entering > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug2: session_new: allocate > >(allocated 0 max 10) > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: session_unused: session > >id 0 unused > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug1: session_new: session 0 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: > >mm_request_receive_expect entering: type 29 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: mm_request_receive > >entering > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug1: SELinux support enabled > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_setup_pty: > >setting TTY context on /dev/pts/2 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: ssh_selinux_setup_pty: > >done > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 29 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_answer_pty: tty > >/dev/pts/2 ptyfd 5 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_pty_req: session > >0 alloc /dev/pts/2 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > >server_input_channel_req: channel 0 request shell reply 1 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: session_by_channel: > >session 0 channel 0 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug1: > >session_input_channel_req: session 0 req shell > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: Starting session: shell on pts/2 > >for adm-faru03 at test.osuwmc from 10.80.5.239 port 65333 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 3 setting TCP_NODELAY > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: packet_set_tos: set > >IP_TOS 0x10 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: channel 0: rfd 14 isatty > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug2: fd 14 setting O_NONBLOCK > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13761]: debug3: fd 12 is O_NONBLOCK > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug1: Setting controlling tty > >using TIOCSCTTY. > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_send > >entering: type 124 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: > >mm_request_receive_expect entering: type 125 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_receive > >entering > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: mm_request_receive > >entering > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: monitor_read: checking > >request 124 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13750]: debug3: mm_request_send > >entering: type 125 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > >KRB5CCNAME=FILE:/tmp/krb5cc_1398410_B30vDK > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > >SELINUX_ROLE_REQUESTED= > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > >SELINUX_LEVEL_REQUESTED= > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > >SELINUX_USE_CURRENT_RANGE= > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > >XDG_SESSION_ID=10 > >Mar 30 13:33:47 mid-ipa-vp01 sshd[13762]: debug3: Copy environment: > >XDG_RUNTIME_DIR=/run/user/1398410 > > > >Just in case, here is my krb5.conf > > > >includedir /var/lib/sss/pubconf/krb5.include.d/ > > > >[logging] > > default = FILE:/var/log/krb5libs.log > > kdc = FILE:/var/log/krb5kdc.log > > admin_server = FILE:/var/log/kadmind.log > > > >[libdefaults] > > default_realm = UNIX.TEST.OSUWMC > > dns_lookup_realm = true > > dns_lookup_kdc = true > > rdns = false > > ticket_lifetime = 24h > > forwardable = yes > > udp_preference_limit = 0 > ># default_ccache_name = KEYRING:persistent:%{uid} > > > >[realms] > > UNIX.TEST.OSUWMC = { > > kdc = mid-ipa-vp01.unix.test.osuwmc:88 > > master_kdc = mid-ipa-vp01.unix.test.osuwmc:88 > > admin_server = mid-ipa-vp01.unix.test.osuwmc:749 > > default_domain = unix.test.osuwmc > > pkinit_anchors = FILE:/etc/ipa/ca.crt > ># auth_to_local = > >RULE:[1:$1@$0](^.*@TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ > ># auth_to_local = RULE:[1:$1 $0](^ * > >TEST.OSUWMC$)s/@TEST.OSUWMC/@test.osuwmc/ > > auth_to_local = DEFAULT > >} > > > >[domain_realm] > > .unix.test.osuwmc = UNIX.TEST.OSUWMC > > unix.test.osuwmc = UNIX.TEST.OSUWMC > > > >[dbmodules] > > UNIX.TEST.OSUWMC = { > > db_library = ipadb.so > > } > > I'm not sure if this would be of any help to you, but in case you have > GSSAPI credential delegation enabled in PuTTY, you also need to allow them > to be delegated to the IPA server using: > > $ ipa host-mod --ok-as-delegate=1 This is only needed if you want that your Kerberos credentials (the TGT) are forwarded from the Windows client to the IPA client so that you can use them to access kerberized services from the IPA client as well without the need to call kinit. This is not needed for authentication because here only the service ticket is send to the IPA client and not the TGT. Can you do the follwoing checks: Can you check by calling klist in a Windows Command window if you got a proper host/... ticket for the IPA host? What version of IPA and SSSD are you using. Can you check if the following works on a IPA host: kinit adm-faru03 at TEST.OSUWMC kvno host/name.of.the.ipa-client.to.login at IPA.REALM ssh -v -l adm-faru03 at test.osuwmc name.of.the.ipa-client.to.login The error messages return by the ssh -v output might help to see why GSSAPI auth failed. bye, Sumit > > Honza > > -- > Jan Cholasta > > -- > 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 yks0000 at gmail.com Tue Mar 31 07:54:29 2015 From: yks0000 at gmail.com (Yogesh Sharma) Date: Tue, 31 Mar 2015 13:24:29 +0530 Subject: [Freeipa-users] IPA Client using Source Code In-Reply-To: <551A43AD.6010201@redhat.com> References: <20150330090934.GY10622@hendrix.redhat.com> <551A43AD.6010201@redhat.com> Message-ID: Yes Petr. Support Case has already been opened with them. *Best Regards,__________________________________________* *Yogesh Sharma* *Email: yks0000 at gmail.com | Web: www.initd.in * RHCE, VCE-CIA, RackSpace Cloud U [image: My LinkedIn Profile] On Tue, Mar 31, 2015 at 12:20 PM, Petr Spacek wrote: > On 30.3.2015 11:23, Yogesh Sharma wrote: > > Hi Jakub: > > > > FreeIPA package is not available in Amazon Linux running on EC2 Instance. > > We tried to install individually packages but it is breaking at many > place. > > BTW if you want FreeIPA support in Amazon Linux then please contact Amazon > support and tell them about your request. It will make life easier for you > and > everyone else too (in long-term). > > Have a nice day! > > -- > Petr^2 Spacek > > -- > 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 prasun.gera at gmail.com Tue Mar 31 08:08:55 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 31 Mar 2015 04:08:55 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: <5515C3DF.5020701@redhat.com> References: <55148136.8040003@redhat.com> <5514C804.4040207@redhat.com> <55156455.7090401@redhat.com> <5515C3DF.5020701@redhat.com> Message-ID: > The idea is that you tel lall the users to either login via migration page > or via SSSD. > If your server is in a migration mode the migration page should be > available and SSSD should detect that server is in migration mode. > In this case any authentication via SSSD will end up creating proper > hashes for Kerberos. I suspect this is when the conversion of the LDAP > hashes happens too. > You suggested that this is not the case but I am not sure that the test > was 100 correct. > > Please try: > - check that migration mode is on > - check that user does not have kerberos password only LDAP hash from NIS > migration > - ssh into a box that runs SSSD with such user, authenticate > As a result you should see Kerberos hash created for this user and I > suspect the LDAP hash is converted at the same time. > > I verified all the steps, and I can confirm that SSSD does not migrate users automatically. I see the following in /var/log/secure, which confirms that sssd is indeed authenticating the user Mar 31 03:50:47 ipaserver sshd[23531]: Accepted password for testuser2 from ip port 43622 ssh2 Mar 31 03:50:47 ipaserver sshd[23531]: pam_unix(sshd:session): session opened for user testuser2 by (uid=0) ipa user-show testuser2 still shows Kerberos keys available: False sssd's logs also show successful authentication. I think this sounds reasonable (and possibly intentional?) since the alternative would make staged migration impossible. As soon as one client is migrated, all other clients would lose the ability to authenticate with NIS. The way it is behaving right now is actually preferable. i.e. No automatic migration until done explicitly by user/admin. Coming back to the original issue, I deleted those accidentally migrated users and added them again, and I haven't seen any anomalous behaviour since. i.e Their cypt hashes are visible to NIS clients. I can only guess that whatever triggered it in the first place was a one-off event. Could yum update be responsible ? All the free ipa packages were updated last week to the latest point release. In any case, I think it is behaving well for now, and hope it stays that way. Minor question: Our NIS maps had separate shadow maps originally, which provided some mild security since they can't be accessed by unprivileged users/ports. Is it possible to do that with the NIS plugin in IPA ? -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Tue Mar 31 09:02:24 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 11:02:24 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: References: <5518AB6D.1020606@redhat.com> <20150330130324.GB8895@p.redhat.com> Message-ID: On my client I still see: 03/31/2015 11:00:08 04/01/2015 11:00:07 krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL 03/31/2015 11:00:09 04/01/2015 11:00:07 HTTP/ldap-01.domain.local at DOMAIN.LOCAL Should ldap-01 not be ldap as I go through my loadbalancer ? Do I need to merge keytabs or so ? 2015-03-31 7:54 GMT+02:00 Matt . : > Hi, > > I tried to trace some stuff but this doesn't give me much more info. > > What I see at the moment in the /var/log/httpd/acces_log is exactly > what happens but without the info I need to get a better view: > > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 258 > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" > 301 259 "https://ldap.domain.local/ipa/json" "-" > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 401 1469 > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 401 1469 > > 2015-03-30 15:03 GMT+02:00 Sumit Bose : >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote: >>> Hi, >>> >>> I just tot home and typing from my cell so i'm suite short in words >>> >>> Create keytab for ldap-01.domain >>> Kinit with that to ldap.domain >>> Curl against ldap.domain >>> Get a 301 which I manage from curl (goes well) >>> Get kerberos ticket error >>> >>> now I don't kinit anymore so re-use my existing ticket and curl against >>> ldap-01.domain and I'm accepted and can execute stuff. >>> >>> My ssl is OK, ticket also it seems. >> >> Maybe the output of >> >> KRB5_TRACE=/dev/sdtout curl -v .... >> >> might help to see what is going on? >> >> bye, >> Sumit >> >>> >>> Thanks M. >>> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : >>> >>> > On 03/29/2015 04:47 AM, Matt . wrote: >>> > >>> >> Hi Guys, >>> >> >>> >> Now my Certification issues are solved for using a loadbalancer in >>> >> front of my ipa servers I get the following: >>> >> >>> >> Unable to verify your Kerberos credentials >>> >> >>> >> and in my logs: >>> >> >>> >> Additional pre-authentication required. >>> >> >>> >> This happens when I connect throught my loadbalancers, I see my server >>> >> coming ni with the right IP. >>> >> >>> >> When I access my ipa server directly, not using the loadbalancer IP >>> >> between it, my kerberos Ticket is valid. >>> >> >>> >> I get the feeling that when I use my loadbalancers and because of that >>> >> I get a 301 redirect it needs a preauth. I see some issues on >>> >> mailinglists but it doesn't fit my situation. >>> >> >>> >> Why wants it the preauth when I already have a valid ticket and my >>> >> redirect is followed by CURL and posted the right way ? >>> >> >>> > >>> > Can you describe the sequence? >>> > What do you do? >>> > >>> > From the client you try IPA CLI and this is where you see the problem even >>> > with the valid ticket or is the flow different? >>> > >>> > I hope someone has an idea. >>> >> >>> >> Thanks, >>> >> >>> >> Matt >>> >> >>> >> >>> > >>> > -- >>> > 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 >>> > >> >>> -- >>> 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 sbose at redhat.com Tue Mar 31 09:09:43 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 31 Mar 2015 11:09:43 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: References: <5518AB6D.1020606@redhat.com> <20150330130324.GB8895@p.redhat.com> Message-ID: <20150331090943.GJ8895@p.redhat.com> On Tue, Mar 31, 2015 at 11:02:24AM +0200, Matt . wrote: > On my client I still see: > > 03/31/2015 11:00:08 04/01/2015 11:00:07 krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL > 03/31/2015 11:00:09 04/01/2015 11:00:07 HTTP/ldap-01.domain.local at DOMAIN.LOCAL > > Should ldap-01 not be ldap as I go through my loadbalancer ? I guess not, because your loadbalancer just redirects the traffic and the authentication is done with ldap-01. bye, Sumit > > Do I need to merge keytabs or so ? > > 2015-03-31 7:54 GMT+02:00 Matt . : > > Hi, > > > > I tried to trace some stuff but this doesn't give me much more info. > > > > What I see at the moment in the /var/log/httpd/acces_log is exactly > > what happens but without the info I need to get a better view: > > > > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 258 > > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" > > 301 259 "https://ldap.domain.local/ipa/json" "-" > > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 401 1469 > > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 401 1469 > > > > 2015-03-30 15:03 GMT+02:00 Sumit Bose : > >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote: > >>> Hi, > >>> > >>> I just tot home and typing from my cell so i'm suite short in words > >>> > >>> Create keytab for ldap-01.domain > >>> Kinit with that to ldap.domain > >>> Curl against ldap.domain > >>> Get a 301 which I manage from curl (goes well) > >>> Get kerberos ticket error > >>> > >>> now I don't kinit anymore so re-use my existing ticket and curl against > >>> ldap-01.domain and I'm accepted and can execute stuff. > >>> > >>> My ssl is OK, ticket also it seems. > >> > >> Maybe the output of > >> > >> KRB5_TRACE=/dev/sdtout curl -v .... > >> > >> might help to see what is going on? > >> > >> bye, > >> Sumit > >> > >>> > >>> Thanks M. > >>> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : > >>> > >>> > On 03/29/2015 04:47 AM, Matt . wrote: > >>> > > >>> >> Hi Guys, > >>> >> > >>> >> Now my Certification issues are solved for using a loadbalancer in > >>> >> front of my ipa servers I get the following: > >>> >> > >>> >> Unable to verify your Kerberos credentials > >>> >> > >>> >> and in my logs: > >>> >> > >>> >> Additional pre-authentication required. > >>> >> > >>> >> This happens when I connect throught my loadbalancers, I see my server > >>> >> coming ni with the right IP. > >>> >> > >>> >> When I access my ipa server directly, not using the loadbalancer IP > >>> >> between it, my kerberos Ticket is valid. > >>> >> > >>> >> I get the feeling that when I use my loadbalancers and because of that > >>> >> I get a 301 redirect it needs a preauth. I see some issues on > >>> >> mailinglists but it doesn't fit my situation. > >>> >> > >>> >> Why wants it the preauth when I already have a valid ticket and my > >>> >> redirect is followed by CURL and posted the right way ? > >>> >> > >>> > > >>> > Can you describe the sequence? > >>> > What do you do? > >>> > > >>> > From the client you try IPA CLI and this is where you see the problem even > >>> > with the valid ticket or is the flow different? > >>> > > >>> > I hope someone has an idea. > >>> >> > >>> >> Thanks, > >>> >> > >>> >> Matt > >>> >> > >>> >> > >>> > > >>> > -- > >>> > 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 > >>> > > >> > >>> -- > >>> 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 yamakasi.014 at gmail.com Tue Mar 31 09:15:12 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 11:15:12 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: <20150331090943.GJ8895@p.redhat.com> References: <5518AB6D.1020606@redhat.com> <20150330130324.GB8895@p.redhat.com> <20150331090943.GJ8895@p.redhat.com> Message-ID: Yes I would assume too, but it's just kicking out possibilities what could make it not working. I cannot figure out why it only logs the 401 after the known 301's in the access_log and nothing further, apache really blocks, so kerberos should be in the way for sure, but how. 2015-03-31 11:09 GMT+02:00 Sumit Bose : > On Tue, Mar 31, 2015 at 11:02:24AM +0200, Matt . wrote: >> On my client I still see: >> >> 03/31/2015 11:00:08 04/01/2015 11:00:07 krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL >> 03/31/2015 11:00:09 04/01/2015 11:00:07 HTTP/ldap-01.domain.local at DOMAIN.LOCAL >> >> Should ldap-01 not be ldap as I go through my loadbalancer ? > > I guess not, because your loadbalancer just redirects the traffic and > the authentication is done with ldap-01. > > bye, > Sumit > >> >> Do I need to merge keytabs or so ? >> >> 2015-03-31 7:54 GMT+02:00 Matt . : >> > Hi, >> > >> > I tried to trace some stuff but this doesn't give me much more info. >> > >> > What I see at the moment in the /var/log/httpd/acces_log is exactly >> > what happens but without the info I need to get a better view: >> > >> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 258 >> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" >> > 301 259 "https://ldap.domain.local/ipa/json" "-" >> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 401 1469 >> > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 401 1469 >> > >> > 2015-03-30 15:03 GMT+02:00 Sumit Bose : >> >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote: >> >>> Hi, >> >>> >> >>> I just tot home and typing from my cell so i'm suite short in words >> >>> >> >>> Create keytab for ldap-01.domain >> >>> Kinit with that to ldap.domain >> >>> Curl against ldap.domain >> >>> Get a 301 which I manage from curl (goes well) >> >>> Get kerberos ticket error >> >>> >> >>> now I don't kinit anymore so re-use my existing ticket and curl against >> >>> ldap-01.domain and I'm accepted and can execute stuff. >> >>> >> >>> My ssl is OK, ticket also it seems. >> >> >> >> Maybe the output of >> >> >> >> KRB5_TRACE=/dev/sdtout curl -v .... >> >> >> >> might help to see what is going on? >> >> >> >> bye, >> >> Sumit >> >> >> >>> >> >>> Thanks M. >> >>> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : >> >>> >> >>> > On 03/29/2015 04:47 AM, Matt . wrote: >> >>> > >> >>> >> Hi Guys, >> >>> >> >> >>> >> Now my Certification issues are solved for using a loadbalancer in >> >>> >> front of my ipa servers I get the following: >> >>> >> >> >>> >> Unable to verify your Kerberos credentials >> >>> >> >> >>> >> and in my logs: >> >>> >> >> >>> >> Additional pre-authentication required. >> >>> >> >> >>> >> This happens when I connect throught my loadbalancers, I see my server >> >>> >> coming ni with the right IP. >> >>> >> >> >>> >> When I access my ipa server directly, not using the loadbalancer IP >> >>> >> between it, my kerberos Ticket is valid. >> >>> >> >> >>> >> I get the feeling that when I use my loadbalancers and because of that >> >>> >> I get a 301 redirect it needs a preauth. I see some issues on >> >>> >> mailinglists but it doesn't fit my situation. >> >>> >> >> >>> >> Why wants it the preauth when I already have a valid ticket and my >> >>> >> redirect is followed by CURL and posted the right way ? >> >>> >> >> >>> > >> >>> > Can you describe the sequence? >> >>> > What do you do? >> >>> > >> >>> > From the client you try IPA CLI and this is where you see the problem even >> >>> > with the valid ticket or is the flow different? >> >>> > >> >>> > I hope someone has an idea. >> >>> >> >> >>> >> Thanks, >> >>> >> >> >>> >> Matt >> >>> >> >> >>> >> >> >>> > >> >>> > -- >> >>> > 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 >> >>> > >> >> >> >>> -- >> >>> 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 benoit.rousselle at gmail.com Tue Mar 31 09:26:53 2015 From: benoit.rousselle at gmail.com (Benoit Rousselle) Date: Tue, 31 Mar 2015 11:26:53 +0200 Subject: [Freeipa-users] generic failure: GSSAPI Error: Unspecified GSS failure Message-ID: hi, I try to set the sudo password but I get a message : GSSAPI Error What's mean this kind of message ? ldappasswd -Y GSSAPI -S -h my_server uid=sudo,cn=sysaccounts,cn=etc,dc=my_domain,dc=com New password: Re-enter new password: SASL/GSSAPI authentication started ldap_sasl_interactive_bind_s: Local error (-2) additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS failure. Minor code may provide more information (Ticket expired) -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Tue Mar 31 09:38:30 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 11:38:30 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: References: <5518AB6D.1020606@redhat.com> <20150330130324.GB8895@p.redhat.com> <20150331090943.GJ8895@p.redhat.com> Message-ID: Here some extra logging from the kerberos log: Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.10.0.121: NEEDED_PREAUTH: kinituser at DOMAIN.LOCAL for krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL, Additional pre-authentication required Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6 etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491, etypes {rep=18 tkt=18 ses=18}, kinituser at DOMAIN.LOCAL for krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): TGS_REQ (6 etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491, etypes {rep=18 tkt=18 ses=18}, kinituser at DOMAIN.LOCAL for HTTP/ldap-01.domain.local at DOMAIN.LOCAL I don't get the preauth needed, does it have anything todo with the 301 redirect which I follow with CURL ? 2015-03-31 11:15 GMT+02:00 Matt . : > Yes I would assume too, but it's just kicking out possibilities what > could make it not working. > > I cannot figure out why it only logs the 401 after the known 301's in > the access_log and nothing further, apache really blocks, so kerberos > should be in the way for sure, but how. > > > > 2015-03-31 11:09 GMT+02:00 Sumit Bose : >> On Tue, Mar 31, 2015 at 11:02:24AM +0200, Matt . wrote: >>> On my client I still see: >>> >>> 03/31/2015 11:00:08 04/01/2015 11:00:07 krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL >>> 03/31/2015 11:00:09 04/01/2015 11:00:07 HTTP/ldap-01.domain.local at DOMAIN.LOCAL >>> >>> Should ldap-01 not be ldap as I go through my loadbalancer ? >> >> I guess not, because your loadbalancer just redirects the traffic and >> the authentication is done with ldap-01. >> >> bye, >> Sumit >> >>> >>> Do I need to merge keytabs or so ? >>> >>> 2015-03-31 7:54 GMT+02:00 Matt . : >>> > Hi, >>> > >>> > I tried to trace some stuff but this doesn't give me much more info. >>> > >>> > What I see at the moment in the /var/log/httpd/acces_log is exactly >>> > what happens but without the info I need to get a better view: >>> > >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 258 >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" >>> > 301 259 "https://ldap.domain.local/ipa/json" "-" >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 401 1469 >>> > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 401 1469 >>> > >>> > 2015-03-30 15:03 GMT+02:00 Sumit Bose : >>> >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote: >>> >>> Hi, >>> >>> >>> >>> I just tot home and typing from my cell so i'm suite short in words >>> >>> >>> >>> Create keytab for ldap-01.domain >>> >>> Kinit with that to ldap.domain >>> >>> Curl against ldap.domain >>> >>> Get a 301 which I manage from curl (goes well) >>> >>> Get kerberos ticket error >>> >>> >>> >>> now I don't kinit anymore so re-use my existing ticket and curl against >>> >>> ldap-01.domain and I'm accepted and can execute stuff. >>> >>> >>> >>> My ssl is OK, ticket also it seems. >>> >> >>> >> Maybe the output of >>> >> >>> >> KRB5_TRACE=/dev/sdtout curl -v .... >>> >> >>> >> might help to see what is going on? >>> >> >>> >> bye, >>> >> Sumit >>> >> >>> >>> >>> >>> Thanks M. >>> >>> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : >>> >>> >>> >>> > On 03/29/2015 04:47 AM, Matt . wrote: >>> >>> > >>> >>> >> Hi Guys, >>> >>> >> >>> >>> >> Now my Certification issues are solved for using a loadbalancer in >>> >>> >> front of my ipa servers I get the following: >>> >>> >> >>> >>> >> Unable to verify your Kerberos credentials >>> >>> >> >>> >>> >> and in my logs: >>> >>> >> >>> >>> >> Additional pre-authentication required. >>> >>> >> >>> >>> >> This happens when I connect throught my loadbalancers, I see my server >>> >>> >> coming ni with the right IP. >>> >>> >> >>> >>> >> When I access my ipa server directly, not using the loadbalancer IP >>> >>> >> between it, my kerberos Ticket is valid. >>> >>> >> >>> >>> >> I get the feeling that when I use my loadbalancers and because of that >>> >>> >> I get a 301 redirect it needs a preauth. I see some issues on >>> >>> >> mailinglists but it doesn't fit my situation. >>> >>> >> >>> >>> >> Why wants it the preauth when I already have a valid ticket and my >>> >>> >> redirect is followed by CURL and posted the right way ? >>> >>> >> >>> >>> > >>> >>> > Can you describe the sequence? >>> >>> > What do you do? >>> >>> > >>> >>> > From the client you try IPA CLI and this is where you see the problem even >>> >>> > with the valid ticket or is the flow different? >>> >>> > >>> >>> > I hope someone has an idea. >>> >>> >> >>> >>> >> Thanks, >>> >>> >> >>> >>> >> Matt >>> >>> >> >>> >>> >> >>> >>> > >>> >>> > -- >>> >>> > 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 >>> >>> > >>> >> >>> >>> -- >>> >>> 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 sbose at redhat.com Tue Mar 31 09:54:06 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 31 Mar 2015 11:54:06 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: References: <5518AB6D.1020606@redhat.com> <20150330130324.GB8895@p.redhat.com> <20150331090943.GJ8895@p.redhat.com> Message-ID: <20150331095406.GK8895@p.redhat.com> On Tue, Mar 31, 2015 at 11:38:30AM +0200, Matt . wrote: > Here some extra logging from the kerberos log: > > Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 10.10.0.121: NEEDED_PREAUTH: > kinituser at DOMAIN.LOCAL for krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL, > Additional pre-authentication required > Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6 > etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491, > etypes {rep=18 tkt=18 ses=18}, kinituser at DOMAIN.LOCAL for > krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL > Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): TGS_REQ (6 > etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491, > etypes {rep=18 tkt=18 ses=18}, kinituser at DOMAIN.LOCAL for > HTTP/ldap-01.domain.local at DOMAIN.LOCAL > > > I don't get the preauth needed, does it have anything todo with the > 301 redirect which I follow with CURL ? no, this is part of the AS_REQ (request to get a TGT) and will always happen. Since the Kerberos client cannot know what kind of pre-auth schemes are supported or required in the server side it first send a request without pre-auth data. The server sends back a list of supported schemes with a special NEEDED_PREAUTH error code if pre-auth is required. And with IPA pre-auth is required otherwise e.g. replay attacks would be easy. HTH bye, Sumit > > 2015-03-31 11:15 GMT+02:00 Matt . : > > Yes I would assume too, but it's just kicking out possibilities what > > could make it not working. > > > > I cannot figure out why it only logs the 401 after the known 301's in > > the access_log and nothing further, apache really blocks, so kerberos > > should be in the way for sure, but how. > > > > > > > > 2015-03-31 11:09 GMT+02:00 Sumit Bose : > >> On Tue, Mar 31, 2015 at 11:02:24AM +0200, Matt . wrote: > >>> On my client I still see: > >>> > >>> 03/31/2015 11:00:08 04/01/2015 11:00:07 krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL > >>> 03/31/2015 11:00:09 04/01/2015 11:00:07 HTTP/ldap-01.domain.local at DOMAIN.LOCAL > >>> > >>> Should ldap-01 not be ldap as I go through my loadbalancer ? > >> > >> I guess not, because your loadbalancer just redirects the traffic and > >> the authentication is done with ldap-01. > >> > >> bye, > >> Sumit > >> > >>> > >>> Do I need to merge keytabs or so ? > >>> > >>> 2015-03-31 7:54 GMT+02:00 Matt . : > >>> > Hi, > >>> > > >>> > I tried to trace some stuff but this doesn't give me much more info. > >>> > > >>> > What I see at the moment in the /var/log/httpd/acces_log is exactly > >>> > what happens but without the info I need to get a better view: > >>> > > >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 258 > >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" > >>> > 301 259 "https://ldap.domain.local/ipa/json" "-" > >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 401 1469 > >>> > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 401 1469 > >>> > > >>> > 2015-03-30 15:03 GMT+02:00 Sumit Bose : > >>> >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote: > >>> >>> Hi, > >>> >>> > >>> >>> I just tot home and typing from my cell so i'm suite short in words > >>> >>> > >>> >>> Create keytab for ldap-01.domain > >>> >>> Kinit with that to ldap.domain > >>> >>> Curl against ldap.domain > >>> >>> Get a 301 which I manage from curl (goes well) > >>> >>> Get kerberos ticket error > >>> >>> > >>> >>> now I don't kinit anymore so re-use my existing ticket and curl against > >>> >>> ldap-01.domain and I'm accepted and can execute stuff. > >>> >>> > >>> >>> My ssl is OK, ticket also it seems. > >>> >> > >>> >> Maybe the output of > >>> >> > >>> >> KRB5_TRACE=/dev/sdtout curl -v .... > >>> >> > >>> >> might help to see what is going on? > >>> >> > >>> >> bye, > >>> >> Sumit > >>> >> > >>> >>> > >>> >>> Thanks M. > >>> >>> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : > >>> >>> > >>> >>> > On 03/29/2015 04:47 AM, Matt . wrote: > >>> >>> > > >>> >>> >> Hi Guys, > >>> >>> >> > >>> >>> >> Now my Certification issues are solved for using a loadbalancer in > >>> >>> >> front of my ipa servers I get the following: > >>> >>> >> > >>> >>> >> Unable to verify your Kerberos credentials > >>> >>> >> > >>> >>> >> and in my logs: > >>> >>> >> > >>> >>> >> Additional pre-authentication required. > >>> >>> >> > >>> >>> >> This happens when I connect throught my loadbalancers, I see my server > >>> >>> >> coming ni with the right IP. > >>> >>> >> > >>> >>> >> When I access my ipa server directly, not using the loadbalancer IP > >>> >>> >> between it, my kerberos Ticket is valid. > >>> >>> >> > >>> >>> >> I get the feeling that when I use my loadbalancers and because of that > >>> >>> >> I get a 301 redirect it needs a preauth. I see some issues on > >>> >>> >> mailinglists but it doesn't fit my situation. > >>> >>> >> > >>> >>> >> Why wants it the preauth when I already have a valid ticket and my > >>> >>> >> redirect is followed by CURL and posted the right way ? > >>> >>> >> > >>> >>> > > >>> >>> > Can you describe the sequence? > >>> >>> > What do you do? > >>> >>> > > >>> >>> > From the client you try IPA CLI and this is where you see the problem even > >>> >>> > with the valid ticket or is the flow different? > >>> >>> > > >>> >>> > I hope someone has an idea. > >>> >>> >> > >>> >>> >> Thanks, > >>> >>> >> > >>> >>> >> Matt > >>> >>> >> > >>> >>> >> > >>> >>> > > >>> >>> > -- > >>> >>> > 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 > >>> >>> > > >>> >> > >>> >>> -- > >>> >>> 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 yamakasi.014 at gmail.com Tue Mar 31 09:57:12 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 11:57:12 +0200 Subject: [Freeipa-users] Additional pre-authentication required, Ticket Wrong ? In-Reply-To: <20150331095406.GK8895@p.redhat.com> References: <5518AB6D.1020606@redhat.com> <20150330130324.GB8895@p.redhat.com> <20150331090943.GJ8895@p.redhat.com> <20150331095406.GK8895@p.redhat.com> Message-ID: OK, also understood. Next item why I don't get any logging or it's not working as espected. I'm actually out of options to be honest. 2015-03-31 11:54 GMT+02:00 Sumit Bose : > On Tue, Mar 31, 2015 at 11:38:30AM +0200, Matt . wrote: >> Here some extra logging from the kerberos log: >> >> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.10.0.121: NEEDED_PREAUTH: >> kinituser at DOMAIN.LOCAL for krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL, >> Additional pre-authentication required >> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): AS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491, >> etypes {rep=18 tkt=18 ses=18}, kinituser at DOMAIN.LOCAL for >> krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL >> Mar 31 11:34:51 ldap-01.domain.local krb5kdc[2764](info): TGS_REQ (6 >> etypes {18 17 16 23 25 26}) 10.10.0.121: ISSUE: authtime 1427794491, >> etypes {rep=18 tkt=18 ses=18}, kinituser at DOMAIN.LOCAL for >> HTTP/ldap-01.domain.local at DOMAIN.LOCAL >> >> >> I don't get the preauth needed, does it have anything todo with the >> 301 redirect which I follow with CURL ? > > no, this is part of the AS_REQ (request to get a TGT) and will always > happen. Since the Kerberos client cannot know what kind of pre-auth > schemes are supported or required in the server side it first send a > request without pre-auth data. The server sends back a list of supported > schemes with a special NEEDED_PREAUTH error code if pre-auth is > required. And with IPA pre-auth is required otherwise e.g. replay > attacks would be easy. > > HTH > > bye, > Sumit > >> >> 2015-03-31 11:15 GMT+02:00 Matt . : >> > Yes I would assume too, but it's just kicking out possibilities what >> > could make it not working. >> > >> > I cannot figure out why it only logs the 401 after the known 301's in >> > the access_log and nothing further, apache really blocks, so kerberos >> > should be in the way for sure, but how. >> > >> > >> > >> > 2015-03-31 11:09 GMT+02:00 Sumit Bose : >> >> On Tue, Mar 31, 2015 at 11:02:24AM +0200, Matt . wrote: >> >>> On my client I still see: >> >>> >> >>> 03/31/2015 11:00:08 04/01/2015 11:00:07 krbtgt/DOMAIN.LOCAL at DOMAIN.LOCAL >> >>> 03/31/2015 11:00:09 04/01/2015 11:00:07 HTTP/ldap-01.domain.local at DOMAIN.LOCAL >> >>> >> >>> Should ldap-01 not be ldap as I go through my loadbalancer ? >> >> >> >> I guess not, because your loadbalancer just redirects the traffic and >> >> the authentication is done with ldap-01. >> >> >> >> bye, >> >> Sumit >> >> >> >>> >> >>> Do I need to merge keytabs or so ? >> >>> >> >>> 2015-03-31 7:54 GMT+02:00 Matt . : >> >>> > Hi, >> >>> > >> >>> > I tried to trace some stuff but this doesn't give me much more info. >> >>> > >> >>> > What I see at the moment in the /var/log/httpd/acces_log is exactly >> >>> > what happens but without the info I need to get a better view: >> >>> > >> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 301 258 >> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" >> >>> > 301 259 "https://ldap.domain.local/ipa/json" "-" >> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:58 +0200] "POST /ipa/json HTTP/1.1" 401 1469 >> >>> > 10.10.0.121 - - [30/Mar/2015:22:22:59 +0200] "POST /ipa/json HTTP/1.1" 401 1469 >> >>> > >> >>> > 2015-03-30 15:03 GMT+02:00 Sumit Bose : >> >>> >> On Mon, Mar 30, 2015 at 04:56:11AM +0200, Matt . wrote: >> >>> >>> Hi, >> >>> >>> >> >>> >>> I just tot home and typing from my cell so i'm suite short in words >> >>> >>> >> >>> >>> Create keytab for ldap-01.domain >> >>> >>> Kinit with that to ldap.domain >> >>> >>> Curl against ldap.domain >> >>> >>> Get a 301 which I manage from curl (goes well) >> >>> >>> Get kerberos ticket error >> >>> >>> >> >>> >>> now I don't kinit anymore so re-use my existing ticket and curl against >> >>> >>> ldap-01.domain and I'm accepted and can execute stuff. >> >>> >>> >> >>> >>> My ssl is OK, ticket also it seems. >> >>> >> >> >>> >> Maybe the output of >> >>> >> >> >>> >> KRB5_TRACE=/dev/sdtout curl -v .... >> >>> >> >> >>> >> might help to see what is going on? >> >>> >> >> >>> >> bye, >> >>> >> Sumit >> >>> >> >> >>> >>> >> >>> >>> Thanks M. >> >>> >>> Op 30 mrt. 2015 03:50 schreef "Dmitri Pal" : >> >>> >>> >> >>> >>> > On 03/29/2015 04:47 AM, Matt . wrote: >> >>> >>> > >> >>> >>> >> Hi Guys, >> >>> >>> >> >> >>> >>> >> Now my Certification issues are solved for using a loadbalancer in >> >>> >>> >> front of my ipa servers I get the following: >> >>> >>> >> >> >>> >>> >> Unable to verify your Kerberos credentials >> >>> >>> >> >> >>> >>> >> and in my logs: >> >>> >>> >> >> >>> >>> >> Additional pre-authentication required. >> >>> >>> >> >> >>> >>> >> This happens when I connect throught my loadbalancers, I see my server >> >>> >>> >> coming ni with the right IP. >> >>> >>> >> >> >>> >>> >> When I access my ipa server directly, not using the loadbalancer IP >> >>> >>> >> between it, my kerberos Ticket is valid. >> >>> >>> >> >> >>> >>> >> I get the feeling that when I use my loadbalancers and because of that >> >>> >>> >> I get a 301 redirect it needs a preauth. I see some issues on >> >>> >>> >> mailinglists but it doesn't fit my situation. >> >>> >>> >> >> >>> >>> >> Why wants it the preauth when I already have a valid ticket and my >> >>> >>> >> redirect is followed by CURL and posted the right way ? >> >>> >>> >> >> >>> >>> > >> >>> >>> > Can you describe the sequence? >> >>> >>> > What do you do? >> >>> >>> > >> >>> >>> > From the client you try IPA CLI and this is where you see the problem even >> >>> >>> > with the valid ticket or is the flow different? >> >>> >>> > >> >>> >>> > I hope someone has an idea. >> >>> >>> >> >> >>> >>> >> Thanks, >> >>> >>> >> >> >>> >>> >> Matt >> >>> >>> >> >> >>> >>> >> >> >>> >>> > >> >>> >>> > -- >> >>> >>> > 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 >> >>> >>> > >> >>> >> >> >>> >>> -- >> >>> >>> 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 sbose at redhat.com Tue Mar 31 09:58:57 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 31 Mar 2015 11:58:57 +0200 Subject: [Freeipa-users] generic failure: GSSAPI Error: Unspecified GSS failure In-Reply-To: References: Message-ID: <20150331095857.GL8895@p.redhat.com> On Tue, Mar 31, 2015 at 11:26:53AM +0200, Benoit Rousselle wrote: > hi, > > I try to set the sudo password but I get a message : GSSAPI Error > > What's mean this kind of message ? > > ldappasswd -Y GSSAPI -S -h my_server > uid=sudo,cn=sysaccounts,cn=etc,dc=my_domain,dc=com > New password: > Re-enter new password: > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: > Unspecified GSS failure. Minor code may provide more information (Ticket > expired) 'Ticket expired', so you either have to call kinit again to get a fresh TGT or there is some severe time mismatch between the client and the server. HTH bye, Sumit > -- > 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 prashant at apigee.com Tue Mar 31 11:56:13 2015 From: prashant at apigee.com (Prashant Bapat) Date: Tue, 31 Mar 2015 17:26:13 +0530 Subject: [Freeipa-users] freeipa behind a load balancer Message-ID: Hi, I'm trying to get 2 FreeIPA servers in a replicated mode behind a load balancer, specifically Amazon ELB. I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like there is more to it than just this file. Any suggestions ? Thanks. --Prashant -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Tue Mar 31 12:02:23 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 14:02:23 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: Message-ID: HI Phasant, Check my mailings about it, it's not easy at least the kerberos part not, SRV records are used for that normally. Are you talking about the webgui or the ldap part ? Cheers, Matt 2015-03-31 13:56 GMT+02:00 Prashant Bapat : > Hi, > > I'm trying to get 2 FreeIPA servers in a replicated mode behind a load > balancer, specifically Amazon ELB. > > I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like > there is more to it than just this file. > > Any suggestions ? > > Thanks. > --Prashant > > -- > 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 Tue Mar 31 12:21:52 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 31 Mar 2015 14:21:52 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: Message-ID: <551A9160.7060800@redhat.com> On 31.3.2015 14:02, Matt . wrote: > HI Phasant, > > Check my mailings about it, it's not easy at least the kerberos part > not, SRV records are used for that normally. > > Are you talking about the webgui or the ldap part ? I would recommend you to step back and describe use-case you have in mind. It is important for us to understand to your use-case to propose optimal solution. Petr^2 Spacek > Cheers, > > Matt > > 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >> Hi, >> >> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >> balancer, specifically Amazon ELB. >> >> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >> there is more to it than just this file. >> >> Any suggestions ? >> >> Thanks. >> --Prashant From yamakasi.014 at gmail.com Tue Mar 31 12:35:29 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 14:35:29 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <551A9160.7060800@redhat.com> References: <551A9160.7060800@redhat.com> Message-ID: Hi Petr, As this is not my topic it's for me quite "simple". I need to post to /ipa/json through a loadbalancer, nothing more. i have ldap-01.domain.tld (ipa1) ldap-01.domain.tld (ipa2) and my loadbalancer is ldap.domain.tld ldap requests over a loadbalancer are quite simple and working, but the json part is more difficult because of the ticket and the dns name. I have added a san ldap.domain.tld to the webgui and there is a http/ldap.domain.tld service on the ipa server. I get a nonvalid kerberos ticket when I go through ldap.domain.tld to ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld after it failed my ticket is OK for ldap-01.domain.tld and works. Is this enough information for you ? Cheers, Matt 2015-03-31 14:21 GMT+02:00 Petr Spacek : > On 31.3.2015 14:02, Matt . wrote: >> HI Phasant, >> >> Check my mailings about it, it's not easy at least the kerberos part >> not, SRV records are used for that normally. >> >> Are you talking about the webgui or the ldap part ? > > I would recommend you to step back and describe use-case you have in mind. It > is important for us to understand to your use-case to propose optimal solution. > > Petr^2 Spacek > >> Cheers, >> >> Matt >> >> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >>> Hi, >>> >>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >>> balancer, specifically Amazon ELB. >>> >>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >>> there is more to it than just this file. >>> >>> Any suggestions ? >>> >>> Thanks. >>> --Prashant > > -- > 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 Tue Mar 31 13:03:59 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 31 Mar 2015 15:03:59 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: <551A9160.7060800@redhat.com> Message-ID: <551A9B3F.4010900@redhat.com> On 31.3.2015 14:35, Matt . wrote: > Hi Petr, > > As this is not my topic it's for me quite "simple". > > I need to post to /ipa/json through a loadbalancer, nothing more. > > i have > > ldap-01.domain.tld (ipa1) > ldap-01.domain.tld (ipa2) > > and my loadbalancer is ldap.domain.tld > > ldap requests over a loadbalancer are quite simple and working, but > the json part is more difficult because of the ticket and the dns > name. I have added a san ldap.domain.tld to the webgui and there is a > http/ldap.domain.tld service on the ipa server. > > I get a nonvalid kerberos ticket when I go through ldap.domain.tld to > ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld > after it failed my ticket is OK for ldap-01.domain.tld and works. > > Is this enough information for you ? Well, I still do not understand the use case. What are your clients? Are you using 'ipa' command to do something? Or some other clients? Usually the best thing is to use DNS SRV records because it works even with geographically distributed clusters and does not have single point of failure (the load balancer). This requires clients with support for DNS SRV but if your machines are using SSSD then you do not need to change anything and it should just work. That is why I'm asking for the use case :-) Petr^2 Spacek > 2015-03-31 14:21 GMT+02:00 Petr Spacek : >> On 31.3.2015 14:02, Matt . wrote: >>> HI Phasant, >>> >>> Check my mailings about it, it's not easy at least the kerberos part >>> not, SRV records are used for that normally. >>> >>> Are you talking about the webgui or the ldap part ? >> >> I would recommend you to step back and describe use-case you have in mind. It >> is important for us to understand to your use-case to propose optimal solution. >> >> Petr^2 Spacek >> >>> Cheers, >>> >>> Matt >>> >>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >>>> Hi, >>>> >>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >>>> balancer, specifically Amazon ELB. >>>> >>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >>>> there is more to it than just this file. >>>> >>>> Any suggestions ? >>>> >>>> Thanks. >>>> --Prashant From yamakasi.014 at gmail.com Tue Mar 31 13:23:18 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 15:23:18 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <551A9B3F.4010900@redhat.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> Message-ID: Hi Petr, We discussed that before indeed, but SRV is not usable in this case. My clients are just webservers (apache) doing some executes of CURL commands to ipa/json, actually the same commands as the webgui does using json, but we curl it. Do you have a better view now ? Cheers, Matt 2015-03-31 15:03 GMT+02:00 Petr Spacek : > On 31.3.2015 14:35, Matt . wrote: >> Hi Petr, >> >> As this is not my topic it's for me quite "simple". >> >> I need to post to /ipa/json through a loadbalancer, nothing more. >> >> i have >> >> ldap-01.domain.tld (ipa1) >> ldap-01.domain.tld (ipa2) >> >> and my loadbalancer is ldap.domain.tld >> >> ldap requests over a loadbalancer are quite simple and working, but >> the json part is more difficult because of the ticket and the dns >> name. I have added a san ldap.domain.tld to the webgui and there is a >> http/ldap.domain.tld service on the ipa server. >> >> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >> after it failed my ticket is OK for ldap-01.domain.tld and works. >> >> Is this enough information for you ? > > Well, I still do not understand the use case. What are your clients? Are you > using 'ipa' command to do something? Or some other clients? > > Usually the best thing is to use DNS SRV records because it works even with > geographically distributed clusters and does not have single point of failure > (the load balancer). > > This requires clients with support for DNS SRV but if your machines are using > SSSD then you do not need to change anything and it should just work. > > That is why I'm asking for the use case :-) > > Petr^2 Spacek > >> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >>> On 31.3.2015 14:02, Matt . wrote: >>>> HI Phasant, >>>> >>>> Check my mailings about it, it's not easy at least the kerberos part >>>> not, SRV records are used for that normally. >>>> >>>> Are you talking about the webgui or the ldap part ? >>> >>> I would recommend you to step back and describe use-case you have in mind. It >>> is important for us to understand to your use-case to propose optimal solution. >>> >>> Petr^2 Spacek >>> >>>> Cheers, >>>> >>>> Matt >>>> >>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >>>>> Hi, >>>>> >>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >>>>> balancer, specifically Amazon ELB. >>>>> >>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >>>>> there is more to it than just this file. >>>>> >>>>> Any suggestions ? >>>>> >>>>> Thanks. >>>>> --Prashant From david.kreuter at bytesource.net Tue Mar 31 13:26:20 2015 From: david.kreuter at bytesource.net (David Kreuter) Date: Tue, 31 Mar 2015 15:26:20 +0200 (CEST) Subject: [Freeipa-users] Fwd: Unexpected IPA Crashes In-Reply-To: <55157825.9050807@redhat.com> Message-ID: <7b3fffa4-749a-474e-96b3-0e91a3a3fad8@zimbra.bytesource.net> The only solutions for me was to integrate the CR repository and upgrade to IPA 4.1.0. Perhaps my problem was solved by 'CVE-2015-1827' It was discovered that the IPA extdom Directory Server plug-in did not correctly perform memory reallocation when handling user account information. A request for a list of groups for a user that belongs to a large number of groups would cause a Directory Server to crash. Anyway, after 5 days without any crash I'm very confident the the problem is solved. ----- Original Message ----- From: "Sankar Ramlingam" To: freeipa-users at redhat.com Sent: Friday, 27 March, 2015 4:32:53 PM Subject: Re: [Freeipa-users] Fwd: Unexpected IPA Crashes On 03/27/2015 01:42 PM, David Kreuter wrote: No, there are no entries with "segfaulter" neither in /var/log/messags nor in journalctr. Meanwhile we encountered several directory server hangs and I was able to produce the stacktrace. Perhpas you can have a look. Hi David, You seem to have the latest/released version of 389-ds-base. You can probably try an upgrade to get the latest of other dependent components and 389-ds-base-debuginfo. Thanks, -Sankar R.
----- Original Message ----- From: "David Kreuter" To: "freeipa-users" Sent: Thursday, 26 March, 2015 11:18:59 PM Subject: Unexpected IPA Crashes We have been using FreeIPA since two years and were more than happy. But since two weeks we are facing unexpected crashed and can not really debug the strange behaviours. The crashes are definitely not caused by connecting a new system or changing the LDAP schema heavily. Following IPA is used: Name : ipa-server Arch : x86_64 Version : 3.3.3 Release : 28.0.1.el7.centos.3 Size : 4.1 M I have followed the troubleshooting guide http://directory.fedoraproject.org/docs/389ds/FAQ/faq.html#Troubleshooting and activated logging and activated the core dumping. Unfortunately, I cannot provide you any core dump, because it is not created after the ipa servers crashes. I'm sure the dirsrv is causing the problem, because when i restart the 389, then ipa works fine for a while. Currently I have activated the replication log level 8192. The error log shows no suspicious error or any fatal error. Following 389* versions are used: Installed Packages 389-ds-base.x86_64 1.3.3.1-15.el7_1 @/389-ds-base-1.3.3.1-15.el7_1.x86_64 389-ds-base-debuginfo.x86_64 1.3.1.6-26.el7_0 @base-debuginfo 389-ds-base-libs.x86_64 1.3.3.1-15.el7_1 Can you please provide some hint how I can debug this problem in more detail. Btw, the ipa infrastructure consist of one master and one replica. The server was also crashing, when the replica server was turned off. Do you thing an upgrade would solve the problem as the last resort?
-- 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 janellenicole80 at gmail.com Tue Mar 31 13:38:28 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 31 Mar 2015 06:38:28 -0700 Subject: [Freeipa-users] Migration mode fun and confusion Message-ID: <551AA354.2090706@gmail.com> Hello again, Is this a feature or a bug? Migration mode - works fine the first time. However, if you need to run it a second time because someone added either new users or groups to your LDAP config and you want to bring those over, if you re-run migration, it indeed brings all the new users over, but NOT their secondary groups, only primary. And even if you have overwrite of the GID option set. Would this be expected for some reason that I may be missing, or is it a bug? Thank you ~J From dpal at redhat.com Tue Mar 31 13:49:19 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 31 Mar 2015 09:49:19 -0400 Subject: [Freeipa-users] Migration mode fun and confusion In-Reply-To: <551AA354.2090706@gmail.com> References: <551AA354.2090706@gmail.com> Message-ID: <551AA5DF.3090403@redhat.com> On 03/31/2015 09:38 AM, Janelle wrote: > Hello again, > > Is this a feature or a bug? > > Migration mode - works fine the first time. However, if you need to > run it a second time because someone added either new users or groups > to your LDAP config and you want to bring those over, if you re-run > migration, it indeed brings all the new users over, but NOT their > secondary groups, only primary. And even if you have overwrite of the > GID option set. > > Would this be expected for some reason that I may be missing, or is it > a bug? > > Thank you > ~J > Let be know if I get you right. Setup: - Old LDAP server - IPA Users are migrated from LDAP to IPA using migrate-ds. Everything works as expected Now you add users to LDAP and put them into some groups (that were already been migrated the first time, right?) You run migrate-ds again and the new users are migrated but group membership is lost. Is this the scenario? If yes, looks like a bug. -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From pspacek at redhat.com Tue Mar 31 13:58:10 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 31 Mar 2015 15:58:10 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> Message-ID: <551AA7F2.2070105@redhat.com> On 31.3.2015 15:23, Matt . wrote: > Hi Petr, > > We discussed that before indeed, but SRV is not usable in this case. > > My clients are just webservers (apache) doing some executes of CURL > commands to ipa/json, actually the same commands as the webgui does > using json, but we curl it. > > Do you have a better view now ? Yes. If you have seen the previous discussion then you know that it will be pretty difficult to do this kind of load balancing. Why are you not using 'ipa' command or Python API we have instead? Why to use CURL and make things more complex? Petr^2 Spacek > 2015-03-31 15:03 GMT+02:00 Petr Spacek : >> On 31.3.2015 14:35, Matt . wrote: >>> Hi Petr, >>> >>> As this is not my topic it's for me quite "simple". >>> >>> I need to post to /ipa/json through a loadbalancer, nothing more. >>> >>> i have >>> >>> ldap-01.domain.tld (ipa1) >>> ldap-01.domain.tld (ipa2) >>> >>> and my loadbalancer is ldap.domain.tld >>> >>> ldap requests over a loadbalancer are quite simple and working, but >>> the json part is more difficult because of the ticket and the dns >>> name. I have added a san ldap.domain.tld to the webgui and there is a >>> http/ldap.domain.tld service on the ipa server. >>> >>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >>> after it failed my ticket is OK for ldap-01.domain.tld and works. >>> >>> Is this enough information for you ? >> >> Well, I still do not understand the use case. What are your clients? Are you >> using 'ipa' command to do something? Or some other clients? >> >> Usually the best thing is to use DNS SRV records because it works even with >> geographically distributed clusters and does not have single point of failure >> (the load balancer). >> >> This requires clients with support for DNS SRV but if your machines are using >> SSSD then you do not need to change anything and it should just work. >> >> That is why I'm asking for the use case :-) >> >> Petr^2 Spacek >> >>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >>>> On 31.3.2015 14:02, Matt . wrote: >>>>> HI Phasant, >>>>> >>>>> Check my mailings about it, it's not easy at least the kerberos part >>>>> not, SRV records are used for that normally. >>>>> >>>>> Are you talking about the webgui or the ldap part ? >>>> >>>> I would recommend you to step back and describe use-case you have in mind. It >>>> is important for us to understand to your use-case to propose optimal solution. >>>> >>>> Petr^2 Spacek >>>> >>>>> Cheers, >>>>> >>>>> Matt >>>>> >>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >>>>>> Hi, >>>>>> >>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >>>>>> balancer, specifically Amazon ELB. >>>>>> >>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >>>>>> there is more to it than just this file. >>>>>> >>>>>> Any suggestions ? >>>>>> >>>>>> Thanks. >>>>>> --Prashant -- Petr Spacek @ Red Hat From dpal at redhat.com Tue Mar 31 13:58:39 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 31 Mar 2015 09:58:39 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: References: <55148136.8040003@redhat.com> <5514C804.4040207@redhat.com> <55156455.7090401@redhat.com> <5515C3DF.5020701@redhat.com> Message-ID: <551AA80F.5070807@redhat.com> On 03/31/2015 04:08 AM, Prasun Gera wrote: > > The idea is that you tel lall the users to either login via > migration page or via SSSD. > If your server is in a migration mode the migration page should be > available and SSSD should detect that server is in migration mode. > In this case any authentication via SSSD will end up creating > proper hashes for Kerberos. I suspect this is when the conversion > of the LDAP hashes happens too. > You suggested that this is not the case but I am not sure that the > test was 100 correct. > > Please try: > - check that migration mode is on > - check that user does not have kerberos password only LDAP hash > from NIS migration > - ssh into a box that runs SSSD with such user, authenticate > As a result you should see Kerberos hash created for this user and > I suspect the LDAP hash is converted at the same time. > > > I verified all the steps, and I can confirm that SSSD does not migrate > users automatically. > I see the following in /var/log/secure, which confirms that sssd is > indeed authenticating the user > > Mar 31 03:50:47 ipaserver sshd[23531]: Accepted password for testuser2 > from ip port 43622 ssh2 > Mar 31 03:50:47 ipaserver sshd[23531]: pam_unix(sshd:session): session > opened for user testuser2 by (uid=0) Hm... this does not mean SSSD was used during the authentication. It means that you used files that were delivered by NIS. > > ipa user-show testuser2 still shows Kerberos keys available: False > > sssd's logs also show successful authentication. ? SSSD does not seem to be involved as user is found in the /etc/passwd and this SSSD should not do anything. > > I think this sounds reasonable (and possibly intentional?) since the > alternative would make staged migration impossible. As soon as one > client is migrated, all other clients would lose the ability to > authenticate with NIS. The way it is behaving right now is actually > preferable. i.e. No automatic migration until done explicitly by > user/admin. > > Coming back to the original issue, I deleted those accidentally > migrated users and added them again, and I haven't seen any anomalous > behaviour since. i.e Their cypt hashes are visible to NIS clients. I > can only guess that whatever triggered it in the first place was a > one-off event. Could yum update be responsible ? All the free ipa > packages were updated last week to the latest point release. In any > case, I think it is behaving well for now, and hope it stays that way. No yum has nothing to do with it. But may be there is a client where the pam stack is configured without pam_unix being first or there was some latency and SSSD managed to find user before NIS replicated the map or NIS is not configured on that client. In this case the user would be migrated because it would hit SSSD. > > Minor question: Our NIS maps had separate shadow maps originally, > which provided some mild security since they can't be accessed by > unprivileged users/ports. Is it possible to do that with the NIS > plugin in IPA ? No AFAIK. It is not recommended to use NIS for authentication anyways so making marginally secure is relly a design not goal. The intent is to help you migrate off NIS as soon as possible. > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: From steve at sylvation.com Tue Mar 31 14:01:58 2015 From: steve at sylvation.com (Steve Neuharth) Date: Tue, 31 Mar 2015 09:01:58 -0500 Subject: [Freeipa-users] freeipa 4.x packages for RHEL? Message-ID: Hello, We're currently running RHEL in production and would love to be using all the goodness that is FreeIPA 4 including certmonger for certificate management. I don't see any mention of 4.x packages available for RHEL in the mailing lists and I have run into problems using the 3.3 client packages on a 4.x realm. When will 4.x packages be available for RHEL? --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From Joshua.Gould at osumc.edu Tue Mar 31 14:02:37 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Tue, 31 Mar 2015 10:02:37 -0400 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: <20150331073047.GG8895@p.redhat.com> References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> <20150330150829.GR4696@redhat.com> <5519723D.5060704@redhat.com> <551A3725.10602@redhat.com> <20150331073047.GG8895@p.redhat.com> Message-ID: Klist in Windows showed one ticket for the IPA domain. #0> Client: adm-faru03 @ test.osuwmc Server: krbtgt/UNIX.TEST.OSUWMC @ TEST.OSUWMC KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a40000 -> forward able renewable pre_authent ok_as_delegate Start Time: 3/31/2015: 9:29:25 (local) End Time: 3/31/2015: 15:28:22 (local) Session Key Type: AES-256-CTS-HMAC-SHA1-96 IPA and SSSD are: ipa-server.x86_64 4.1.0-18.el7_1.3 sssd.x86_64 1.12.2-58.el7_1.6.1 Kinit adm-faru03 at TEST.OSUWMC was telling. Once it reported ?kinit: KDC reply did not match expectations while getting initial credentials?. We waited a minute or two (were discussing results) and tried again just adding the -V flag and it worked. Kvno host/mid-ipa-vp01.unix.test.osuwmc at UNIX.TEST.OSUWMC = 2 Verbose logging in putty gave the following error: On 3/31/15, 3:30 AM, "Sumit Bose" wrote: > >Can you do the follwoing checks: > >Can you check by calling klist in a Windows Command window if you got > > >a proper host/... ticket for the IPA host? > > > > > >What version of IPA and SSSD are you using. > > > > > >Can you check if the following works on a IPA host: > > > > > >kinit adm-faru03 at TEST.OSUWMC > > >kvno host/name.of.the.ipa-client.to.login at IPA.REALM > > >ssh -v -l adm-faru03 at test.osuwmc name.of.the.ipa-client.to.login > > From Joshua.Gould at osumc.edu Tue Mar 31 14:03:16 2015 From: Joshua.Gould at osumc.edu (Gould, Joshua) Date: Tue, 31 Mar 2015 10:03:16 -0400 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: <20150330144543.GA4156@redhat.com> <20150330145542.GQ4696@redhat.com> <20150330150829.GR4696@redhat.com> <5519723D.5060704@redhat.com> <551A3725.10602@redhat.com> <20150331073047.GG8895@p.redhat.com> Message-ID: Putty error was: Event Log: GSSAPI authentication initialisation failed Event Log: No authority could be contacted for authentication.The domain name of the authenticating party could be wrong, the domain could be unreachable, or there might have been a trust relationship failure. On 3/31/15, 10:02 AM, "Gould, Joshua" wrote: >Klist in Windows showed one ticket for the IPA domain. > >#0> Client: adm-faru03 @ test.osuwmc > Server: krbtgt/UNIX.TEST.OSUWMC @ TEST.OSUWMC > KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 > Ticket Flags 0x40a40000 -> forward able renewable pre_authent >ok_as_delegate > Start Time: 3/31/2015: 9:29:25 (local) > End Time: 3/31/2015: 15:28:22 (local) > Session Key Type: AES-256-CTS-HMAC-SHA1-96 > >IPA and SSSD are: >ipa-server.x86_64 >4.1.0-18.el7_1.3 >sssd.x86_64 >1.12.2-58.el7_1.6.1 > >Kinit adm-faru03 at TEST.OSUWMC was telling. Once it reported ?kinit: KDC >reply did not match expectations while getting initial credentials?. We >waited a minute or two (were discussing results) and tried again just >adding the -V flag and it worked. > >Kvno host/mid-ipa-vp01.unix.test.osuwmc at UNIX.TEST.OSUWMC = 2 > >Verbose logging in putty gave the following error: > > >On 3/31/15, 3:30 AM, "Sumit Bose" wrote: > >> >>Can you do the follwoing checks: >> >>Can you check by calling klist in a Windows Command window if you got >> >> >>a proper host/... ticket for the IPA host? >> >> >> >> >> >>What version of IPA and SSSD are you using. >> >> >> >> >> >>Can you check if the following works on a IPA host: >> >> >> >> >> >>kinit adm-faru03 at TEST.OSUWMC >> >> >>kvno host/name.of.the.ipa-client.to.login at IPA.REALM >> >> >>ssh -v -l adm-faru03 at test.osuwmc name.of.the.ipa-client.to.login >> >> > From prashant at apigee.com Tue Mar 31 14:10:06 2015 From: prashant at apigee.com (Prashant Bapat) Date: Tue, 31 Mar 2015 19:40:06 +0530 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: Message-ID: Just the web UI. Thanks. --Prashant On Mar 31, 2015 5:32 PM, "Matt ." wrote: > HI Phasant, > > Check my mailings about it, it's not easy at least the kerberos part > not, SRV records are used for that normally. > > Are you talking about the webgui or the ldap part ? > > Cheers, > > Matt > > 2015-03-31 13:56 GMT+02:00 Prashant Bapat : > > Hi, > > > > I'm trying to get 2 FreeIPA servers in a replicated mode behind a load > > balancer, specifically Amazon ELB. > > > > I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks > like > > there is more to it than just this file. > > > > Any suggestions ? > > > > Thanks. > > --Prashant > > > > -- > > 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 yamakasi.014 at gmail.com Tue Mar 31 14:10:22 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 16:10:22 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <551AA7F2.2070105@redhat.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> Message-ID: HI Petr, We had a several of reasons why we did that. We wanted to use one language for that, and also have formatted returns. There was also some security issue which came up. I could ask you, why does IPA json itself ? if you see what it posts and what it gets back as result it makes it much more clear in development. HTTP loadbalancing is not difficult at all, as we post to the webserver I need to have that part only auth right. We do more very specific loadbalancing stuff and this is the most easy one as it's only webserver forward, but IPA/Kerberos has an issue with the principal it seems... it cannot be hard to make that accepted I would say. I'm still looking for solutions :) Cheers, Matt 2015-03-31 15:58 GMT+02:00 Petr Spacek : > On 31.3.2015 15:23, Matt . wrote: >> Hi Petr, >> >> We discussed that before indeed, but SRV is not usable in this case. >> >> My clients are just webservers (apache) doing some executes of CURL >> commands to ipa/json, actually the same commands as the webgui does >> using json, but we curl it. >> >> Do you have a better view now ? > > Yes. If you have seen the previous discussion then you know that it will be > pretty difficult to do this kind of load balancing. > > Why are you not using 'ipa' command or Python API we have instead? Why to use > CURL and make things more complex? > > Petr^2 Spacek > >> 2015-03-31 15:03 GMT+02:00 Petr Spacek : >>> On 31.3.2015 14:35, Matt . wrote: >>>> Hi Petr, >>>> >>>> As this is not my topic it's for me quite "simple". >>>> >>>> I need to post to /ipa/json through a loadbalancer, nothing more. >>>> >>>> i have >>>> >>>> ldap-01.domain.tld (ipa1) >>>> ldap-01.domain.tld (ipa2) >>>> >>>> and my loadbalancer is ldap.domain.tld >>>> >>>> ldap requests over a loadbalancer are quite simple and working, but >>>> the json part is more difficult because of the ticket and the dns >>>> name. I have added a san ldap.domain.tld to the webgui and there is a >>>> http/ldap.domain.tld service on the ipa server. >>>> >>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >>>> after it failed my ticket is OK for ldap-01.domain.tld and works. >>>> >>>> Is this enough information for you ? >>> >>> Well, I still do not understand the use case. What are your clients? Are you >>> using 'ipa' command to do something? Or some other clients? >>> >>> Usually the best thing is to use DNS SRV records because it works even with >>> geographically distributed clusters and does not have single point of failure >>> (the load balancer). >>> >>> This requires clients with support for DNS SRV but if your machines are using >>> SSSD then you do not need to change anything and it should just work. >>> >>> That is why I'm asking for the use case :-) >>> >>> Petr^2 Spacek >>> >>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >>>>> On 31.3.2015 14:02, Matt . wrote: >>>>>> HI Phasant, >>>>>> >>>>>> Check my mailings about it, it's not easy at least the kerberos part >>>>>> not, SRV records are used for that normally. >>>>>> >>>>>> Are you talking about the webgui or the ldap part ? >>>>> >>>>> I would recommend you to step back and describe use-case you have in mind. It >>>>> is important for us to understand to your use-case to propose optimal solution. >>>>> >>>>> Petr^2 Spacek >>>>> >>>>>> Cheers, >>>>>> >>>>>> Matt >>>>>> >>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >>>>>>> Hi, >>>>>>> >>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >>>>>>> balancer, specifically Amazon ELB. >>>>>>> >>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >>>>>>> there is more to it than just this file. >>>>>>> >>>>>>> Any suggestions ? >>>>>>> >>>>>>> Thanks. >>>>>>> --Prashant > > > -- > Petr Spacek @ Red Hat From Andy.Thompson at e-tcc.com Tue Mar 31 14:13:55 2015 From: Andy.Thompson at e-tcc.com (Andy Thompson) Date: Tue, 31 Mar 2015 14:13:55 +0000 Subject: [Freeipa-users] generic failure: GSSAPI Error: Unspecified GSS failure In-Reply-To: References: Message-ID: > I try to set the sudo password but I get a message : GSSAPI Error > > What's mean this kind of message ? > > ldappasswd -Y GSSAPI -S -h my_server > uid=sudo,cn=sysaccounts,cn=etc,dc=my_domain,dc=com > New password: > Re-enter new password: > SASL/GSSAPI authentication started > ldap_sasl_interactive_bind_s: Local error (-2) > additional info: SASL(-1): generic failure: GSSAPI Error: Unspecified GSS > failure. Minor code may provide more information (Ticket expired) Your kerberos ticket has expired. You need to get a new ticket using kinit and then try using gssapi. -andy From abokovoy at redhat.com Tue Mar 31 14:16:51 2015 From: abokovoy at redhat.com (Alexander Bokovoy) Date: Tue, 31 Mar 2015 17:16:51 +0300 Subject: [Freeipa-users] freeipa 4.x packages for RHEL? In-Reply-To: References: Message-ID: <20150331141651.GS3878@redhat.com> On Tue, 31 Mar 2015, Steve Neuharth wrote: >Hello, > >We're currently running RHEL in production and would love to be using all >the goodness that is FreeIPA 4 including certmonger for certificate >management. I don't see any mention of 4.x packages available for RHEL in >the mailing lists and I have run into problems using the 3.3 client >packages on a 4.x realm. > >When will 4.x packages be available for RHEL? They are already available, starting with RHEL7.1. -- / Alexander Bokovoy From pspacek at redhat.com Tue Mar 31 14:24:44 2015 From: pspacek at redhat.com (Petr Spacek) Date: Tue, 31 Mar 2015 16:24:44 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> Message-ID: <551AAE2C.8070606@redhat.com> On 31.3.2015 16:10, Matt . wrote: > HI Petr, > > We had a several of reasons why we did that. We wanted to use one > language for that, and also have formatted returns. There was also > some security issue which came up. I would be very interested in the security reason. If you see any problem with 'ipa' command or FreeIPA API please send me a private e-mail or contact secalert at redhat.com directly. > I could ask you, why does IPA json itself ? if you see what it posts > and what it gets back as result it makes it much more clear in > development. I do not understand the question, sorry. If you want to see what 'ipa' command does run it with '-vv' parameter: $ ipa -vv user-find It will print JSON request and reply: ipa: INFO: Request: { "id": 0, "method": "user_find", "params": [ [ null ], { "all": false, "no_members": false, "pkey_only": false, "raw": false, "version": "2.115", "whoami": false } ] } ipa: INFO: Response: { "error": null, "id": 0, "principal": "admin at IPA.EXAMPLE", "result": { "count": 2, "result": [ { "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", "gidnumber": [ "1381000000" ], ... > HTTP loadbalancing is not difficult at all, as we post to the > webserver I need to have that part only auth right. We do more very > specific loadbalancing stuff and this is the most easy one as it's > only webserver forward, but IPA/Kerberos has an issue with the > principal it seems... it cannot be hard to make that accepted I would > say. If you insist on Kerberos servers behind a load balancer... you will need to somehow share the Kerberos key among all servers. I will defer that to Kerberos experts here. > I'm still looking for solutions :) Sure, but you will save a lot of time and nerves if you simply call 'ipa' command :-) Have a nice day! Petr^2 Spacek > Cheers, > > Matt > > 2015-03-31 15:58 GMT+02:00 Petr Spacek : >> On 31.3.2015 15:23, Matt . wrote: >>> Hi Petr, >>> >>> We discussed that before indeed, but SRV is not usable in this case. >>> >>> My clients are just webservers (apache) doing some executes of CURL >>> commands to ipa/json, actually the same commands as the webgui does >>> using json, but we curl it. >>> >>> Do you have a better view now ? >> >> Yes. If you have seen the previous discussion then you know that it will be >> pretty difficult to do this kind of load balancing. >> >> Why are you not using 'ipa' command or Python API we have instead? Why to use >> CURL and make things more complex? >> >> Petr^2 Spacek >> >>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : >>>> On 31.3.2015 14:35, Matt . wrote: >>>>> Hi Petr, >>>>> >>>>> As this is not my topic it's for me quite "simple". >>>>> >>>>> I need to post to /ipa/json through a loadbalancer, nothing more. >>>>> >>>>> i have >>>>> >>>>> ldap-01.domain.tld (ipa1) >>>>> ldap-01.domain.tld (ipa2) >>>>> >>>>> and my loadbalancer is ldap.domain.tld >>>>> >>>>> ldap requests over a loadbalancer are quite simple and working, but >>>>> the json part is more difficult because of the ticket and the dns >>>>> name. I have added a san ldap.domain.tld to the webgui and there is a >>>>> http/ldap.domain.tld service on the ipa server. >>>>> >>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. >>>>> >>>>> Is this enough information for you ? >>>> >>>> Well, I still do not understand the use case. What are your clients? Are you >>>> using 'ipa' command to do something? Or some other clients? >>>> >>>> Usually the best thing is to use DNS SRV records because it works even with >>>> geographically distributed clusters and does not have single point of failure >>>> (the load balancer). >>>> >>>> This requires clients with support for DNS SRV but if your machines are using >>>> SSSD then you do not need to change anything and it should just work. >>>> >>>> That is why I'm asking for the use case :-) >>>> >>>> Petr^2 Spacek >>>> >>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >>>>>> On 31.3.2015 14:02, Matt . wrote: >>>>>>> HI Phasant, >>>>>>> >>>>>>> Check my mailings about it, it's not easy at least the kerberos part >>>>>>> not, SRV records are used for that normally. >>>>>>> >>>>>>> Are you talking about the webgui or the ldap part ? >>>>>> >>>>>> I would recommend you to step back and describe use-case you have in mind. It >>>>>> is important for us to understand to your use-case to propose optimal solution. >>>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>>> Cheers, >>>>>>> >>>>>>> Matt >>>>>>> >>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >>>>>>>> Hi, >>>>>>>> >>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >>>>>>>> balancer, specifically Amazon ELB. >>>>>>>> >>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >>>>>>>> there is more to it than just this file. >>>>>>>> >>>>>>>> Any suggestions ? >>>>>>>> >>>>>>>> Thanks. >>>>>>>> --Prashant From rcritten at redhat.com Tue Mar 31 14:28:11 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 31 Mar 2015 10:28:11 -0400 Subject: [Freeipa-users] Migration mode fun and confusion In-Reply-To: <551AA5DF.3090403@redhat.com> References: <551AA354.2090706@gmail.com> <551AA5DF.3090403@redhat.com> Message-ID: <551AAEFB.1070800@redhat.com> Dmitri Pal wrote: > On 03/31/2015 09:38 AM, Janelle wrote: >> Hello again, >> >> Is this a feature or a bug? >> >> Migration mode - works fine the first time. However, if you need to >> run it a second time because someone added either new users or groups >> to your LDAP config and you want to bring those over, if you re-run >> migration, it indeed brings all the new users over, but NOT their >> secondary groups, only primary. And even if you have overwrite of the >> GID option set. >> >> Would this be expected for some reason that I may be missing, or is it >> a bug? >> >> Thank you >> ~J >> > Let be know if I get you right. > > Setup: > - Old LDAP server > - IPA > > Users are migrated from LDAP to IPA using migrate-ds. > Everything works as expected > Now you add users to LDAP and put them into some groups (that were > already been migrated the first time, right?) > You run migrate-ds again and the new users are migrated but group > membership is lost. > > Is this the scenario? > If yes, looks like a bug. I agree. IIRC it only looks at new entries, not at changes to existing entries (this is migration after all, not sync). Changes in group membership are overlooked. Bringing in new users and looking up their groups probably wouldn't be a big deal. Re-syncing all group memberships would likely be VERY expensive. rob From jbaird at follett.com Tue Mar 31 14:29:41 2015 From: jbaird at follett.com (Baird, Josh) Date: Tue, 31 Mar 2015 14:29:41 +0000 Subject: [Freeipa-users] freeipa 4.x packages for RHEL? In-Reply-To: References: Message-ID: FreeIPA 4 is currently available in RHEL 7.1. Josh From: freeipa-users-bounces at redhat.com [mailto:freeipa-users-bounces at redhat.com] On Behalf Of Steve Neuharth Sent: Tuesday, March 31, 2015 10:02 AM To: freeipa-users at redhat.com Subject: [Freeipa-users] freeipa 4.x packages for RHEL? Hello, We're currently running RHEL in production and would love to be using all the goodness that is FreeIPA 4 including certmonger for certificate management. I don't see any mention of 4.x packages available for RHEL in the mailing lists and I have run into problems using the 3.3 client packages on a 4.x realm. When will 4.x packages be available for RHEL? --steve -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Tue Mar 31 14:38:22 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 16:38:22 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <551AAE2C.8070606@redhat.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> Message-ID: True, but we have some extra later between which does the cli command not usable (at least for the moment) I already know how to share the key's among all servers, that works fine, IPA/Apache/Kerberos only doesn't like the other hostname (loadbalancer), or the client doesn't understand it. So fixing this saves me really much more time than doing the another way. Thanks! Matt 2015-03-31 16:24 GMT+02:00 Petr Spacek : > On 31.3.2015 16:10, Matt . wrote: >> HI Petr, >> >> We had a several of reasons why we did that. We wanted to use one >> language for that, and also have formatted returns. There was also >> some security issue which came up. > > I would be very interested in the security reason. If you see any problem with > 'ipa' command or FreeIPA API please send me a private e-mail or contact > secalert at redhat.com directly. > >> I could ask you, why does IPA json itself ? if you see what it posts >> and what it gets back as result it makes it much more clear in >> development. > > I do not understand the question, sorry. > > If you want to see what 'ipa' command does run it with '-vv' parameter: > $ ipa -vv user-find > > It will print JSON request and reply: > ipa: INFO: Request: { > "id": 0, > "method": "user_find", > "params": [ > [ > null > ], > { > "all": false, > "no_members": false, > "pkey_only": false, > "raw": false, > "version": "2.115", > "whoami": false > } > ] > } > ipa: INFO: Response: { > "error": null, > "id": 0, > "principal": "admin at IPA.EXAMPLE", > "result": { > "count": 2, > "result": [ > { > "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > "gidnumber": [ > "1381000000" > ], > ... > > >> HTTP loadbalancing is not difficult at all, as we post to the >> webserver I need to have that part only auth right. We do more very >> specific loadbalancing stuff and this is the most easy one as it's >> only webserver forward, but IPA/Kerberos has an issue with the >> principal it seems... it cannot be hard to make that accepted I would >> say. > > If you insist on Kerberos servers behind a load balancer... you will need to > somehow share the Kerberos key among all servers. I will defer that to > Kerberos experts here. > >> I'm still looking for solutions :) > > Sure, but you will save a lot of time and nerves if you simply call 'ipa' > command :-) > > Have a nice day! > > Petr^2 Spacek > >> Cheers, >> >> Matt >> >> 2015-03-31 15:58 GMT+02:00 Petr Spacek : >>> On 31.3.2015 15:23, Matt . wrote: >>>> Hi Petr, >>>> >>>> We discussed that before indeed, but SRV is not usable in this case. >>>> >>>> My clients are just webservers (apache) doing some executes of CURL >>>> commands to ipa/json, actually the same commands as the webgui does >>>> using json, but we curl it. >>>> >>>> Do you have a better view now ? >>> >>> Yes. If you have seen the previous discussion then you know that it will be >>> pretty difficult to do this kind of load balancing. >>> >>> Why are you not using 'ipa' command or Python API we have instead? Why to use >>> CURL and make things more complex? >>> >>> Petr^2 Spacek >>> >>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : >>>>> On 31.3.2015 14:35, Matt . wrote: >>>>>> Hi Petr, >>>>>> >>>>>> As this is not my topic it's for me quite "simple". >>>>>> >>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. >>>>>> >>>>>> i have >>>>>> >>>>>> ldap-01.domain.tld (ipa1) >>>>>> ldap-01.domain.tld (ipa2) >>>>>> >>>>>> and my loadbalancer is ldap.domain.tld >>>>>> >>>>>> ldap requests over a loadbalancer are quite simple and working, but >>>>>> the json part is more difficult because of the ticket and the dns >>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a >>>>>> http/ldap.domain.tld service on the ipa server. >>>>>> >>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. >>>>>> >>>>>> Is this enough information for you ? >>>>> >>>>> Well, I still do not understand the use case. What are your clients? Are you >>>>> using 'ipa' command to do something? Or some other clients? >>>>> >>>>> Usually the best thing is to use DNS SRV records because it works even with >>>>> geographically distributed clusters and does not have single point of failure >>>>> (the load balancer). >>>>> >>>>> This requires clients with support for DNS SRV but if your machines are using >>>>> SSSD then you do not need to change anything and it should just work. >>>>> >>>>> That is why I'm asking for the use case :-) >>>>> >>>>> Petr^2 Spacek >>>>> >>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >>>>>>> On 31.3.2015 14:02, Matt . wrote: >>>>>>>> HI Phasant, >>>>>>>> >>>>>>>> Check my mailings about it, it's not easy at least the kerberos part >>>>>>>> not, SRV records are used for that normally. >>>>>>>> >>>>>>>> Are you talking about the webgui or the ldap part ? >>>>>>> >>>>>>> I would recommend you to step back and describe use-case you have in mind. It >>>>>>> is important for us to understand to your use-case to propose optimal solution. >>>>>>> >>>>>>> Petr^2 Spacek >>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> Matt >>>>>>>> >>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >>>>>>>>> balancer, specifically Amazon ELB. >>>>>>>>> >>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >>>>>>>>> there is more to it than just this file. >>>>>>>>> >>>>>>>>> Any suggestions ? >>>>>>>>> >>>>>>>>> Thanks. >>>>>>>>> --Prashant From sbose at redhat.com Tue Mar 31 14:40:49 2015 From: sbose at redhat.com (Sumit Bose) Date: Tue, 31 Mar 2015 16:40:49 +0200 Subject: [Freeipa-users] Troubleshooting SSO In-Reply-To: References: <20150330145542.GQ4696@redhat.com> <20150330150829.GR4696@redhat.com> <5519723D.5060704@redhat.com> <551A3725.10602@redhat.com> <20150331073047.GG8895@p.redhat.com> Message-ID: <20150331144049.GM8895@p.redhat.com> On Tue, Mar 31, 2015 at 10:02:37AM -0400, Gould, Joshua wrote: > Klist in Windows showed one ticket for the IPA domain. > > #0> Client: adm-faru03 @ test.osuwmc > Server: krbtgt/UNIX.TEST.OSUWMC @ TEST.OSUWMC > KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 > Ticket Flags 0x40a40000 -> forward able renewable pre_authent > ok_as_delegate > Start Time: 3/31/2015: 9:29:25 (local) > End Time: 3/31/2015: 15:28:22 (local) > Session Key Type: AES-256-CTS-HMAC-SHA1-96 The means that you do not have a ticket for the IPA client. Please make sure you use 'mid-ipa-vp01.unix.test.osuwmc' as hostname with putty. Since the AD DC gave you the cross-realm TGT (the ticket you've shown above) I would expect that you Windows client has issues resolving a KDC in the IPA domain. Please check on the Windows client with the nslookup utility you DNS SRV records like _kerberos._tcp.dc._msdcs.unix.test.osuwmc and _kerberos._tcp.unix.test.osuwmc can be resolved. > > IPA and SSSD are: > ipa-server.x86_64 > 4.1.0-18.el7_1.3 > sssd.x86_64 > 1.12.2-58.el7_1.6.1 > > Kinit adm-faru03 at TEST.OSUWMC was telling. Once it reported ?kinit: KDC > reply did not match expectations while getting initial credentials?. We > waited a minute or two (were discussing results) and tried again just > adding the -V flag and it worked. > > Kvno host/mid-ipa-vp01.unix.test.osuwmc at UNIX.TEST.OSUWMC = 2 > > Verbose logging in putty gave the following error: > Which errors do you see when using ssh in the IPA client after calling kinit? Or is it working in this case? bye, Sumit > > On 3/31/15, 3:30 AM, "Sumit Bose" wrote: > > > > >Can you do the follwoing checks: > > > >Can you check by calling klist in a Windows Command window if you got > > > > > >a proper host/... ticket for the IPA host? > > > > > > > > > > > >What version of IPA and SSSD are you using. > > > > > > > > > > > >Can you check if the following works on a IPA host: > > > > > > > > > > > >kinit adm-faru03 at TEST.OSUWMC > > > > > >kvno host/name.of.the.ipa-client.to.login at IPA.REALM > > > > > >ssh -v -l adm-faru03 at test.osuwmc name.of.the.ipa-client.to.login > > > > > > From janellenicole80 at gmail.com Tue Mar 31 14:50:50 2015 From: janellenicole80 at gmail.com (Janelle) Date: Tue, 31 Mar 2015 07:50:50 -0700 Subject: [Freeipa-users] Migration mode fun and confusion In-Reply-To: <551AA5DF.3090403@redhat.com> References: <551AA354.2090706@gmail.com> <551AA5DF.3090403@redhat.com> Message-ID: <551AB44A.3030108@gmail.com> On 3/31/15 6:49 AM, Dmitri Pal wrote: > On 03/31/2015 09:38 AM, Janelle wrote: >> Hello again, >> >> Is this a feature or a bug? >> >> Migration mode - works fine the first time. However, if you need to >> run it a second time because someone added either new users or groups >> to your LDAP config and you want to bring those over, if you re-run >> migration, it indeed brings all the new users over, but NOT their >> secondary groups, only primary. And even if you have overwrite of the >> GID option set. >> >> Would this be expected for some reason that I may be missing, or is >> it a bug? >> >> Thank you >> ~J >> > Let be know if I get you right. That's it exactly. Ok - Bug. :-) > > Setup: > - Old LDAP server > - IPA > > Users are migrated from LDAP to IPA using migrate-ds. > Everything works as expected > Now you add users to LDAP and put them into some groups (that were > already been migrated the first time, right?) > You run migrate-ds again and the new users are migrated but group > membership is lost. > > Is this the scenario? > If yes, looks like a bug. > > From dpal at redhat.com Tue Mar 31 15:07:56 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 31 Mar 2015 11:07:56 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> Message-ID: <551AB84C.6080004@redhat.com> On 03/31/2015 10:38 AM, Matt . wrote: > True, but we have some extra later between which does the cli command > not usable (at least for the moment) > > I already know how to share the key's among all servers, that works > fine, IPA/Apache/Kerberos only doesn't like the other hostname > (loadbalancer), or the client doesn't understand it. > > So fixing this saves me really much more time than doing the another way. Kerberos is not load balancer friendly. It is something that is a known property of Kerberos. I remember MIT mentioning something that they did or might do to help with that so it might make sense to ask this question on the MIT Kerberos user list. > > Thanks! > > Matt > > 2015-03-31 16:24 GMT+02:00 Petr Spacek : >> On 31.3.2015 16:10, Matt . wrote: >>> HI Petr, >>> >>> We had a several of reasons why we did that. We wanted to use one >>> language for that, and also have formatted returns. There was also >>> some security issue which came up. >> I would be very interested in the security reason. If you see any problem with >> 'ipa' command or FreeIPA API please send me a private e-mail or contact >> secalert at redhat.com directly. >> >>> I could ask you, why does IPA json itself ? if you see what it posts >>> and what it gets back as result it makes it much more clear in >>> development. >> I do not understand the question, sorry. >> >> If you want to see what 'ipa' command does run it with '-vv' parameter: >> $ ipa -vv user-find >> >> It will print JSON request and reply: >> ipa: INFO: Request: { >> "id": 0, >> "method": "user_find", >> "params": [ >> [ >> null >> ], >> { >> "all": false, >> "no_members": false, >> "pkey_only": false, >> "raw": false, >> "version": "2.115", >> "whoami": false >> } >> ] >> } >> ipa: INFO: Response: { >> "error": null, >> "id": 0, >> "principal": "admin at IPA.EXAMPLE", >> "result": { >> "count": 2, >> "result": [ >> { >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", >> "gidnumber": [ >> "1381000000" >> ], >> ... >> >> >>> HTTP loadbalancing is not difficult at all, as we post to the >>> webserver I need to have that part only auth right. We do more very >>> specific loadbalancing stuff and this is the most easy one as it's >>> only webserver forward, but IPA/Kerberos has an issue with the >>> principal it seems... it cannot be hard to make that accepted I would >>> say. >> If you insist on Kerberos servers behind a load balancer... you will need to >> somehow share the Kerberos key among all servers. I will defer that to >> Kerberos experts here. >> >>> I'm still looking for solutions :) >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' >> command :-) >> >> Have a nice day! >> >> Petr^2 Spacek >> >>> Cheers, >>> >>> Matt >>> >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : >>>> On 31.3.2015 15:23, Matt . wrote: >>>>> Hi Petr, >>>>> >>>>> We discussed that before indeed, but SRV is not usable in this case. >>>>> >>>>> My clients are just webservers (apache) doing some executes of CURL >>>>> commands to ipa/json, actually the same commands as the webgui does >>>>> using json, but we curl it. >>>>> >>>>> Do you have a better view now ? >>>> Yes. If you have seen the previous discussion then you know that it will be >>>> pretty difficult to do this kind of load balancing. >>>> >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use >>>> CURL and make things more complex? >>>> >>>> Petr^2 Spacek >>>> >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : >>>>>> On 31.3.2015 14:35, Matt . wrote: >>>>>>> Hi Petr, >>>>>>> >>>>>>> As this is not my topic it's for me quite "simple". >>>>>>> >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. >>>>>>> >>>>>>> i have >>>>>>> >>>>>>> ldap-01.domain.tld (ipa1) >>>>>>> ldap-01.domain.tld (ipa2) >>>>>>> >>>>>>> and my loadbalancer is ldap.domain.tld >>>>>>> >>>>>>> ldap requests over a loadbalancer are quite simple and working, but >>>>>>> the json part is more difficult because of the ticket and the dns >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a >>>>>>> http/ldap.domain.tld service on the ipa server. >>>>>>> >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. >>>>>>> >>>>>>> Is this enough information for you ? >>>>>> Well, I still do not understand the use case. What are your clients? Are you >>>>>> using 'ipa' command to do something? Or some other clients? >>>>>> >>>>>> Usually the best thing is to use DNS SRV records because it works even with >>>>>> geographically distributed clusters and does not have single point of failure >>>>>> (the load balancer). >>>>>> >>>>>> This requires clients with support for DNS SRV but if your machines are using >>>>>> SSSD then you do not need to change anything and it should just work. >>>>>> >>>>>> That is why I'm asking for the use case :-) >>>>>> >>>>>> Petr^2 Spacek >>>>>> >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >>>>>>>> On 31.3.2015 14:02, Matt . wrote: >>>>>>>>> HI Phasant, >>>>>>>>> >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part >>>>>>>>> not, SRV records are used for that normally. >>>>>>>>> >>>>>>>>> Are you talking about the webgui or the ldap part ? >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It >>>>>>>> is important for us to understand to your use-case to propose optimal solution. >>>>>>>> >>>>>>>> Petr^2 Spacek >>>>>>>> >>>>>>>>> Cheers, >>>>>>>>> >>>>>>>>> Matt >>>>>>>>> >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >>>>>>>>>> Hi, >>>>>>>>>> >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >>>>>>>>>> balancer, specifically Amazon ELB. >>>>>>>>>> >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >>>>>>>>>> there is more to it than just this file. >>>>>>>>>> >>>>>>>>>> Any suggestions ? >>>>>>>>>> >>>>>>>>>> Thanks. >>>>>>>>>> --Prashant -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From dpal at redhat.com Tue Mar 31 15:09:20 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 31 Mar 2015 11:09:20 -0400 Subject: [Freeipa-users] Migration mode fun and confusion In-Reply-To: <551AB44A.3030108@gmail.com> References: <551AA354.2090706@gmail.com> <551AA5DF.3090403@redhat.com> <551AB44A.3030108@gmail.com> Message-ID: <551AB8A0.7010709@redhat.com> On 03/31/2015 10:50 AM, Janelle wrote: > > > On 3/31/15 6:49 AM, Dmitri Pal wrote: >> On 03/31/2015 09:38 AM, Janelle wrote: >>> Hello again, >>> >>> Is this a feature or a bug? >>> >>> Migration mode - works fine the first time. However, if you need to >>> run it a second time because someone added either new users or >>> groups to your LDAP config and you want to bring those over, if you >>> re-run migration, it indeed brings all the new users over, but NOT >>> their secondary groups, only primary. And even if you have overwrite >>> of the GID option set. >>> >>> Would this be expected for some reason that I may be missing, or is >>> it a bug? >>> >>> Thank you >>> ~J >>> >> Let be know if I get you right. > That's it exactly. > Ok - Bug. Looks like it. You know what to do :-) > :-) > >> >> Setup: >> - Old LDAP server >> - IPA >> >> Users are migrated from LDAP to IPA using migrate-ds. >> Everything works as expected >> Now you add users to LDAP and put them into some groups (that were >> already been migrated the first time, right?) >> You run migrate-ds again and the new users are migrated but group >> membership is lost. >> >> Is this the scenario? >> If yes, looks like a bug. >> >> > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From bpk678 at gmail.com Tue Mar 31 15:41:48 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 31 Mar 2015 11:41:48 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <551AB84C.6080004@redhat.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> Message-ID: <1427816508.24621.14.camel@desktop.bpk2.com> On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > On 03/31/2015 10:38 AM, Matt . wrote: > > True, but we have some extra later between which does the cli command > > not usable (at least for the moment) > > > > I already know how to share the key's among all servers, that works > > fine, IPA/Apache/Kerberos only doesn't like the other hostname > > (loadbalancer), or the client doesn't understand it. > > > > So fixing this saves me really much more time than doing the another way. > > Kerberos is not load balancer friendly. It is something that is a known > property of Kerberos. > I remember MIT mentioning something that they did or might do to help > with that so it might make sense to ask this question on the MIT > Kerberos user list. > > > > > Thanks! > > > > Matt > > > > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > >> On 31.3.2015 16:10, Matt . wrote: > >>> HI Petr, > >>> > >>> We had a several of reasons why we did that. We wanted to use one > >>> language for that, and also have formatted returns. There was also > >>> some security issue which came up. > >> I would be very interested in the security reason. If you see any problem with > >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > >> secalert at redhat.com directly. > >> > >>> I could ask you, why does IPA json itself ? if you see what it posts > >>> and what it gets back as result it makes it much more clear in > >>> development. > >> I do not understand the question, sorry. > >> > >> If you want to see what 'ipa' command does run it with '-vv' parameter: > >> $ ipa -vv user-find > >> > >> It will print JSON request and reply: > >> ipa: INFO: Request: { > >> "id": 0, > >> "method": "user_find", > >> "params": [ > >> [ > >> null > >> ], > >> { > >> "all": false, > >> "no_members": false, > >> "pkey_only": false, > >> "raw": false, > >> "version": "2.115", > >> "whoami": false > >> } > >> ] > >> } > >> ipa: INFO: Response: { > >> "error": null, > >> "id": 0, > >> "principal": "admin at IPA.EXAMPLE", > >> "result": { > >> "count": 2, > >> "result": [ > >> { > >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > >> "gidnumber": [ > >> "1381000000" > >> ], > >> ... > >> > >> > >>> HTTP loadbalancing is not difficult at all, as we post to the > >>> webserver I need to have that part only auth right. We do more very > >>> specific loadbalancing stuff and this is the most easy one as it's > >>> only webserver forward, but IPA/Kerberos has an issue with the > >>> principal it seems... it cannot be hard to make that accepted I would > >>> say. > >> If you insist on Kerberos servers behind a load balancer... you will need to > >> somehow share the Kerberos key among all servers. I will defer that to > >> Kerberos experts here. > >> > >>> I'm still looking for solutions :) > >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' > >> command :-) > >> > >> Have a nice day! > >> > >> Petr^2 Spacek > >> > >>> Cheers, > >>> > >>> Matt > >>> > >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : > >>>> On 31.3.2015 15:23, Matt . wrote: > >>>>> Hi Petr, > >>>>> > >>>>> We discussed that before indeed, but SRV is not usable in this case. > >>>>> > >>>>> My clients are just webservers (apache) doing some executes of CURL > >>>>> commands to ipa/json, actually the same commands as the webgui does > >>>>> using json, but we curl it. > >>>>> > >>>>> Do you have a better view now ? > >>>> Yes. If you have seen the previous discussion then you know that it will be > >>>> pretty difficult to do this kind of load balancing. > >>>> > >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use > >>>> CURL and make things more complex? > >>>> > >>>> Petr^2 Spacek > >>>> > >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : > >>>>>> On 31.3.2015 14:35, Matt . wrote: > >>>>>>> Hi Petr, > >>>>>>> > >>>>>>> As this is not my topic it's for me quite "simple". > >>>>>>> > >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. > >>>>>>> > >>>>>>> i have > >>>>>>> > >>>>>>> ldap-01.domain.tld (ipa1) > >>>>>>> ldap-01.domain.tld (ipa2) > >>>>>>> > >>>>>>> and my loadbalancer is ldap.domain.tld > >>>>>>> > >>>>>>> ldap requests over a loadbalancer are quite simple and working, but > >>>>>>> the json part is more difficult because of the ticket and the dns > >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a > >>>>>>> http/ldap.domain.tld service on the ipa server. > >>>>>>> > >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to > >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld > >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. > >>>>>>> > >>>>>>> Is this enough information for you ? > >>>>>> Well, I still do not understand the use case. What are your clients? Are you > >>>>>> using 'ipa' command to do something? Or some other clients? > >>>>>> > >>>>>> Usually the best thing is to use DNS SRV records because it works even with > >>>>>> geographically distributed clusters and does not have single point of failure > >>>>>> (the load balancer). > >>>>>> > >>>>>> This requires clients with support for DNS SRV but if your machines are using > >>>>>> SSSD then you do not need to change anything and it should just work. > >>>>>> > >>>>>> That is why I'm asking for the use case :-) > >>>>>> > >>>>>> Petr^2 Spacek > >>>>>> > >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : > >>>>>>>> On 31.3.2015 14:02, Matt . wrote: > >>>>>>>>> HI Phasant, > >>>>>>>>> > >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part > >>>>>>>>> not, SRV records are used for that normally. > >>>>>>>>> > >>>>>>>>> Are you talking about the webgui or the ldap part ? > >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It > >>>>>>>> is important for us to understand to your use-case to propose optimal solution. > >>>>>>>> > >>>>>>>> Petr^2 Spacek > >>>>>>>> > >>>>>>>>> Cheers, > >>>>>>>>> > >>>>>>>>> Matt > >>>>>>>>> > >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : > >>>>>>>>>> Hi, > >>>>>>>>>> > >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load > >>>>>>>>>> balancer, specifically Amazon ELB. > >>>>>>>>>> > >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like > >>>>>>>>>> there is more to it than just this file. > >>>>>>>>>> > >>>>>>>>>> Any suggestions ? > >>>>>>>>>> > >>>>>>>>>> Thanks. > >>>>>>>>>> --Prashant > > > -- > Thank you, > Dmitri Pal > > Sr. Engineering Manager IdM portfolio > Red Hat, Inc. > kerberos is load balancer friendly, if you pet it nicely. you generate a principal for the VIP. you then create a keytab for the VIP. you distribute the keytab via SCP (or other secure method) to all load balanced pool members. you must distribute the same exact keytab to all devices. the KVNO for the VIP principal must match in all copies put on the pool members. use "klist -Kket /path/to/file.keytab" to validate this on all pool members. there are additional steps you may want to take, in order to add the individual principal(s) to the same keytab, so that you can access the pool members themselves (not via the VIP). this requires that you distribute the keytab as above, and then add the individual principals to the local copy of the keytab file. example: you have created the principal ldap/ldap.domain.tld for your VIP you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab you have copied the keytab file ~/ldap.keytab to server1, server2 and server3 as /etc/ldap.keytab you ssh to server1 and run kadmin. you then add a principal ldap/server1.domain.tld you then add the principal ldap/server1.domain.tld to the already existing keytab /etc/ldap.keytab. quit kadmin when you run "klist -Kket /etc/ldap.keytab" you should see two principals in it. the VIP name and the hostname. lather, rinse, repeat for all servers. keep in mind the administrative overhead of changing names of servers or VIPs. there are other tricks for doing kerberos stuff. i use the same VIP, but different ports in order to access an individual host/service behind the load balancer. this works because the name (of the VIP) stays the same and i just point a different front end port to an individual backend device/port. From yamakasi.014 at gmail.com Tue Mar 31 15:51:35 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 17:51:35 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427816508.24621.14.camel@desktop.bpk2.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> Message-ID: Hi Brendan, Yes thanks for your great explanation, I have done that indeed. But in some strange way, with only a 401 in access_log of apache I get a Non valid ticket when I connect through my loadbalancer. I don't go "by" my loadbalancer but through it (NAT) or should it go "by/next" to it ? I think we can get this fixed :) Thanks! Matt 2015-03-31 17:41 GMT+02:00 Brendan Kearney : > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: >> On 03/31/2015 10:38 AM, Matt . wrote: >> > True, but we have some extra later between which does the cli command >> > not usable (at least for the moment) >> > >> > I already know how to share the key's among all servers, that works >> > fine, IPA/Apache/Kerberos only doesn't like the other hostname >> > (loadbalancer), or the client doesn't understand it. >> > >> > So fixing this saves me really much more time than doing the another way. >> >> Kerberos is not load balancer friendly. It is something that is a known >> property of Kerberos. >> I remember MIT mentioning something that they did or might do to help >> with that so it might make sense to ask this question on the MIT >> Kerberos user list. >> >> > >> > Thanks! >> > >> > Matt >> > >> > 2015-03-31 16:24 GMT+02:00 Petr Spacek : >> >> On 31.3.2015 16:10, Matt . wrote: >> >>> HI Petr, >> >>> >> >>> We had a several of reasons why we did that. We wanted to use one >> >>> language for that, and also have formatted returns. There was also >> >>> some security issue which came up. >> >> I would be very interested in the security reason. If you see any problem with >> >> 'ipa' command or FreeIPA API please send me a private e-mail or contact >> >> secalert at redhat.com directly. >> >> >> >>> I could ask you, why does IPA json itself ? if you see what it posts >> >>> and what it gets back as result it makes it much more clear in >> >>> development. >> >> I do not understand the question, sorry. >> >> >> >> If you want to see what 'ipa' command does run it with '-vv' parameter: >> >> $ ipa -vv user-find >> >> >> >> It will print JSON request and reply: >> >> ipa: INFO: Request: { >> >> "id": 0, >> >> "method": "user_find", >> >> "params": [ >> >> [ >> >> null >> >> ], >> >> { >> >> "all": false, >> >> "no_members": false, >> >> "pkey_only": false, >> >> "raw": false, >> >> "version": "2.115", >> >> "whoami": false >> >> } >> >> ] >> >> } >> >> ipa: INFO: Response: { >> >> "error": null, >> >> "id": 0, >> >> "principal": "admin at IPA.EXAMPLE", >> >> "result": { >> >> "count": 2, >> >> "result": [ >> >> { >> >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", >> >> "gidnumber": [ >> >> "1381000000" >> >> ], >> >> ... >> >> >> >> >> >>> HTTP loadbalancing is not difficult at all, as we post to the >> >>> webserver I need to have that part only auth right. We do more very >> >>> specific loadbalancing stuff and this is the most easy one as it's >> >>> only webserver forward, but IPA/Kerberos has an issue with the >> >>> principal it seems... it cannot be hard to make that accepted I would >> >>> say. >> >> If you insist on Kerberos servers behind a load balancer... you will need to >> >> somehow share the Kerberos key among all servers. I will defer that to >> >> Kerberos experts here. >> >> >> >>> I'm still looking for solutions :) >> >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' >> >> command :-) >> >> >> >> Have a nice day! >> >> >> >> Petr^2 Spacek >> >> >> >>> Cheers, >> >>> >> >>> Matt >> >>> >> >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : >> >>>> On 31.3.2015 15:23, Matt . wrote: >> >>>>> Hi Petr, >> >>>>> >> >>>>> We discussed that before indeed, but SRV is not usable in this case. >> >>>>> >> >>>>> My clients are just webservers (apache) doing some executes of CURL >> >>>>> commands to ipa/json, actually the same commands as the webgui does >> >>>>> using json, but we curl it. >> >>>>> >> >>>>> Do you have a better view now ? >> >>>> Yes. If you have seen the previous discussion then you know that it will be >> >>>> pretty difficult to do this kind of load balancing. >> >>>> >> >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use >> >>>> CURL and make things more complex? >> >>>> >> >>>> Petr^2 Spacek >> >>>> >> >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : >> >>>>>> On 31.3.2015 14:35, Matt . wrote: >> >>>>>>> Hi Petr, >> >>>>>>> >> >>>>>>> As this is not my topic it's for me quite "simple". >> >>>>>>> >> >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. >> >>>>>>> >> >>>>>>> i have >> >>>>>>> >> >>>>>>> ldap-01.domain.tld (ipa1) >> >>>>>>> ldap-01.domain.tld (ipa2) >> >>>>>>> >> >>>>>>> and my loadbalancer is ldap.domain.tld >> >>>>>>> >> >>>>>>> ldap requests over a loadbalancer are quite simple and working, but >> >>>>>>> the json part is more difficult because of the ticket and the dns >> >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a >> >>>>>>> http/ldap.domain.tld service on the ipa server. >> >>>>>>> >> >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >> >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >> >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. >> >>>>>>> >> >>>>>>> Is this enough information for you ? >> >>>>>> Well, I still do not understand the use case. What are your clients? Are you >> >>>>>> using 'ipa' command to do something? Or some other clients? >> >>>>>> >> >>>>>> Usually the best thing is to use DNS SRV records because it works even with >> >>>>>> geographically distributed clusters and does not have single point of failure >> >>>>>> (the load balancer). >> >>>>>> >> >>>>>> This requires clients with support for DNS SRV but if your machines are using >> >>>>>> SSSD then you do not need to change anything and it should just work. >> >>>>>> >> >>>>>> That is why I'm asking for the use case :-) >> >>>>>> >> >>>>>> Petr^2 Spacek >> >>>>>> >> >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >> >>>>>>>> On 31.3.2015 14:02, Matt . wrote: >> >>>>>>>>> HI Phasant, >> >>>>>>>>> >> >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part >> >>>>>>>>> not, SRV records are used for that normally. >> >>>>>>>>> >> >>>>>>>>> Are you talking about the webgui or the ldap part ? >> >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It >> >>>>>>>> is important for us to understand to your use-case to propose optimal solution. >> >>>>>>>> >> >>>>>>>> Petr^2 Spacek >> >>>>>>>> >> >>>>>>>>> Cheers, >> >>>>>>>>> >> >>>>>>>>> Matt >> >>>>>>>>> >> >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >> >>>>>>>>>> Hi, >> >>>>>>>>>> >> >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >> >>>>>>>>>> balancer, specifically Amazon ELB. >> >>>>>>>>>> >> >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >> >>>>>>>>>> there is more to it than just this file. >> >>>>>>>>>> >> >>>>>>>>>> Any suggestions ? >> >>>>>>>>>> >> >>>>>>>>>> Thanks. >> >>>>>>>>>> --Prashant >> >> >> -- >> Thank you, >> Dmitri Pal >> >> Sr. Engineering Manager IdM portfolio >> Red Hat, Inc. >> > > kerberos is load balancer friendly, if you pet it nicely. > > you generate a principal for the VIP. you then create a keytab for the > VIP. you distribute the keytab via SCP (or other secure method) to all > load balanced pool members. you must distribute the same exact keytab > to all devices. the KVNO for the VIP principal must match in all copies > put on the pool members. use "klist -Kket /path/to/file.keytab" to > validate this on all pool members. > > there are additional steps you may want to take, in order to add the > individual principal(s) to the same keytab, so that you can access the > pool members themselves (not via the VIP). this requires that you > distribute the keytab as above, and then add the individual principals > to the local copy of the keytab file. > > example: > > you have created the principal ldap/ldap.domain.tld for your VIP > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab > you have copied the keytab file ~/ldap.keytab to server1, server2 and > server3 as /etc/ldap.keytab > > you ssh to server1 and run kadmin. > you then add a principal ldap/server1.domain.tld > you then add the principal ldap/server1.domain.tld to the already > existing keytab /etc/ldap.keytab. > quit kadmin > > when you run "klist -Kket /etc/ldap.keytab" you should see two > principals in it. the VIP name and the hostname. > > lather, rinse, repeat for all servers. > > keep in mind the administrative overhead of changing names of servers or > VIPs. > > there are other tricks for doing kerberos stuff. i use the same VIP, > but different ports in order to access an individual host/service behind > the load balancer. this works because the name (of the VIP) stays the > same and i just point a different front end port to an individual > backend device/port. > > -- > 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 bpk678 at gmail.com Tue Mar 31 15:58:53 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 31 Mar 2015 11:58:53 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> Message-ID: <1427817533.24621.18.camel@desktop.bpk2.com> On Tue, 2015-03-31 at 17:51 +0200, Matt . wrote: > Hi Brendan, > > Yes thanks for your great explanation, I have done that indeed. But in > some strange way, with only a 401 in access_log of apache I get a Non > valid ticket when I connect through my loadbalancer. I don't go "by" > my loadbalancer but through it (NAT) or should it go "by/next" to it ? > > I think we can get this fixed :) > > Thanks! > > Matt > > 2015-03-31 17:41 GMT+02:00 Brendan Kearney : > > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > >> On 03/31/2015 10:38 AM, Matt . wrote: > >> > True, but we have some extra later between which does the cli command > >> > not usable (at least for the moment) > >> > > >> > I already know how to share the key's among all servers, that works > >> > fine, IPA/Apache/Kerberos only doesn't like the other hostname > >> > (loadbalancer), or the client doesn't understand it. > >> > > >> > So fixing this saves me really much more time than doing the another way. > >> > >> Kerberos is not load balancer friendly. It is something that is a known > >> property of Kerberos. > >> I remember MIT mentioning something that they did or might do to help > >> with that so it might make sense to ask this question on the MIT > >> Kerberos user list. > >> > >> > > >> > Thanks! > >> > > >> > Matt > >> > > >> > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > >> >> On 31.3.2015 16:10, Matt . wrote: > >> >>> HI Petr, > >> >>> > >> >>> We had a several of reasons why we did that. We wanted to use one > >> >>> language for that, and also have formatted returns. There was also > >> >>> some security issue which came up. > >> >> I would be very interested in the security reason. If you see any problem with > >> >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > >> >> secalert at redhat.com directly. > >> >> > >> >>> I could ask you, why does IPA json itself ? if you see what it posts > >> >>> and what it gets back as result it makes it much more clear in > >> >>> development. > >> >> I do not understand the question, sorry. > >> >> > >> >> If you want to see what 'ipa' command does run it with '-vv' parameter: > >> >> $ ipa -vv user-find > >> >> > >> >> It will print JSON request and reply: > >> >> ipa: INFO: Request: { > >> >> "id": 0, > >> >> "method": "user_find", > >> >> "params": [ > >> >> [ > >> >> null > >> >> ], > >> >> { > >> >> "all": false, > >> >> "no_members": false, > >> >> "pkey_only": false, > >> >> "raw": false, > >> >> "version": "2.115", > >> >> "whoami": false > >> >> } > >> >> ] > >> >> } > >> >> ipa: INFO: Response: { > >> >> "error": null, > >> >> "id": 0, > >> >> "principal": "admin at IPA.EXAMPLE", > >> >> "result": { > >> >> "count": 2, > >> >> "result": [ > >> >> { > >> >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > >> >> "gidnumber": [ > >> >> "1381000000" > >> >> ], > >> >> ... > >> >> > >> >> > >> >>> HTTP loadbalancing is not difficult at all, as we post to the > >> >>> webserver I need to have that part only auth right. We do more very > >> >>> specific loadbalancing stuff and this is the most easy one as it's > >> >>> only webserver forward, but IPA/Kerberos has an issue with the > >> >>> principal it seems... it cannot be hard to make that accepted I would > >> >>> say. > >> >> If you insist on Kerberos servers behind a load balancer... you will need to > >> >> somehow share the Kerberos key among all servers. I will defer that to > >> >> Kerberos experts here. > >> >> > >> >>> I'm still looking for solutions :) > >> >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' > >> >> command :-) > >> >> > >> >> Have a nice day! > >> >> > >> >> Petr^2 Spacek > >> >> > >> >>> Cheers, > >> >>> > >> >>> Matt > >> >>> > >> >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : > >> >>>> On 31.3.2015 15:23, Matt . wrote: > >> >>>>> Hi Petr, > >> >>>>> > >> >>>>> We discussed that before indeed, but SRV is not usable in this case. > >> >>>>> > >> >>>>> My clients are just webservers (apache) doing some executes of CURL > >> >>>>> commands to ipa/json, actually the same commands as the webgui does > >> >>>>> using json, but we curl it. > >> >>>>> > >> >>>>> Do you have a better view now ? > >> >>>> Yes. If you have seen the previous discussion then you know that it will be > >> >>>> pretty difficult to do this kind of load balancing. > >> >>>> > >> >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use > >> >>>> CURL and make things more complex? > >> >>>> > >> >>>> Petr^2 Spacek > >> >>>> > >> >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : > >> >>>>>> On 31.3.2015 14:35, Matt . wrote: > >> >>>>>>> Hi Petr, > >> >>>>>>> > >> >>>>>>> As this is not my topic it's for me quite "simple". > >> >>>>>>> > >> >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. > >> >>>>>>> > >> >>>>>>> i have > >> >>>>>>> > >> >>>>>>> ldap-01.domain.tld (ipa1) > >> >>>>>>> ldap-01.domain.tld (ipa2) > >> >>>>>>> > >> >>>>>>> and my loadbalancer is ldap.domain.tld > >> >>>>>>> > >> >>>>>>> ldap requests over a loadbalancer are quite simple and working, but > >> >>>>>>> the json part is more difficult because of the ticket and the dns > >> >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a > >> >>>>>>> http/ldap.domain.tld service on the ipa server. > >> >>>>>>> > >> >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to > >> >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld > >> >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. > >> >>>>>>> > >> >>>>>>> Is this enough information for you ? > >> >>>>>> Well, I still do not understand the use case. What are your clients? Are you > >> >>>>>> using 'ipa' command to do something? Or some other clients? > >> >>>>>> > >> >>>>>> Usually the best thing is to use DNS SRV records because it works even with > >> >>>>>> geographically distributed clusters and does not have single point of failure > >> >>>>>> (the load balancer). > >> >>>>>> > >> >>>>>> This requires clients with support for DNS SRV but if your machines are using > >> >>>>>> SSSD then you do not need to change anything and it should just work. > >> >>>>>> > >> >>>>>> That is why I'm asking for the use case :-) > >> >>>>>> > >> >>>>>> Petr^2 Spacek > >> >>>>>> > >> >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : > >> >>>>>>>> On 31.3.2015 14:02, Matt . wrote: > >> >>>>>>>>> HI Phasant, > >> >>>>>>>>> > >> >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part > >> >>>>>>>>> not, SRV records are used for that normally. > >> >>>>>>>>> > >> >>>>>>>>> Are you talking about the webgui or the ldap part ? > >> >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It > >> >>>>>>>> is important for us to understand to your use-case to propose optimal solution. > >> >>>>>>>> > >> >>>>>>>> Petr^2 Spacek > >> >>>>>>>> > >> >>>>>>>>> Cheers, > >> >>>>>>>>> > >> >>>>>>>>> Matt > >> >>>>>>>>> > >> >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : > >> >>>>>>>>>> Hi, > >> >>>>>>>>>> > >> >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load > >> >>>>>>>>>> balancer, specifically Amazon ELB. > >> >>>>>>>>>> > >> >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like > >> >>>>>>>>>> there is more to it than just this file. > >> >>>>>>>>>> > >> >>>>>>>>>> Any suggestions ? > >> >>>>>>>>>> > >> >>>>>>>>>> Thanks. > >> >>>>>>>>>> --Prashant > >> > >> > >> -- > >> Thank you, > >> Dmitri Pal > >> > >> Sr. Engineering Manager IdM portfolio > >> Red Hat, Inc. > >> > > > > kerberos is load balancer friendly, if you pet it nicely. > > > > you generate a principal for the VIP. you then create a keytab for the > > VIP. you distribute the keytab via SCP (or other secure method) to all > > load balanced pool members. you must distribute the same exact keytab > > to all devices. the KVNO for the VIP principal must match in all copies > > put on the pool members. use "klist -Kket /path/to/file.keytab" to > > validate this on all pool members. > > > > there are additional steps you may want to take, in order to add the > > individual principal(s) to the same keytab, so that you can access the > > pool members themselves (not via the VIP). this requires that you > > distribute the keytab as above, and then add the individual principals > > to the local copy of the keytab file. > > > > example: > > > > you have created the principal ldap/ldap.domain.tld for your VIP > > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab > > you have copied the keytab file ~/ldap.keytab to server1, server2 and > > server3 as /etc/ldap.keytab > > > > you ssh to server1 and run kadmin. > > you then add a principal ldap/server1.domain.tld > > you then add the principal ldap/server1.domain.tld to the already > > existing keytab /etc/ldap.keytab. > > quit kadmin > > > > when you run "klist -Kket /etc/ldap.keytab" you should see two > > principals in it. the VIP name and the hostname. > > > > lather, rinse, repeat for all servers. > > > > keep in mind the administrative overhead of changing names of servers or > > VIPs. > > > > there are other tricks for doing kerberos stuff. i use the same VIP, > > but different ports in order to access an individual host/service behind > > the load balancer. this works because the name (of the VIP) stays the > > same and i just point a different front end port to an individual > > backend device/port. > > > > -- > > 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 wireshark/tcpdump are your friends. run an unfiltered capture on the client and attempt the access. review the capture and see what is not working (hint, filter for "kerberos || ldap" in wireshark during your review). ldapwhoami should return info about your ID. klist after running the ldapwhoami should have an ldap ticket listed, along with your TGT and possibly others. From prasun.gera at gmail.com Tue Mar 31 16:04:20 2015 From: prasun.gera at gmail.com (Prasun Gera) Date: Tue, 31 Mar 2015 12:04:20 -0400 Subject: [Freeipa-users] Understanding the migration mode In-Reply-To: References: <55148136.8040003@redhat.com> <5514C804.4040207@redhat.com> <55156455.7090401@redhat.com> <5515C3DF.5020701@redhat.com> <551AA80F.5070807@redhat.com> Message-ID: I've figured it out. You are right. SSSD triggers key generation. For migrated clients though, since ypbind still runs and the NIS-plugin serves maps, they authenticate first using NIS before SSSD. If ypbind is stopped, it is forced to use SSSD, and then it triggers the migration. Thanks for persisting with this. It's pretty clear how it works now. On Tue, Mar 31, 2015 at 11:32 AM, Prasun Gera wrote: > > >> ? SSSD does not seem to be involved as user is found in the /etc/passwd >> and this SSSD should not do anything. >> >> It's not a local user. There's no entry in /etc/passwd. Here's the > relevant sssd log > > > sssd_ssh > > (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [sss_parse_name_for_domains] > (0x0200): name 'testuser2' matched without domain, user is testuser2 > (Tue Mar 31 03:50:41 2015) [sssd[ssh]] [client_recv] (0x0200): Client > disconnected! > (Tue Mar 31 03:53:17 2015) [sssd[ssh]] [sss_cmd_get_version] (0x0200): > Received client version [0]. > > sssd_pam > > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): domain: > ipadomain > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): user: > testuser2 > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): service: > sshd > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): tty: ssh > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): ruser: > not set > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): rhost: > host_ip > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): authtok > type: 0 > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): > newauthtok type: 0 > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): priv: 1 > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): cli_pid: > 23983 > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_print_data] (0x0100): logon > name: testuser2 > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dom_forwarder] (0x0100): > pam_dp_send_req returned 0 > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_dp_process_reply] (0x0100): > received: [0][ipadomain] > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): pam_reply > called with result [0]. > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [pam_reply] (0x0200): blen: 27 > (Tue Mar 31 03:53:54 2015) [sssd[pam]] [client_recv] (0x0200): Client > disconnected! > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Tue Mar 31 16:18:22 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 18:18:22 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427817533.24621.18.camel@desktop.bpk2.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427817533.24621.18.camel@desktop.bpk2.com> Message-ID: OK, that makes it even more clear. an ldapwhoami might be an issue. As this client is known on a different ldap server and I kinit to another ldap server. There is a reason for this as we have out office network and our deployment network. Users that manage are in the office ldap, user that are in deployment are in the deployment ldap. I do my kinit username at deployment.domain which works ok when I run my commands at ipa-01.deployment.domain. But when I want to do a ldapwhoami it tries to connect to the office ldap server which is not working of course. (I get a connection error atm, need to investigate as that server is running fine). Get the idea ? Thanks again! Matt 2015-03-31 17:58 GMT+02:00 Brendan Kearney : > On Tue, 2015-03-31 at 17:51 +0200, Matt . wrote: >> Hi Brendan, >> >> Yes thanks for your great explanation, I have done that indeed. But in >> some strange way, with only a 401 in access_log of apache I get a Non >> valid ticket when I connect through my loadbalancer. I don't go "by" >> my loadbalancer but through it (NAT) or should it go "by/next" to it ? >> >> I think we can get this fixed :) >> >> Thanks! >> >> Matt >> >> 2015-03-31 17:41 GMT+02:00 Brendan Kearney : >> > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: >> >> On 03/31/2015 10:38 AM, Matt . wrote: >> >> > True, but we have some extra later between which does the cli command >> >> > not usable (at least for the moment) >> >> > >> >> > I already know how to share the key's among all servers, that works >> >> > fine, IPA/Apache/Kerberos only doesn't like the other hostname >> >> > (loadbalancer), or the client doesn't understand it. >> >> > >> >> > So fixing this saves me really much more time than doing the another way. >> >> >> >> Kerberos is not load balancer friendly. It is something that is a known >> >> property of Kerberos. >> >> I remember MIT mentioning something that they did or might do to help >> >> with that so it might make sense to ask this question on the MIT >> >> Kerberos user list. >> >> >> >> > >> >> > Thanks! >> >> > >> >> > Matt >> >> > >> >> > 2015-03-31 16:24 GMT+02:00 Petr Spacek : >> >> >> On 31.3.2015 16:10, Matt . wrote: >> >> >>> HI Petr, >> >> >>> >> >> >>> We had a several of reasons why we did that. We wanted to use one >> >> >>> language for that, and also have formatted returns. There was also >> >> >>> some security issue which came up. >> >> >> I would be very interested in the security reason. If you see any problem with >> >> >> 'ipa' command or FreeIPA API please send me a private e-mail or contact >> >> >> secalert at redhat.com directly. >> >> >> >> >> >>> I could ask you, why does IPA json itself ? if you see what it posts >> >> >>> and what it gets back as result it makes it much more clear in >> >> >>> development. >> >> >> I do not understand the question, sorry. >> >> >> >> >> >> If you want to see what 'ipa' command does run it with '-vv' parameter: >> >> >> $ ipa -vv user-find >> >> >> >> >> >> It will print JSON request and reply: >> >> >> ipa: INFO: Request: { >> >> >> "id": 0, >> >> >> "method": "user_find", >> >> >> "params": [ >> >> >> [ >> >> >> null >> >> >> ], >> >> >> { >> >> >> "all": false, >> >> >> "no_members": false, >> >> >> "pkey_only": false, >> >> >> "raw": false, >> >> >> "version": "2.115", >> >> >> "whoami": false >> >> >> } >> >> >> ] >> >> >> } >> >> >> ipa: INFO: Response: { >> >> >> "error": null, >> >> >> "id": 0, >> >> >> "principal": "admin at IPA.EXAMPLE", >> >> >> "result": { >> >> >> "count": 2, >> >> >> "result": [ >> >> >> { >> >> >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", >> >> >> "gidnumber": [ >> >> >> "1381000000" >> >> >> ], >> >> >> ... >> >> >> >> >> >> >> >> >>> HTTP loadbalancing is not difficult at all, as we post to the >> >> >>> webserver I need to have that part only auth right. We do more very >> >> >>> specific loadbalancing stuff and this is the most easy one as it's >> >> >>> only webserver forward, but IPA/Kerberos has an issue with the >> >> >>> principal it seems... it cannot be hard to make that accepted I would >> >> >>> say. >> >> >> If you insist on Kerberos servers behind a load balancer... you will need to >> >> >> somehow share the Kerberos key among all servers. I will defer that to >> >> >> Kerberos experts here. >> >> >> >> >> >>> I'm still looking for solutions :) >> >> >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' >> >> >> command :-) >> >> >> >> >> >> Have a nice day! >> >> >> >> >> >> Petr^2 Spacek >> >> >> >> >> >>> Cheers, >> >> >>> >> >> >>> Matt >> >> >>> >> >> >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : >> >> >>>> On 31.3.2015 15:23, Matt . wrote: >> >> >>>>> Hi Petr, >> >> >>>>> >> >> >>>>> We discussed that before indeed, but SRV is not usable in this case. >> >> >>>>> >> >> >>>>> My clients are just webservers (apache) doing some executes of CURL >> >> >>>>> commands to ipa/json, actually the same commands as the webgui does >> >> >>>>> using json, but we curl it. >> >> >>>>> >> >> >>>>> Do you have a better view now ? >> >> >>>> Yes. If you have seen the previous discussion then you know that it will be >> >> >>>> pretty difficult to do this kind of load balancing. >> >> >>>> >> >> >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use >> >> >>>> CURL and make things more complex? >> >> >>>> >> >> >>>> Petr^2 Spacek >> >> >>>> >> >> >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : >> >> >>>>>> On 31.3.2015 14:35, Matt . wrote: >> >> >>>>>>> Hi Petr, >> >> >>>>>>> >> >> >>>>>>> As this is not my topic it's for me quite "simple". >> >> >>>>>>> >> >> >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. >> >> >>>>>>> >> >> >>>>>>> i have >> >> >>>>>>> >> >> >>>>>>> ldap-01.domain.tld (ipa1) >> >> >>>>>>> ldap-01.domain.tld (ipa2) >> >> >>>>>>> >> >> >>>>>>> and my loadbalancer is ldap.domain.tld >> >> >>>>>>> >> >> >>>>>>> ldap requests over a loadbalancer are quite simple and working, but >> >> >>>>>>> the json part is more difficult because of the ticket and the dns >> >> >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a >> >> >>>>>>> http/ldap.domain.tld service on the ipa server. >> >> >>>>>>> >> >> >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >> >> >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >> >> >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. >> >> >>>>>>> >> >> >>>>>>> Is this enough information for you ? >> >> >>>>>> Well, I still do not understand the use case. What are your clients? Are you >> >> >>>>>> using 'ipa' command to do something? Or some other clients? >> >> >>>>>> >> >> >>>>>> Usually the best thing is to use DNS SRV records because it works even with >> >> >>>>>> geographically distributed clusters and does not have single point of failure >> >> >>>>>> (the load balancer). >> >> >>>>>> >> >> >>>>>> This requires clients with support for DNS SRV but if your machines are using >> >> >>>>>> SSSD then you do not need to change anything and it should just work. >> >> >>>>>> >> >> >>>>>> That is why I'm asking for the use case :-) >> >> >>>>>> >> >> >>>>>> Petr^2 Spacek >> >> >>>>>> >> >> >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >> >> >>>>>>>> On 31.3.2015 14:02, Matt . wrote: >> >> >>>>>>>>> HI Phasant, >> >> >>>>>>>>> >> >> >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part >> >> >>>>>>>>> not, SRV records are used for that normally. >> >> >>>>>>>>> >> >> >>>>>>>>> Are you talking about the webgui or the ldap part ? >> >> >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It >> >> >>>>>>>> is important for us to understand to your use-case to propose optimal solution. >> >> >>>>>>>> >> >> >>>>>>>> Petr^2 Spacek >> >> >>>>>>>> >> >> >>>>>>>>> Cheers, >> >> >>>>>>>>> >> >> >>>>>>>>> Matt >> >> >>>>>>>>> >> >> >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >> >> >>>>>>>>>> Hi, >> >> >>>>>>>>>> >> >> >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >> >> >>>>>>>>>> balancer, specifically Amazon ELB. >> >> >>>>>>>>>> >> >> >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >> >> >>>>>>>>>> there is more to it than just this file. >> >> >>>>>>>>>> >> >> >>>>>>>>>> Any suggestions ? >> >> >>>>>>>>>> >> >> >>>>>>>>>> Thanks. >> >> >>>>>>>>>> --Prashant >> >> >> >> >> >> -- >> >> Thank you, >> >> Dmitri Pal >> >> >> >> Sr. Engineering Manager IdM portfolio >> >> Red Hat, Inc. >> >> >> > >> > kerberos is load balancer friendly, if you pet it nicely. >> > >> > you generate a principal for the VIP. you then create a keytab for the >> > VIP. you distribute the keytab via SCP (or other secure method) to all >> > load balanced pool members. you must distribute the same exact keytab >> > to all devices. the KVNO for the VIP principal must match in all copies >> > put on the pool members. use "klist -Kket /path/to/file.keytab" to >> > validate this on all pool members. >> > >> > there are additional steps you may want to take, in order to add the >> > individual principal(s) to the same keytab, so that you can access the >> > pool members themselves (not via the VIP). this requires that you >> > distribute the keytab as above, and then add the individual principals >> > to the local copy of the keytab file. >> > >> > example: >> > >> > you have created the principal ldap/ldap.domain.tld for your VIP >> > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab >> > you have copied the keytab file ~/ldap.keytab to server1, server2 and >> > server3 as /etc/ldap.keytab >> > >> > you ssh to server1 and run kadmin. >> > you then add a principal ldap/server1.domain.tld >> > you then add the principal ldap/server1.domain.tld to the already >> > existing keytab /etc/ldap.keytab. >> > quit kadmin >> > >> > when you run "klist -Kket /etc/ldap.keytab" you should see two >> > principals in it. the VIP name and the hostname. >> > >> > lather, rinse, repeat for all servers. >> > >> > keep in mind the administrative overhead of changing names of servers or >> > VIPs. >> > >> > there are other tricks for doing kerberos stuff. i use the same VIP, >> > but different ports in order to access an individual host/service behind >> > the load balancer. this works because the name (of the VIP) stays the >> > same and i just point a different front end port to an individual >> > backend device/port. >> > >> > -- >> > 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 > > wireshark/tcpdump are your friends. run an unfiltered capture on the > client and attempt the access. review the capture and see what is not > working (hint, filter for "kerberos || ldap" in wireshark during your > review). > > ldapwhoami should return info about your ID. klist after running the > ldapwhoami should have an ldap ticket listed, along with your TGT and > possibly others. > From simo at redhat.com Tue Mar 31 16:53:00 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 31 Mar 2015 12:53:00 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427816508.24621.14.camel@desktop.bpk2.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> Message-ID: <1427820780.8302.188.camel@willson.usersys.redhat.com> On Tue, 2015-03-31 at 11:41 -0400, Brendan Kearney wrote: > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > > On 03/31/2015 10:38 AM, Matt . wrote: > > > True, but we have some extra later between which does the cli command > > > not usable (at least for the moment) > > > > > > I already know how to share the key's among all servers, that works > > > fine, IPA/Apache/Kerberos only doesn't like the other hostname > > > (loadbalancer), or the client doesn't understand it. > > > > > > So fixing this saves me really much more time than doing the another way. > > > > Kerberos is not load balancer friendly. It is something that is a known > > property of Kerberos. > > I remember MIT mentioning something that they did or might do to help > > with that so it might make sense to ask this question on the MIT > > Kerberos user list. > > > > > > > > Thanks! > > > > > > Matt > > > > > > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > > >> On 31.3.2015 16:10, Matt . wrote: > > >>> HI Petr, > > >>> > > >>> We had a several of reasons why we did that. We wanted to use one > > >>> language for that, and also have formatted returns. There was also > > >>> some security issue which came up. > > >> I would be very interested in the security reason. If you see any problem with > > >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > > >> secalert at redhat.com directly. > > >> > > >>> I could ask you, why does IPA json itself ? if you see what it posts > > >>> and what it gets back as result it makes it much more clear in > > >>> development. > > >> I do not understand the question, sorry. > > >> > > >> If you want to see what 'ipa' command does run it with '-vv' parameter: > > >> $ ipa -vv user-find > > >> > > >> It will print JSON request and reply: > > >> ipa: INFO: Request: { > > >> "id": 0, > > >> "method": "user_find", > > >> "params": [ > > >> [ > > >> null > > >> ], > > >> { > > >> "all": false, > > >> "no_members": false, > > >> "pkey_only": false, > > >> "raw": false, > > >> "version": "2.115", > > >> "whoami": false > > >> } > > >> ] > > >> } > > >> ipa: INFO: Response: { > > >> "error": null, > > >> "id": 0, > > >> "principal": "admin at IPA.EXAMPLE", > > >> "result": { > > >> "count": 2, > > >> "result": [ > > >> { > > >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > > >> "gidnumber": [ > > >> "1381000000" > > >> ], > > >> ... > > >> > > >> > > >>> HTTP loadbalancing is not difficult at all, as we post to the > > >>> webserver I need to have that part only auth right. We do more very > > >>> specific loadbalancing stuff and this is the most easy one as it's > > >>> only webserver forward, but IPA/Kerberos has an issue with the > > >>> principal it seems... it cannot be hard to make that accepted I would > > >>> say. > > >> If you insist on Kerberos servers behind a load balancer... you will need to > > >> somehow share the Kerberos key among all servers. I will defer that to > > >> Kerberos experts here. > > >> > > >>> I'm still looking for solutions :) > > >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' > > >> command :-) > > >> > > >> Have a nice day! > > >> > > >> Petr^2 Spacek > > >> > > >>> Cheers, > > >>> > > >>> Matt > > >>> > > >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : > > >>>> On 31.3.2015 15:23, Matt . wrote: > > >>>>> Hi Petr, > > >>>>> > > >>>>> We discussed that before indeed, but SRV is not usable in this case. > > >>>>> > > >>>>> My clients are just webservers (apache) doing some executes of CURL > > >>>>> commands to ipa/json, actually the same commands as the webgui does > > >>>>> using json, but we curl it. > > >>>>> > > >>>>> Do you have a better view now ? > > >>>> Yes. If you have seen the previous discussion then you know that it will be > > >>>> pretty difficult to do this kind of load balancing. > > >>>> > > >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use > > >>>> CURL and make things more complex? > > >>>> > > >>>> Petr^2 Spacek > > >>>> > > >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : > > >>>>>> On 31.3.2015 14:35, Matt . wrote: > > >>>>>>> Hi Petr, > > >>>>>>> > > >>>>>>> As this is not my topic it's for me quite "simple". > > >>>>>>> > > >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. > > >>>>>>> > > >>>>>>> i have > > >>>>>>> > > >>>>>>> ldap-01.domain.tld (ipa1) > > >>>>>>> ldap-01.domain.tld (ipa2) > > >>>>>>> > > >>>>>>> and my loadbalancer is ldap.domain.tld > > >>>>>>> > > >>>>>>> ldap requests over a loadbalancer are quite simple and working, but > > >>>>>>> the json part is more difficult because of the ticket and the dns > > >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a > > >>>>>>> http/ldap.domain.tld service on the ipa server. > > >>>>>>> > > >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to > > >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld > > >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. > > >>>>>>> > > >>>>>>> Is this enough information for you ? > > >>>>>> Well, I still do not understand the use case. What are your clients? Are you > > >>>>>> using 'ipa' command to do something? Or some other clients? > > >>>>>> > > >>>>>> Usually the best thing is to use DNS SRV records because it works even with > > >>>>>> geographically distributed clusters and does not have single point of failure > > >>>>>> (the load balancer). > > >>>>>> > > >>>>>> This requires clients with support for DNS SRV but if your machines are using > > >>>>>> SSSD then you do not need to change anything and it should just work. > > >>>>>> > > >>>>>> That is why I'm asking for the use case :-) > > >>>>>> > > >>>>>> Petr^2 Spacek > > >>>>>> > > >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : > > >>>>>>>> On 31.3.2015 14:02, Matt . wrote: > > >>>>>>>>> HI Phasant, > > >>>>>>>>> > > >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part > > >>>>>>>>> not, SRV records are used for that normally. > > >>>>>>>>> > > >>>>>>>>> Are you talking about the webgui or the ldap part ? > > >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It > > >>>>>>>> is important for us to understand to your use-case to propose optimal solution. > > >>>>>>>> > > >>>>>>>> Petr^2 Spacek > > >>>>>>>> > > >>>>>>>>> Cheers, > > >>>>>>>>> > > >>>>>>>>> Matt > > >>>>>>>>> > > >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : > > >>>>>>>>>> Hi, > > >>>>>>>>>> > > >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load > > >>>>>>>>>> balancer, specifically Amazon ELB. > > >>>>>>>>>> > > >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like > > >>>>>>>>>> there is more to it than just this file. > > >>>>>>>>>> > > >>>>>>>>>> Any suggestions ? > > >>>>>>>>>> > > >>>>>>>>>> Thanks. > > >>>>>>>>>> --Prashant > > > > > > -- > > Thank you, > > Dmitri Pal > > > > Sr. Engineering Manager IdM portfolio > > Red Hat, Inc. > > > > kerberos is load balancer friendly, if you pet it nicely. > > you generate a principal for the VIP. you then create a keytab for the > VIP. you distribute the keytab via SCP (or other secure method) to all > load balanced pool members. you must distribute the same exact keytab > to all devices. the KVNO for the VIP principal must match in all copies > put on the pool members. use "klist -Kket /path/to/file.keytab" to > validate this on all pool members. > > there are additional steps you may want to take, in order to add the > individual principal(s) to the same keytab, so that you can access the > pool members themselves (not via the VIP). this requires that you > distribute the keytab as above, and then add the individual principals > to the local copy of the keytab file. > > example: > > you have created the principal ldap/ldap.domain.tld for your VIP > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab > you have copied the keytab file ~/ldap.keytab to server1, server2 and > server3 as /etc/ldap.keytab > > you ssh to server1 and run kadmin. > you then add a principal ldap/server1.domain.tld > you then add the principal ldap/server1.domain.tld to the already > existing keytab /etc/ldap.keytab. > quit kadmin > > when you run "klist -Kket /etc/ldap.keytab" you should see two > principals in it. the VIP name and the hostname. > > lather, rinse, repeat for all servers. > > keep in mind the administrative overhead of changing names of servers or > VIPs. > > there are other tricks for doing kerberos stuff. i use the same VIP, > but different ports in order to access an individual host/service behind > the load balancer. this works because the name (of the VIP) stays the > same and i just point a different front end port to an individual > backend device/port. > This is all true if you just accept connections. (Un?)fortunately we use delegation within IPA, which requires to use a local key to contact the KDC. This action "fixates" what key we are going to use to accept incoming context establishment requests. If a principal name is not specified then the selected key is usually the first in the keytab. In an IPA setup that will usually be the server's specific key. In order to use multiple keys in conjunction with IPA we'd have to explicitly support. I am not sure if the SSL layer records which name was used (perhaps it does if SNI is used, but almost certainly not is SAN are used), or if multiple virtual hosts need to be used. If we can know what name the client used then we could modify mod_auth_gssapi to select a specific name to acquire creds and then accept the connection with the correct keys. (Another option would be to explicitly retry with each available key if something fails). I am afraid I won't try to coerce mod_auth_kerb to do that, so this option is probably something we can do only post 4.2 and only if we can make appropriate modifications. Simo. -- Simo Sorce * Red Hat, Inc * New York From bpk678 at gmail.com Tue Mar 31 17:21:36 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 31 Mar 2015 13:21:36 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427820780.8302.188.camel@willson.usersys.redhat.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427820780.8302.188.camel@willson.usersys.redhat.com> Message-ID: <1427822496.24621.25.camel@desktop.bpk2.com> On Tue, 2015-03-31 at 12:53 -0400, Simo Sorce wrote: > On Tue, 2015-03-31 at 11:41 -0400, Brendan Kearney wrote: > > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > > > On 03/31/2015 10:38 AM, Matt . wrote: > > > > True, but we have some extra later between which does the cli command > > > > not usable (at least for the moment) > > > > > > > > I already know how to share the key's among all servers, that works > > > > fine, IPA/Apache/Kerberos only doesn't like the other hostname > > > > (loadbalancer), or the client doesn't understand it. > > > > > > > > So fixing this saves me really much more time than doing the another way. > > > > > > Kerberos is not load balancer friendly. It is something that is a known > > > property of Kerberos. > > > I remember MIT mentioning something that they did or might do to help > > > with that so it might make sense to ask this question on the MIT > > > Kerberos user list. > > > > > > > > > > > Thanks! > > > > > > > > Matt > > > > > > > > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > > > >> On 31.3.2015 16:10, Matt . wrote: > > > >>> HI Petr, > > > >>> > > > >>> We had a several of reasons why we did that. We wanted to use one > > > >>> language for that, and also have formatted returns. There was also > > > >>> some security issue which came up. > > > >> I would be very interested in the security reason. If you see any problem with > > > >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > > > >> secalert at redhat.com directly. > > > >> > > > >>> I could ask you, why does IPA json itself ? if you see what it posts > > > >>> and what it gets back as result it makes it much more clear in > > > >>> development. > > > >> I do not understand the question, sorry. > > > >> > > > >> If you want to see what 'ipa' command does run it with '-vv' parameter: > > > >> $ ipa -vv user-find > > > >> > > > >> It will print JSON request and reply: > > > >> ipa: INFO: Request: { > > > >> "id": 0, > > > >> "method": "user_find", > > > >> "params": [ > > > >> [ > > > >> null > > > >> ], > > > >> { > > > >> "all": false, > > > >> "no_members": false, > > > >> "pkey_only": false, > > > >> "raw": false, > > > >> "version": "2.115", > > > >> "whoami": false > > > >> } > > > >> ] > > > >> } > > > >> ipa: INFO: Response: { > > > >> "error": null, > > > >> "id": 0, > > > >> "principal": "admin at IPA.EXAMPLE", > > > >> "result": { > > > >> "count": 2, > > > >> "result": [ > > > >> { > > > >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > > > >> "gidnumber": [ > > > >> "1381000000" > > > >> ], > > > >> ... > > > >> > > > >> > > > >>> HTTP loadbalancing is not difficult at all, as we post to the > > > >>> webserver I need to have that part only auth right. We do more very > > > >>> specific loadbalancing stuff and this is the most easy one as it's > > > >>> only webserver forward, but IPA/Kerberos has an issue with the > > > >>> principal it seems... it cannot be hard to make that accepted I would > > > >>> say. > > > >> If you insist on Kerberos servers behind a load balancer... you will need to > > > >> somehow share the Kerberos key among all servers. I will defer that to > > > >> Kerberos experts here. > > > >> > > > >>> I'm still looking for solutions :) > > > >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' > > > >> command :-) > > > >> > > > >> Have a nice day! > > > >> > > > >> Petr^2 Spacek > > > >> > > > >>> Cheers, > > > >>> > > > >>> Matt > > > >>> > > > >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : > > > >>>> On 31.3.2015 15:23, Matt . wrote: > > > >>>>> Hi Petr, > > > >>>>> > > > >>>>> We discussed that before indeed, but SRV is not usable in this case. > > > >>>>> > > > >>>>> My clients are just webservers (apache) doing some executes of CURL > > > >>>>> commands to ipa/json, actually the same commands as the webgui does > > > >>>>> using json, but we curl it. > > > >>>>> > > > >>>>> Do you have a better view now ? > > > >>>> Yes. If you have seen the previous discussion then you know that it will be > > > >>>> pretty difficult to do this kind of load balancing. > > > >>>> > > > >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use > > > >>>> CURL and make things more complex? > > > >>>> > > > >>>> Petr^2 Spacek > > > >>>> > > > >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : > > > >>>>>> On 31.3.2015 14:35, Matt . wrote: > > > >>>>>>> Hi Petr, > > > >>>>>>> > > > >>>>>>> As this is not my topic it's for me quite "simple". > > > >>>>>>> > > > >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. > > > >>>>>>> > > > >>>>>>> i have > > > >>>>>>> > > > >>>>>>> ldap-01.domain.tld (ipa1) > > > >>>>>>> ldap-01.domain.tld (ipa2) > > > >>>>>>> > > > >>>>>>> and my loadbalancer is ldap.domain.tld > > > >>>>>>> > > > >>>>>>> ldap requests over a loadbalancer are quite simple and working, but > > > >>>>>>> the json part is more difficult because of the ticket and the dns > > > >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a > > > >>>>>>> http/ldap.domain.tld service on the ipa server. > > > >>>>>>> > > > >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to > > > >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld > > > >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. > > > >>>>>>> > > > >>>>>>> Is this enough information for you ? > > > >>>>>> Well, I still do not understand the use case. What are your clients? Are you > > > >>>>>> using 'ipa' command to do something? Or some other clients? > > > >>>>>> > > > >>>>>> Usually the best thing is to use DNS SRV records because it works even with > > > >>>>>> geographically distributed clusters and does not have single point of failure > > > >>>>>> (the load balancer). > > > >>>>>> > > > >>>>>> This requires clients with support for DNS SRV but if your machines are using > > > >>>>>> SSSD then you do not need to change anything and it should just work. > > > >>>>>> > > > >>>>>> That is why I'm asking for the use case :-) > > > >>>>>> > > > >>>>>> Petr^2 Spacek > > > >>>>>> > > > >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : > > > >>>>>>>> On 31.3.2015 14:02, Matt . wrote: > > > >>>>>>>>> HI Phasant, > > > >>>>>>>>> > > > >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part > > > >>>>>>>>> not, SRV records are used for that normally. > > > >>>>>>>>> > > > >>>>>>>>> Are you talking about the webgui or the ldap part ? > > > >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It > > > >>>>>>>> is important for us to understand to your use-case to propose optimal solution. > > > >>>>>>>> > > > >>>>>>>> Petr^2 Spacek > > > >>>>>>>> > > > >>>>>>>>> Cheers, > > > >>>>>>>>> > > > >>>>>>>>> Matt > > > >>>>>>>>> > > > >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : > > > >>>>>>>>>> Hi, > > > >>>>>>>>>> > > > >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load > > > >>>>>>>>>> balancer, specifically Amazon ELB. > > > >>>>>>>>>> > > > >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like > > > >>>>>>>>>> there is more to it than just this file. > > > >>>>>>>>>> > > > >>>>>>>>>> Any suggestions ? > > > >>>>>>>>>> > > > >>>>>>>>>> Thanks. > > > >>>>>>>>>> --Prashant > > > > > > > > > -- > > > Thank you, > > > Dmitri Pal > > > > > > Sr. Engineering Manager IdM portfolio > > > Red Hat, Inc. > > > > > > > kerberos is load balancer friendly, if you pet it nicely. > > > > you generate a principal for the VIP. you then create a keytab for the > > VIP. you distribute the keytab via SCP (or other secure method) to all > > load balanced pool members. you must distribute the same exact keytab > > to all devices. the KVNO for the VIP principal must match in all copies > > put on the pool members. use "klist -Kket /path/to/file.keytab" to > > validate this on all pool members. > > > > there are additional steps you may want to take, in order to add the > > individual principal(s) to the same keytab, so that you can access the > > pool members themselves (not via the VIP). this requires that you > > distribute the keytab as above, and then add the individual principals > > to the local copy of the keytab file. > > > > example: > > > > you have created the principal ldap/ldap.domain.tld for your VIP > > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab > > you have copied the keytab file ~/ldap.keytab to server1, server2 and > > server3 as /etc/ldap.keytab > > > > you ssh to server1 and run kadmin. > > you then add a principal ldap/server1.domain.tld > > you then add the principal ldap/server1.domain.tld to the already > > existing keytab /etc/ldap.keytab. > > quit kadmin > > > > when you run "klist -Kket /etc/ldap.keytab" you should see two > > principals in it. the VIP name and the hostname. > > > > lather, rinse, repeat for all servers. > > > > keep in mind the administrative overhead of changing names of servers or > > VIPs. > > > > there are other tricks for doing kerberos stuff. i use the same VIP, > > but different ports in order to access an individual host/service behind > > the load balancer. this works because the name (of the VIP) stays the > > same and i just point a different front end port to an individual > > backend device/port. > > > > This is all true if you just accept connections. > > (Un?)fortunately we use delegation within IPA, which requires to use a > local key to contact the KDC. This action "fixates" what key we are > going to use to accept incoming context establishment requests. If a > principal name is not specified then the selected key is usually the > first in the keytab. > > In an IPA setup that will usually be the server's specific key. > > In order to use multiple keys in conjunction with IPA we'd have to > explicitly support. I am not sure if the SSL layer records which name > was used (perhaps it does if SNI is used, but almost certainly not is > SAN are used), or if multiple virtual hosts need to be used. > If we can know what name the client used then we could modify > mod_auth_gssapi to select a specific name to acquire creds and then > accept the connection with the correct keys. (Another option would be to > explicitly retry with each available key if something fails). > > I am afraid I won't try to coerce mod_auth_kerb to do that, so this > option is probably something we can do only post 4.2 and only if we can > make appropriate modifications. > > Simo. > the below works for me on apache2.4, with mod_auth_kerb, MIT Kerberos V and OpenLDAP. I run HAProxy, which holds the A/PTR records for www.bpk2.com, and load balances to each of the instances i have running behind it. Fedora 20 with latest everything... AuthType Kerberos AuthName "Enter your credentials" KrbMethodNegotiate On KrbMethodK5Passwd On KrbSaveCredentials On KrbAuthRealms BPK2.COM Krb5KeyTab /etc/httpd/conf.d/httpd.keytab KrbServiceName "HTTP/www.bpk2.com at BPK2.COM" KrbLocalUserMapping On KrbDelegateBasic Off KrbAuthoritative Off KrbServiceName explicitly sets the principal to be used. because of this, i use the front end trick with port on the VIP to access a specific pool memeber (www:80 --> load balanced via least connections to all pool members, www:81 --> server1:80, www:82 --> server2:80) From bpk678 at gmail.com Tue Mar 31 17:29:05 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 31 Mar 2015 13:29:05 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427817533.24621.18.camel@desktop.bpk2.com> Message-ID: <1427822945.24621.28.camel@desktop.bpk2.com> On Tue, 2015-03-31 at 18:18 +0200, Matt . wrote: > OK, that makes it even more clear. > > an ldapwhoami might be an issue. As this client is known on a > different ldap server and I kinit to another ldap server. There is a > reason for this as we have out office network and our deployment > network. Users that manage are in the office ldap, user that are in > deployment are in the deployment ldap. I do my kinit > username at deployment.domain which works ok when I run my commands at > ipa-01.deployment.domain. > > But when I want to do a ldapwhoami it tries to connect to the office > ldap server which is not working of course. (I get a connection error > atm, need to investigate as that server is running fine). > > Get the idea ? > > Thanks again! > > Matt > > 2015-03-31 17:58 GMT+02:00 Brendan Kearney : > > On Tue, 2015-03-31 at 17:51 +0200, Matt . wrote: > >> Hi Brendan, > >> > >> Yes thanks for your great explanation, I have done that indeed. But in > >> some strange way, with only a 401 in access_log of apache I get a Non > >> valid ticket when I connect through my loadbalancer. I don't go "by" > >> my loadbalancer but through it (NAT) or should it go "by/next" to it ? > >> > >> I think we can get this fixed :) > >> > >> Thanks! > >> > >> Matt > >> > >> 2015-03-31 17:41 GMT+02:00 Brendan Kearney : > >> > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > >> >> On 03/31/2015 10:38 AM, Matt . wrote: > >> >> > True, but we have some extra later between which does the cli command > >> >> > not usable (at least for the moment) > >> >> > > >> >> > I already know how to share the key's among all servers, that works > >> >> > fine, IPA/Apache/Kerberos only doesn't like the other hostname > >> >> > (loadbalancer), or the client doesn't understand it. > >> >> > > >> >> > So fixing this saves me really much more time than doing the another way. > >> >> > >> >> Kerberos is not load balancer friendly. It is something that is a known > >> >> property of Kerberos. > >> >> I remember MIT mentioning something that they did or might do to help > >> >> with that so it might make sense to ask this question on the MIT > >> >> Kerberos user list. > >> >> > >> >> > > >> >> > Thanks! > >> >> > > >> >> > Matt > >> >> > > >> >> > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > >> >> >> On 31.3.2015 16:10, Matt . wrote: > >> >> >>> HI Petr, > >> >> >>> > >> >> >>> We had a several of reasons why we did that. We wanted to use one > >> >> >>> language for that, and also have formatted returns. There was also > >> >> >>> some security issue which came up. > >> >> >> I would be very interested in the security reason. If you see any problem with > >> >> >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > >> >> >> secalert at redhat.com directly. > >> >> >> > >> >> >>> I could ask you, why does IPA json itself ? if you see what it posts > >> >> >>> and what it gets back as result it makes it much more clear in > >> >> >>> development. > >> >> >> I do not understand the question, sorry. > >> >> >> > >> >> >> If you want to see what 'ipa' command does run it with '-vv' parameter: > >> >> >> $ ipa -vv user-find > >> >> >> > >> >> >> It will print JSON request and reply: > >> >> >> ipa: INFO: Request: { > >> >> >> "id": 0, > >> >> >> "method": "user_find", > >> >> >> "params": [ > >> >> >> [ > >> >> >> null > >> >> >> ], > >> >> >> { > >> >> >> "all": false, > >> >> >> "no_members": false, > >> >> >> "pkey_only": false, > >> >> >> "raw": false, > >> >> >> "version": "2.115", > >> >> >> "whoami": false > >> >> >> } > >> >> >> ] > >> >> >> } > >> >> >> ipa: INFO: Response: { > >> >> >> "error": null, > >> >> >> "id": 0, > >> >> >> "principal": "admin at IPA.EXAMPLE", > >> >> >> "result": { > >> >> >> "count": 2, > >> >> >> "result": [ > >> >> >> { > >> >> >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > >> >> >> "gidnumber": [ > >> >> >> "1381000000" > >> >> >> ], > >> >> >> ... > >> >> >> > >> >> >> > >> >> >>> HTTP loadbalancing is not difficult at all, as we post to the > >> >> >>> webserver I need to have that part only auth right. We do more very > >> >> >>> specific loadbalancing stuff and this is the most easy one as it's > >> >> >>> only webserver forward, but IPA/Kerberos has an issue with the > >> >> >>> principal it seems... it cannot be hard to make that accepted I would > >> >> >>> say. > >> >> >> If you insist on Kerberos servers behind a load balancer... you will need to > >> >> >> somehow share the Kerberos key among all servers. I will defer that to > >> >> >> Kerberos experts here. > >> >> >> > >> >> >>> I'm still looking for solutions :) > >> >> >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' > >> >> >> command :-) > >> >> >> > >> >> >> Have a nice day! > >> >> >> > >> >> >> Petr^2 Spacek > >> >> >> > >> >> >>> Cheers, > >> >> >>> > >> >> >>> Matt > >> >> >>> > >> >> >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : > >> >> >>>> On 31.3.2015 15:23, Matt . wrote: > >> >> >>>>> Hi Petr, > >> >> >>>>> > >> >> >>>>> We discussed that before indeed, but SRV is not usable in this case. > >> >> >>>>> > >> >> >>>>> My clients are just webservers (apache) doing some executes of CURL > >> >> >>>>> commands to ipa/json, actually the same commands as the webgui does > >> >> >>>>> using json, but we curl it. > >> >> >>>>> > >> >> >>>>> Do you have a better view now ? > >> >> >>>> Yes. If you have seen the previous discussion then you know that it will be > >> >> >>>> pretty difficult to do this kind of load balancing. > >> >> >>>> > >> >> >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use > >> >> >>>> CURL and make things more complex? > >> >> >>>> > >> >> >>>> Petr^2 Spacek > >> >> >>>> > >> >> >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : > >> >> >>>>>> On 31.3.2015 14:35, Matt . wrote: > >> >> >>>>>>> Hi Petr, > >> >> >>>>>>> > >> >> >>>>>>> As this is not my topic it's for me quite "simple". > >> >> >>>>>>> > >> >> >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. > >> >> >>>>>>> > >> >> >>>>>>> i have > >> >> >>>>>>> > >> >> >>>>>>> ldap-01.domain.tld (ipa1) > >> >> >>>>>>> ldap-01.domain.tld (ipa2) > >> >> >>>>>>> > >> >> >>>>>>> and my loadbalancer is ldap.domain.tld > >> >> >>>>>>> > >> >> >>>>>>> ldap requests over a loadbalancer are quite simple and working, but > >> >> >>>>>>> the json part is more difficult because of the ticket and the dns > >> >> >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a > >> >> >>>>>>> http/ldap.domain.tld service on the ipa server. > >> >> >>>>>>> > >> >> >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to > >> >> >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld > >> >> >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. > >> >> >>>>>>> > >> >> >>>>>>> Is this enough information for you ? > >> >> >>>>>> Well, I still do not understand the use case. What are your clients? Are you > >> >> >>>>>> using 'ipa' command to do something? Or some other clients? > >> >> >>>>>> > >> >> >>>>>> Usually the best thing is to use DNS SRV records because it works even with > >> >> >>>>>> geographically distributed clusters and does not have single point of failure > >> >> >>>>>> (the load balancer). > >> >> >>>>>> > >> >> >>>>>> This requires clients with support for DNS SRV but if your machines are using > >> >> >>>>>> SSSD then you do not need to change anything and it should just work. > >> >> >>>>>> > >> >> >>>>>> That is why I'm asking for the use case :-) > >> >> >>>>>> > >> >> >>>>>> Petr^2 Spacek > >> >> >>>>>> > >> >> >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : > >> >> >>>>>>>> On 31.3.2015 14:02, Matt . wrote: > >> >> >>>>>>>>> HI Phasant, > >> >> >>>>>>>>> > >> >> >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part > >> >> >>>>>>>>> not, SRV records are used for that normally. > >> >> >>>>>>>>> > >> >> >>>>>>>>> Are you talking about the webgui or the ldap part ? > >> >> >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It > >> >> >>>>>>>> is important for us to understand to your use-case to propose optimal solution. > >> >> >>>>>>>> > >> >> >>>>>>>> Petr^2 Spacek > >> >> >>>>>>>> > >> >> >>>>>>>>> Cheers, > >> >> >>>>>>>>> > >> >> >>>>>>>>> Matt > >> >> >>>>>>>>> > >> >> >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : > >> >> >>>>>>>>>> Hi, > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load > >> >> >>>>>>>>>> balancer, specifically Amazon ELB. > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like > >> >> >>>>>>>>>> there is more to it than just this file. > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> Any suggestions ? > >> >> >>>>>>>>>> > >> >> >>>>>>>>>> Thanks. > >> >> >>>>>>>>>> --Prashant > >> >> > >> >> > >> >> -- > >> >> Thank you, > >> >> Dmitri Pal > >> >> > >> >> Sr. Engineering Manager IdM portfolio > >> >> Red Hat, Inc. > >> >> > >> > > >> > kerberos is load balancer friendly, if you pet it nicely. > >> > > >> > you generate a principal for the VIP. you then create a keytab for the > >> > VIP. you distribute the keytab via SCP (or other secure method) to all > >> > load balanced pool members. you must distribute the same exact keytab > >> > to all devices. the KVNO for the VIP principal must match in all copies > >> > put on the pool members. use "klist -Kket /path/to/file.keytab" to > >> > validate this on all pool members. > >> > > >> > there are additional steps you may want to take, in order to add the > >> > individual principal(s) to the same keytab, so that you can access the > >> > pool members themselves (not via the VIP). this requires that you > >> > distribute the keytab as above, and then add the individual principals > >> > to the local copy of the keytab file. > >> > > >> > example: > >> > > >> > you have created the principal ldap/ldap.domain.tld for your VIP > >> > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab > >> > you have copied the keytab file ~/ldap.keytab to server1, server2 and > >> > server3 as /etc/ldap.keytab > >> > > >> > you ssh to server1 and run kadmin. > >> > you then add a principal ldap/server1.domain.tld > >> > you then add the principal ldap/server1.domain.tld to the already > >> > existing keytab /etc/ldap.keytab. > >> > quit kadmin > >> > > >> > when you run "klist -Kket /etc/ldap.keytab" you should see two > >> > principals in it. the VIP name and the hostname. > >> > > >> > lather, rinse, repeat for all servers. > >> > > >> > keep in mind the administrative overhead of changing names of servers or > >> > VIPs. > >> > > >> > there are other tricks for doing kerberos stuff. i use the same VIP, > >> > but different ports in order to access an individual host/service behind > >> > the load balancer. this works because the name (of the VIP) stays the > >> > same and i just point a different front end port to an individual > >> > backend device/port. > >> > > >> > -- > >> > 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 > > > > wireshark/tcpdump are your friends. run an unfiltered capture on the > > client and attempt the access. review the capture and see what is not > > working (hint, filter for "kerberos || ldap" in wireshark during your > > review). > > > > ldapwhoami should return info about your ID. klist after running the > > ldapwhoami should have an ldap ticket listed, along with your TGT and > > possibly others. > > looks like trusts between the kerberos realms and/or ldap domains are not setup, are not setup correctly or are not bi-directional. you seem to be getting a referral for the ticket, but cannot get the ticket from where you are being referred to. dig into a netowrk capture with wireshark and look through it very carefully. From yamakasi.014 at gmail.com Tue Mar 31 17:36:10 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 19:36:10 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427822945.24621.28.camel@desktop.bpk2.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427817533.24621.18.camel@desktop.bpk2.com> <1427822945.24621.28.camel@desktop.bpk2.com> Message-ID: OK, but as I say, without the loadbalancer, same domain it works. My IPA server also sees the client name and ptr as I do nat. So you create a keytab for your host you are doing the commands from ? I was using a user keytab and run my commands as that user, that works to ipa-01 It's getting something more clear. 2015-03-31 19:29 GMT+02:00 Brendan Kearney : > On Tue, 2015-03-31 at 18:18 +0200, Matt . wrote: >> OK, that makes it even more clear. >> >> an ldapwhoami might be an issue. As this client is known on a >> different ldap server and I kinit to another ldap server. There is a >> reason for this as we have out office network and our deployment >> network. Users that manage are in the office ldap, user that are in >> deployment are in the deployment ldap. I do my kinit >> username at deployment.domain which works ok when I run my commands at >> ipa-01.deployment.domain. >> >> But when I want to do a ldapwhoami it tries to connect to the office >> ldap server which is not working of course. (I get a connection error >> atm, need to investigate as that server is running fine). >> >> Get the idea ? >> >> Thanks again! >> >> Matt >> >> 2015-03-31 17:58 GMT+02:00 Brendan Kearney : >> > On Tue, 2015-03-31 at 17:51 +0200, Matt . wrote: >> >> Hi Brendan, >> >> >> >> Yes thanks for your great explanation, I have done that indeed. But in >> >> some strange way, with only a 401 in access_log of apache I get a Non >> >> valid ticket when I connect through my loadbalancer. I don't go "by" >> >> my loadbalancer but through it (NAT) or should it go "by/next" to it ? >> >> >> >> I think we can get this fixed :) >> >> >> >> Thanks! >> >> >> >> Matt >> >> >> >> 2015-03-31 17:41 GMT+02:00 Brendan Kearney : >> >> > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: >> >> >> On 03/31/2015 10:38 AM, Matt . wrote: >> >> >> > True, but we have some extra later between which does the cli command >> >> >> > not usable (at least for the moment) >> >> >> > >> >> >> > I already know how to share the key's among all servers, that works >> >> >> > fine, IPA/Apache/Kerberos only doesn't like the other hostname >> >> >> > (loadbalancer), or the client doesn't understand it. >> >> >> > >> >> >> > So fixing this saves me really much more time than doing the another way. >> >> >> >> >> >> Kerberos is not load balancer friendly. It is something that is a known >> >> >> property of Kerberos. >> >> >> I remember MIT mentioning something that they did or might do to help >> >> >> with that so it might make sense to ask this question on the MIT >> >> >> Kerberos user list. >> >> >> >> >> >> > >> >> >> > Thanks! >> >> >> > >> >> >> > Matt >> >> >> > >> >> >> > 2015-03-31 16:24 GMT+02:00 Petr Spacek : >> >> >> >> On 31.3.2015 16:10, Matt . wrote: >> >> >> >>> HI Petr, >> >> >> >>> >> >> >> >>> We had a several of reasons why we did that. We wanted to use one >> >> >> >>> language for that, and also have formatted returns. There was also >> >> >> >>> some security issue which came up. >> >> >> >> I would be very interested in the security reason. If you see any problem with >> >> >> >> 'ipa' command or FreeIPA API please send me a private e-mail or contact >> >> >> >> secalert at redhat.com directly. >> >> >> >> >> >> >> >>> I could ask you, why does IPA json itself ? if you see what it posts >> >> >> >>> and what it gets back as result it makes it much more clear in >> >> >> >>> development. >> >> >> >> I do not understand the question, sorry. >> >> >> >> >> >> >> >> If you want to see what 'ipa' command does run it with '-vv' parameter: >> >> >> >> $ ipa -vv user-find >> >> >> >> >> >> >> >> It will print JSON request and reply: >> >> >> >> ipa: INFO: Request: { >> >> >> >> "id": 0, >> >> >> >> "method": "user_find", >> >> >> >> "params": [ >> >> >> >> [ >> >> >> >> null >> >> >> >> ], >> >> >> >> { >> >> >> >> "all": false, >> >> >> >> "no_members": false, >> >> >> >> "pkey_only": false, >> >> >> >> "raw": false, >> >> >> >> "version": "2.115", >> >> >> >> "whoami": false >> >> >> >> } >> >> >> >> ] >> >> >> >> } >> >> >> >> ipa: INFO: Response: { >> >> >> >> "error": null, >> >> >> >> "id": 0, >> >> >> >> "principal": "admin at IPA.EXAMPLE", >> >> >> >> "result": { >> >> >> >> "count": 2, >> >> >> >> "result": [ >> >> >> >> { >> >> >> >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", >> >> >> >> "gidnumber": [ >> >> >> >> "1381000000" >> >> >> >> ], >> >> >> >> ... >> >> >> >> >> >> >> >> >> >> >> >>> HTTP loadbalancing is not difficult at all, as we post to the >> >> >> >>> webserver I need to have that part only auth right. We do more very >> >> >> >>> specific loadbalancing stuff and this is the most easy one as it's >> >> >> >>> only webserver forward, but IPA/Kerberos has an issue with the >> >> >> >>> principal it seems... it cannot be hard to make that accepted I would >> >> >> >>> say. >> >> >> >> If you insist on Kerberos servers behind a load balancer... you will need to >> >> >> >> somehow share the Kerberos key among all servers. I will defer that to >> >> >> >> Kerberos experts here. >> >> >> >> >> >> >> >>> I'm still looking for solutions :) >> >> >> >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' >> >> >> >> command :-) >> >> >> >> >> >> >> >> Have a nice day! >> >> >> >> >> >> >> >> Petr^2 Spacek >> >> >> >> >> >> >> >>> Cheers, >> >> >> >>> >> >> >> >>> Matt >> >> >> >>> >> >> >> >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : >> >> >> >>>> On 31.3.2015 15:23, Matt . wrote: >> >> >> >>>>> Hi Petr, >> >> >> >>>>> >> >> >> >>>>> We discussed that before indeed, but SRV is not usable in this case. >> >> >> >>>>> >> >> >> >>>>> My clients are just webservers (apache) doing some executes of CURL >> >> >> >>>>> commands to ipa/json, actually the same commands as the webgui does >> >> >> >>>>> using json, but we curl it. >> >> >> >>>>> >> >> >> >>>>> Do you have a better view now ? >> >> >> >>>> Yes. If you have seen the previous discussion then you know that it will be >> >> >> >>>> pretty difficult to do this kind of load balancing. >> >> >> >>>> >> >> >> >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use >> >> >> >>>> CURL and make things more complex? >> >> >> >>>> >> >> >> >>>> Petr^2 Spacek >> >> >> >>>> >> >> >> >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : >> >> >> >>>>>> On 31.3.2015 14:35, Matt . wrote: >> >> >> >>>>>>> Hi Petr, >> >> >> >>>>>>> >> >> >> >>>>>>> As this is not my topic it's for me quite "simple". >> >> >> >>>>>>> >> >> >> >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. >> >> >> >>>>>>> >> >> >> >>>>>>> i have >> >> >> >>>>>>> >> >> >> >>>>>>> ldap-01.domain.tld (ipa1) >> >> >> >>>>>>> ldap-01.domain.tld (ipa2) >> >> >> >>>>>>> >> >> >> >>>>>>> and my loadbalancer is ldap.domain.tld >> >> >> >>>>>>> >> >> >> >>>>>>> ldap requests over a loadbalancer are quite simple and working, but >> >> >> >>>>>>> the json part is more difficult because of the ticket and the dns >> >> >> >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a >> >> >> >>>>>>> http/ldap.domain.tld service on the ipa server. >> >> >> >>>>>>> >> >> >> >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to >> >> >> >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld >> >> >> >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. >> >> >> >>>>>>> >> >> >> >>>>>>> Is this enough information for you ? >> >> >> >>>>>> Well, I still do not understand the use case. What are your clients? Are you >> >> >> >>>>>> using 'ipa' command to do something? Or some other clients? >> >> >> >>>>>> >> >> >> >>>>>> Usually the best thing is to use DNS SRV records because it works even with >> >> >> >>>>>> geographically distributed clusters and does not have single point of failure >> >> >> >>>>>> (the load balancer). >> >> >> >>>>>> >> >> >> >>>>>> This requires clients with support for DNS SRV but if your machines are using >> >> >> >>>>>> SSSD then you do not need to change anything and it should just work. >> >> >> >>>>>> >> >> >> >>>>>> That is why I'm asking for the use case :-) >> >> >> >>>>>> >> >> >> >>>>>> Petr^2 Spacek >> >> >> >>>>>> >> >> >> >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : >> >> >> >>>>>>>> On 31.3.2015 14:02, Matt . wrote: >> >> >> >>>>>>>>> HI Phasant, >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part >> >> >> >>>>>>>>> not, SRV records are used for that normally. >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> Are you talking about the webgui or the ldap part ? >> >> >> >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It >> >> >> >>>>>>>> is important for us to understand to your use-case to propose optimal solution. >> >> >> >>>>>>>> >> >> >> >>>>>>>> Petr^2 Spacek >> >> >> >>>>>>>> >> >> >> >>>>>>>>> Cheers, >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> Matt >> >> >> >>>>>>>>> >> >> >> >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : >> >> >> >>>>>>>>>> Hi, >> >> >> >>>>>>>>>> >> >> >> >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load >> >> >> >>>>>>>>>> balancer, specifically Amazon ELB. >> >> >> >>>>>>>>>> >> >> >> >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like >> >> >> >>>>>>>>>> there is more to it than just this file. >> >> >> >>>>>>>>>> >> >> >> >>>>>>>>>> Any suggestions ? >> >> >> >>>>>>>>>> >> >> >> >>>>>>>>>> Thanks. >> >> >> >>>>>>>>>> --Prashant >> >> >> >> >> >> >> >> >> -- >> >> >> Thank you, >> >> >> Dmitri Pal >> >> >> >> >> >> Sr. Engineering Manager IdM portfolio >> >> >> Red Hat, Inc. >> >> >> >> >> > >> >> > kerberos is load balancer friendly, if you pet it nicely. >> >> > >> >> > you generate a principal for the VIP. you then create a keytab for the >> >> > VIP. you distribute the keytab via SCP (or other secure method) to all >> >> > load balanced pool members. you must distribute the same exact keytab >> >> > to all devices. the KVNO for the VIP principal must match in all copies >> >> > put on the pool members. use "klist -Kket /path/to/file.keytab" to >> >> > validate this on all pool members. >> >> > >> >> > there are additional steps you may want to take, in order to add the >> >> > individual principal(s) to the same keytab, so that you can access the >> >> > pool members themselves (not via the VIP). this requires that you >> >> > distribute the keytab as above, and then add the individual principals >> >> > to the local copy of the keytab file. >> >> > >> >> > example: >> >> > >> >> > you have created the principal ldap/ldap.domain.tld for your VIP >> >> > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab >> >> > you have copied the keytab file ~/ldap.keytab to server1, server2 and >> >> > server3 as /etc/ldap.keytab >> >> > >> >> > you ssh to server1 and run kadmin. >> >> > you then add a principal ldap/server1.domain.tld >> >> > you then add the principal ldap/server1.domain.tld to the already >> >> > existing keytab /etc/ldap.keytab. >> >> > quit kadmin >> >> > >> >> > when you run "klist -Kket /etc/ldap.keytab" you should see two >> >> > principals in it. the VIP name and the hostname. >> >> > >> >> > lather, rinse, repeat for all servers. >> >> > >> >> > keep in mind the administrative overhead of changing names of servers or >> >> > VIPs. >> >> > >> >> > there are other tricks for doing kerberos stuff. i use the same VIP, >> >> > but different ports in order to access an individual host/service behind >> >> > the load balancer. this works because the name (of the VIP) stays the >> >> > same and i just point a different front end port to an individual >> >> > backend device/port. >> >> > >> >> > -- >> >> > 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 >> > >> > wireshark/tcpdump are your friends. run an unfiltered capture on the >> > client and attempt the access. review the capture and see what is not >> > working (hint, filter for "kerberos || ldap" in wireshark during your >> > review). >> > >> > ldapwhoami should return info about your ID. klist after running the >> > ldapwhoami should have an ldap ticket listed, along with your TGT and >> > possibly others. >> > > > looks like trusts between the kerberos realms and/or ldap domains are > not setup, are not setup correctly or are not bi-directional. > > you seem to be getting a referral for the ticket, but cannot get the > ticket from where you are being referred to. dig into a netowrk capture > with wireshark and look through it very carefully. > From bpk678 at gmail.com Tue Mar 31 17:49:21 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 31 Mar 2015 13:49:21 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427817533.24621.18.camel@desktop.bpk2.com> <1427822945.24621.28.camel@desktop.bpk2.com> Message-ID: <1427824161.24621.37.camel@desktop.bpk2.com> On Tue, 2015-03-31 at 19:36 +0200, Matt . wrote: > OK, but as I say, without the loadbalancer, same domain it works. > All the more reason to capture the session and review it in wireshark. > My IPA server also sees the client name and ptr as I do nat. > > So you create a keytab for your host you are doing the commands from ? all of my hosts get a host principal and have it put in /etc/krb5.keytab. i run kadmin to generate them. freeipa likely has utilities for this, but am not sure what they are. > I was using a user keytab and run my commands as that user, that works > to ipa-01 > > It's getting something more clear. From simo at redhat.com Tue Mar 31 17:50:16 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 31 Mar 2015 13:50:16 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427822496.24621.25.camel@desktop.bpk2.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427820780.8302.188.camel@willson.usersys.redhat.com> <1427822496.24621.25.camel@desktop.bpk2.com> Message-ID: <1427824216.8302.192.camel@willson.usersys.redhat.com> On Tue, 2015-03-31 at 13:21 -0400, Brendan Kearney wrote: > On Tue, 2015-03-31 at 12:53 -0400, Simo Sorce wrote: > > On Tue, 2015-03-31 at 11:41 -0400, Brendan Kearney wrote: > > > On Tue, 2015-03-31 at 11:07 -0400, Dmitri Pal wrote: > > > > On 03/31/2015 10:38 AM, Matt . wrote: > > > > > True, but we have some extra later between which does the cli command > > > > > not usable (at least for the moment) > > > > > > > > > > I already know how to share the key's among all servers, that works > > > > > fine, IPA/Apache/Kerberos only doesn't like the other hostname > > > > > (loadbalancer), or the client doesn't understand it. > > > > > > > > > > So fixing this saves me really much more time than doing the another way. > > > > > > > > Kerberos is not load balancer friendly. It is something that is a known > > > > property of Kerberos. > > > > I remember MIT mentioning something that they did or might do to help > > > > with that so it might make sense to ask this question on the MIT > > > > Kerberos user list. > > > > > > > > > > > > > > Thanks! > > > > > > > > > > Matt > > > > > > > > > > 2015-03-31 16:24 GMT+02:00 Petr Spacek : > > > > >> On 31.3.2015 16:10, Matt . wrote: > > > > >>> HI Petr, > > > > >>> > > > > >>> We had a several of reasons why we did that. We wanted to use one > > > > >>> language for that, and also have formatted returns. There was also > > > > >>> some security issue which came up. > > > > >> I would be very interested in the security reason. If you see any problem with > > > > >> 'ipa' command or FreeIPA API please send me a private e-mail or contact > > > > >> secalert at redhat.com directly. > > > > >> > > > > >>> I could ask you, why does IPA json itself ? if you see what it posts > > > > >>> and what it gets back as result it makes it much more clear in > > > > >>> development. > > > > >> I do not understand the question, sorry. > > > > >> > > > > >> If you want to see what 'ipa' command does run it with '-vv' parameter: > > > > >> $ ipa -vv user-find > > > > >> > > > > >> It will print JSON request and reply: > > > > >> ipa: INFO: Request: { > > > > >> "id": 0, > > > > >> "method": "user_find", > > > > >> "params": [ > > > > >> [ > > > > >> null > > > > >> ], > > > > >> { > > > > >> "all": false, > > > > >> "no_members": false, > > > > >> "pkey_only": false, > > > > >> "raw": false, > > > > >> "version": "2.115", > > > > >> "whoami": false > > > > >> } > > > > >> ] > > > > >> } > > > > >> ipa: INFO: Response: { > > > > >> "error": null, > > > > >> "id": 0, > > > > >> "principal": "admin at IPA.EXAMPLE", > > > > >> "result": { > > > > >> "count": 2, > > > > >> "result": [ > > > > >> { > > > > >> "dn": "uid=admin,cn=users,cn=accounts,dc=ipa,dc=example", > > > > >> "gidnumber": [ > > > > >> "1381000000" > > > > >> ], > > > > >> ... > > > > >> > > > > >> > > > > >>> HTTP loadbalancing is not difficult at all, as we post to the > > > > >>> webserver I need to have that part only auth right. We do more very > > > > >>> specific loadbalancing stuff and this is the most easy one as it's > > > > >>> only webserver forward, but IPA/Kerberos has an issue with the > > > > >>> principal it seems... it cannot be hard to make that accepted I would > > > > >>> say. > > > > >> If you insist on Kerberos servers behind a load balancer... you will need to > > > > >> somehow share the Kerberos key among all servers. I will defer that to > > > > >> Kerberos experts here. > > > > >> > > > > >>> I'm still looking for solutions :) > > > > >> Sure, but you will save a lot of time and nerves if you simply call 'ipa' > > > > >> command :-) > > > > >> > > > > >> Have a nice day! > > > > >> > > > > >> Petr^2 Spacek > > > > >> > > > > >>> Cheers, > > > > >>> > > > > >>> Matt > > > > >>> > > > > >>> 2015-03-31 15:58 GMT+02:00 Petr Spacek : > > > > >>>> On 31.3.2015 15:23, Matt . wrote: > > > > >>>>> Hi Petr, > > > > >>>>> > > > > >>>>> We discussed that before indeed, but SRV is not usable in this case. > > > > >>>>> > > > > >>>>> My clients are just webservers (apache) doing some executes of CURL > > > > >>>>> commands to ipa/json, actually the same commands as the webgui does > > > > >>>>> using json, but we curl it. > > > > >>>>> > > > > >>>>> Do you have a better view now ? > > > > >>>> Yes. If you have seen the previous discussion then you know that it will be > > > > >>>> pretty difficult to do this kind of load balancing. > > > > >>>> > > > > >>>> Why are you not using 'ipa' command or Python API we have instead? Why to use > > > > >>>> CURL and make things more complex? > > > > >>>> > > > > >>>> Petr^2 Spacek > > > > >>>> > > > > >>>>> 2015-03-31 15:03 GMT+02:00 Petr Spacek : > > > > >>>>>> On 31.3.2015 14:35, Matt . wrote: > > > > >>>>>>> Hi Petr, > > > > >>>>>>> > > > > >>>>>>> As this is not my topic it's for me quite "simple". > > > > >>>>>>> > > > > >>>>>>> I need to post to /ipa/json through a loadbalancer, nothing more. > > > > >>>>>>> > > > > >>>>>>> i have > > > > >>>>>>> > > > > >>>>>>> ldap-01.domain.tld (ipa1) > > > > >>>>>>> ldap-01.domain.tld (ipa2) > > > > >>>>>>> > > > > >>>>>>> and my loadbalancer is ldap.domain.tld > > > > >>>>>>> > > > > >>>>>>> ldap requests over a loadbalancer are quite simple and working, but > > > > >>>>>>> the json part is more difficult because of the ticket and the dns > > > > >>>>>>> name. I have added a san ldap.domain.tld to the webgui and there is a > > > > >>>>>>> http/ldap.domain.tld service on the ipa server. > > > > >>>>>>> > > > > >>>>>>> I get a nonvalid kerberos ticket when I go through ldap.domain.tld to > > > > >>>>>>> ldap-01.domain.tld, but when I change my script to ldap-01.domain.tld > > > > >>>>>>> after it failed my ticket is OK for ldap-01.domain.tld and works. > > > > >>>>>>> > > > > >>>>>>> Is this enough information for you ? > > > > >>>>>> Well, I still do not understand the use case. What are your clients? Are you > > > > >>>>>> using 'ipa' command to do something? Or some other clients? > > > > >>>>>> > > > > >>>>>> Usually the best thing is to use DNS SRV records because it works even with > > > > >>>>>> geographically distributed clusters and does not have single point of failure > > > > >>>>>> (the load balancer). > > > > >>>>>> > > > > >>>>>> This requires clients with support for DNS SRV but if your machines are using > > > > >>>>>> SSSD then you do not need to change anything and it should just work. > > > > >>>>>> > > > > >>>>>> That is why I'm asking for the use case :-) > > > > >>>>>> > > > > >>>>>> Petr^2 Spacek > > > > >>>>>> > > > > >>>>>>> 2015-03-31 14:21 GMT+02:00 Petr Spacek : > > > > >>>>>>>> On 31.3.2015 14:02, Matt . wrote: > > > > >>>>>>>>> HI Phasant, > > > > >>>>>>>>> > > > > >>>>>>>>> Check my mailings about it, it's not easy at least the kerberos part > > > > >>>>>>>>> not, SRV records are used for that normally. > > > > >>>>>>>>> > > > > >>>>>>>>> Are you talking about the webgui or the ldap part ? > > > > >>>>>>>> I would recommend you to step back and describe use-case you have in mind. It > > > > >>>>>>>> is important for us to understand to your use-case to propose optimal solution. > > > > >>>>>>>> > > > > >>>>>>>> Petr^2 Spacek > > > > >>>>>>>> > > > > >>>>>>>>> Cheers, > > > > >>>>>>>>> > > > > >>>>>>>>> Matt > > > > >>>>>>>>> > > > > >>>>>>>>> 2015-03-31 13:56 GMT+02:00 Prashant Bapat : > > > > >>>>>>>>>> Hi, > > > > >>>>>>>>>> > > > > >>>>>>>>>> I'm trying to get 2 FreeIPA servers in a replicated mode behind a load > > > > >>>>>>>>>> balancer, specifically Amazon ELB. > > > > >>>>>>>>>> > > > > >>>>>>>>>> I started with editing the /etc/httpd/conf.d/ipa-rewrite.conf but looks like > > > > >>>>>>>>>> there is more to it than just this file. > > > > >>>>>>>>>> > > > > >>>>>>>>>> Any suggestions ? > > > > >>>>>>>>>> > > > > >>>>>>>>>> Thanks. > > > > >>>>>>>>>> --Prashant > > > > > > > > > > > > -- > > > > Thank you, > > > > Dmitri Pal > > > > > > > > Sr. Engineering Manager IdM portfolio > > > > Red Hat, Inc. > > > > > > > > > > kerberos is load balancer friendly, if you pet it nicely. > > > > > > you generate a principal for the VIP. you then create a keytab for the > > > VIP. you distribute the keytab via SCP (or other secure method) to all > > > load balanced pool members. you must distribute the same exact keytab > > > to all devices. the KVNO for the VIP principal must match in all copies > > > put on the pool members. use "klist -Kket /path/to/file.keytab" to > > > validate this on all pool members. > > > > > > there are additional steps you may want to take, in order to add the > > > individual principal(s) to the same keytab, so that you can access the > > > pool members themselves (not via the VIP). this requires that you > > > distribute the keytab as above, and then add the individual principals > > > to the local copy of the keytab file. > > > > > > example: > > > > > > you have created the principal ldap/ldap.domain.tld for your VIP > > > you have created the keytab for ldap/ldap.domain.tld as ~/ldap.keytab > > > you have copied the keytab file ~/ldap.keytab to server1, server2 and > > > server3 as /etc/ldap.keytab > > > > > > you ssh to server1 and run kadmin. > > > you then add a principal ldap/server1.domain.tld > > > you then add the principal ldap/server1.domain.tld to the already > > > existing keytab /etc/ldap.keytab. > > > quit kadmin > > > > > > when you run "klist -Kket /etc/ldap.keytab" you should see two > > > principals in it. the VIP name and the hostname. > > > > > > lather, rinse, repeat for all servers. > > > > > > keep in mind the administrative overhead of changing names of servers or > > > VIPs. > > > > > > there are other tricks for doing kerberos stuff. i use the same VIP, > > > but different ports in order to access an individual host/service behind > > > the load balancer. this works because the name (of the VIP) stays the > > > same and i just point a different front end port to an individual > > > backend device/port. > > > > > > > This is all true if you just accept connections. > > > > (Un?)fortunately we use delegation within IPA, which requires to use a > > local key to contact the KDC. This action "fixates" what key we are > > going to use to accept incoming context establishment requests. If a > > principal name is not specified then the selected key is usually the > > first in the keytab. > > > > In an IPA setup that will usually be the server's specific key. > > > > In order to use multiple keys in conjunction with IPA we'd have to > > explicitly support. I am not sure if the SSL layer records which name > > was used (perhaps it does if SNI is used, but almost certainly not is > > SAN are used), or if multiple virtual hosts need to be used. > > If we can know what name the client used then we could modify > > mod_auth_gssapi to select a specific name to acquire creds and then > > accept the connection with the correct keys. (Another option would be to > > explicitly retry with each available key if something fails). > > > > I am afraid I won't try to coerce mod_auth_kerb to do that, so this > > option is probably something we can do only post 4.2 and only if we can > > make appropriate modifications. > > > > Simo. > > > the below works for me on apache2.4, with mod_auth_kerb, MIT Kerberos V > and OpenLDAP. I run HAProxy, which holds the A/PTR records for > www.bpk2.com, and load balances to each of the instances i have running > behind it. Fedora 20 with latest everything... > > AuthType Kerberos > AuthName "Enter your credentials" > KrbMethodNegotiate On > KrbMethodK5Passwd On > KrbSaveCredentials On > KrbAuthRealms BPK2.COM > Krb5KeyTab /etc/httpd/conf.d/httpd.keytab > KrbServiceName "HTTP/www.bpk2.com at BPK2.COM" > KrbLocalUserMapping On > KrbDelegateBasic Off > KrbAuthoritative Off > > KrbServiceName explicitly sets the principal to be used. because of > this, i use the front end trick with port on the VIP to access a > specific pool memeber (www:80 --> load balanced via least connections to > all pool members, www:81 --> server1:80, www:82 --> server2:80) Yes, this will work, most kerberized services can work this way, as you can just use a single common key for all the servers and force everything to go through the load balancer. But IPA is more complex and some operations will be performed directly against the specific server name, so you need to keep 2 sets of keys (one for the server name and one for the load balancer name), but that does not work right now. Simo. -- Simo Sorce * Red Hat, Inc * New York From simo at redhat.com Tue Mar 31 17:54:10 2015 From: simo at redhat.com (Simo Sorce) Date: Tue, 31 Mar 2015 13:54:10 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427824216.8302.192.camel@willson.usersys.redhat.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427820780.8302.188.camel@willson.usersys.redhat.com> <1427822496.24621.25.camel@desktop.bpk2.com> <1427824216.8302.192.camel@willson.usersys.redhat.com> Message-ID: <1427824450.8302.195.camel@willson.usersys.redhat.com> On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote: > But IPA is more complex and some operations will be performed directly > against the specific server name, so you need to keep 2 sets of keys > (one for the server name and one for the load balancer name), but that > does not work right now. One experiment that can be done is to remove all "per-server" HTTP services for the IPA server, and instead add their name as aliases on the common load-balancer name. This would mean that all IPA servers would have just one key in their HTTP keytab, but the KDC would release tickets readable by that key for any name the clients may ask for. It is a bit tricky, every time you build a replica you want to load-balance you'll have to go back and remove the service and switch keytabs, but it may be an option. Of course if you brick IPA then you get to keep the pieces :-) Simo. -- Simo Sorce * Red Hat, Inc * New York From markus at die5roths.de Tue Mar 31 17:54:20 2015 From: markus at die5roths.de (Markus Roth) Date: Tue, 31 Mar 2015 19:54:20 +0200 Subject: [Freeipa-users] Setup of freeipa 4.1.3 failed Message-ID: <2588793.PXhtNmgmCt@shdehenw2471> Hi all, I want setup freeipa 4.1.3 on a fresh installed fedora 21. The ipa-server-install shows the following output: configuring NTP daemon (ntpd) [1/4]: stopping ntpd [2/4]: writing configuration [3/4]: configuring ntpd to start on boot [4/4]: starting ntpd Done configuring NTP daemon (ntpd). Configuring directory server (dirsrv): Estimated time 1 minute [1/38]: creating directory server user [2/38]: creating directory server instance [3/38]: adding default schema [4/38]: enabling memberof plugin [5/38]: enabling winsync plugin [6/38]: configuring replication version plugin [7/38]: enabling IPA enrollment plugin [8/38]: enabling ldapi [9/38]: configuring uniqueness plugin [10/38]: configuring uuid plugin [11/38]: configuring modrdn plugin [12/38]: configuring DNS plugin [13/38]: enabling entryUSN plugin [14/38]: configuring lockout plugin [15/38]: creating indices [16/38]: enabling referential integrity plugin [17/38]: configuring certmap.conf [18/38]: configure autobind for root [19/38]: configure new location for managed entries [20/38]: configure dirsrv ccache [21/38]: enable SASL mapping fallback [22/38]: restarting directory server [23/38]: adding default layout [24/38]: adding delegation layout [25/38]: creating container for managed entries [26/38]: configuring user private groups [27/38]: configuring netgroups from hostgroups [28/38]: creating default Sudo bind user [29/38]: creating default Auto Member layout [30/38]: adding range check plugin [31/38]: creating default HBAC rule allow_all [32/38]: initializing group membership [33/38]: adding master entry [34/38]: configuring Posix uid/gid generation [35/38]: adding replication acis [36/38]: enabling compatibility plugin [37/38]: tuning directory server [38/38]: configuring directory to start on boot Done configuring directory server (dirsrv). Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 seconds [1/27]: creating certificate server user [2/27]: configuring certificate server instance [3/27]: stopping certificate server instance to update CS.cfg [4/27]: backing up CS.cfg [5/27]: disabling nonces [6/27]: set up CRL publishing [7/27]: enable PKIX certificate path discovery and validation [8/27]: starting certificate server instance [error] RuntimeError: CA did not start in 300.0s CA did not start in 300.0s The ipa server install log shows this: 2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted 2015-03-31T17:39:35Z DEBUG Waiting for CA to start... 2015-03-31T17:39:36Z 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/cainstance.py", line 526, in __start self.start() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 279, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 229, in start self.wait_until_running() File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 223, in wait_until_running raise RuntimeError('CA did not start in %ss' % timeout) RuntimeError: CA did not start in 300.0s 2015-03-31T17:39:36Z DEBUG [error] RuntimeError: CA did not start in 300.0s 2015-03-31T17:39:36Z DEBUG File "/usr/lib/python2.7/site- packages/ipaserver/install/installutils.py", line 642, in run_script return_value = main_function() File "/usr/sbin/ipa-server-install", line 1183, in main ca_signing_algorithm=options.ca_signing_algorithm) File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", line 520, in configure_instance self.start_creation(runtime=210) 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/cainstance.py", line 526, in __start self.start() File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line 279, in start self.service.start(instance_name, capture_output=capture_output, wait=wait) File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 229, in start self.wait_until_running() File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line 223, in wait_until_running raise RuntimeError('CA did not start in %ss' % timeout) 2015-03-31T17:39:36Z DEBUG The ipa-server-install command failed, exception: RuntimeError: CA did not start in 300.0s I uninstalled the ipa server completely several times and installed it again. But it always stops at the same step with the setup. Can anybody help? Markus. From dpal at redhat.com Tue Mar 31 17:58:10 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 31 Mar 2015 13:58:10 -0400 Subject: [Freeipa-users] Setup of freeipa 4.1.3 failed In-Reply-To: <2588793.PXhtNmgmCt@shdehenw2471> References: <2588793.PXhtNmgmCt@shdehenw2471> Message-ID: <551AE032.9090606@redhat.com> On 03/31/2015 01:54 PM, Markus Roth wrote: > Hi all, > > I want setup freeipa 4.1.3 on a fresh installed fedora 21. > The ipa-server-install shows the following output: > > configuring NTP daemon (ntpd) > [1/4]: stopping ntpd > [2/4]: writing configuration > [3/4]: configuring ntpd to start on boot > [4/4]: starting ntpd > Done configuring NTP daemon (ntpd). > Configuring directory server (dirsrv): Estimated time 1 minute > [1/38]: creating directory server user > [2/38]: creating directory server instance > [3/38]: adding default schema > [4/38]: enabling memberof plugin > [5/38]: enabling winsync plugin > [6/38]: configuring replication version plugin > [7/38]: enabling IPA enrollment plugin > [8/38]: enabling ldapi > [9/38]: configuring uniqueness plugin > [10/38]: configuring uuid plugin > [11/38]: configuring modrdn plugin > [12/38]: configuring DNS plugin > [13/38]: enabling entryUSN plugin > [14/38]: configuring lockout plugin > [15/38]: creating indices > [16/38]: enabling referential integrity plugin > [17/38]: configuring certmap.conf > [18/38]: configure autobind for root > [19/38]: configure new location for managed entries > [20/38]: configure dirsrv ccache > [21/38]: enable SASL mapping fallback > [22/38]: restarting directory server > [23/38]: adding default layout > [24/38]: adding delegation layout > [25/38]: creating container for managed entries > [26/38]: configuring user private groups > [27/38]: configuring netgroups from hostgroups > [28/38]: creating default Sudo bind user > [29/38]: creating default Auto Member layout > [30/38]: adding range check plugin > [31/38]: creating default HBAC rule allow_all > [32/38]: initializing group membership > [33/38]: adding master entry > [34/38]: configuring Posix uid/gid generation > [35/38]: adding replication acis > [36/38]: enabling compatibility plugin > [37/38]: tuning directory server > [38/38]: configuring directory to start on boot > Done configuring directory server (dirsrv). > Configuring certificate server (pki-tomcatd): Estimated time 3 minutes 30 > seconds > [1/27]: creating certificate server user > [2/27]: configuring certificate server instance > [3/27]: stopping certificate server instance to update CS.cfg > [4/27]: backing up CS.cfg > [5/27]: disabling nonces > [6/27]: set up CRL publishing > [7/27]: enable PKIX certificate path discovery and validation > [8/27]: starting certificate server instance > [error] RuntimeError: CA did not start in 300.0s > CA did not start in 300.0s > > The ipa server install log shows this: > > 2015-03-31T17:39:35Z DEBUG The CA status is: check interrupted > 2015-03-31T17:39:35Z DEBUG Waiting for CA to start... > 2015-03-31T17:39:36Z 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/cainstance.py", > line 526, in __start > self.start() > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 279, in start > self.service.start(instance_name, capture_output=capture_output, > wait=wait) > File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line > 229, in start > self.wait_until_running() > File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line > 223, in wait_until_running > raise RuntimeError('CA did not start in %ss' % timeout) > RuntimeError: CA did not start in 300.0s > > 2015-03-31T17:39:36Z DEBUG [error] RuntimeError: CA did not start in 300.0s > 2015-03-31T17:39:36Z DEBUG File "/usr/lib/python2.7/site- > packages/ipaserver/install/installutils.py", line 642, in run_script > return_value = main_function() > > File "/usr/sbin/ipa-server-install", line 1183, in main > ca_signing_algorithm=options.ca_signing_algorithm) > > File "/usr/lib/python2.7/site-packages/ipaserver/install/cainstance.py", > line 520, in configure_instance > self.start_creation(runtime=210) > > 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/cainstance.py", > line 526, in __start > self.start() > > File "/usr/lib/python2.7/site-packages/ipaserver/install/service.py", line > 279, in start > self.service.start(instance_name, capture_output=capture_output, > wait=wait) > > File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line > 229, in start > self.wait_until_running() > > File "/usr/lib/python2.7/site-packages/ipaplatform/redhat/services.py", line > 223, in wait_until_running > raise RuntimeError('CA did not start in %ss' % timeout) > > 2015-03-31T17:39:36Z DEBUG The ipa-server-install command failed, exception: > RuntimeError: CA did not start in 300.0s > > I uninstalled the ipa server completely several times and installed it again. > But it always stops at the same step with the setup. > > Can anybody help? > > Markus. > Please provide install logs, and look at directory server and PKI server logs created during the installation. It seems that Dogtag did not start. It usually does not start when the DS under it does not start. The logs would show that. DS does not start does because of different issues. Can bind to the port for example. So please review the logs and see what they reveal. This might help you with details http://www.freeipa.org/page/Troubleshooting -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. From bpk678 at gmail.com Tue Mar 31 18:10:45 2015 From: bpk678 at gmail.com (Brendan Kearney) Date: Tue, 31 Mar 2015 14:10:45 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427824450.8302.195.camel@willson.usersys.redhat.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427820780.8302.188.camel@willson.usersys.redhat.com> <1427822496.24621.25.camel@desktop.bpk2.com> <1427824216.8302.192.camel@willson.usersys.redhat.com> <1427824450.8302.195.camel@willson.usersys.redhat.com> Message-ID: <1427825445.24621.39.camel@desktop.bpk2.com> On Tue, 2015-03-31 at 13:54 -0400, Simo Sorce wrote: > On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote: > > But IPA is more complex and some operations will be performed directly > > against the specific server name, so you need to keep 2 sets of keys > > (one for the server name and one for the load balancer name), but that > > does not work right now. > > One experiment that can be done is to remove all "per-server" HTTP > services for the IPA server, and instead add their name as aliases on > the common load-balancer name. > > This would mean that all IPA servers would have just one key in their > HTTP keytab, but the KDC would release tickets readable by that key for > any name the clients may ask for. > > It is a bit tricky, every time you build a replica you want to > load-balance you'll have to go back and remove the service and switch > keytabs, but it may be an option. Of course if you brick IPA then you > get to keep the pieces :-) > > Simo. > careful there, as kerberos balks at CNAME records. i think you need to use A records. i ran into a couple odd issues and decided to only use A/PTR records for my stuff and never went "exploring" for options/alternatives. From steve at sylvation.com Tue Mar 31 18:19:57 2015 From: steve at sylvation.com (Steve Neuharth) Date: Tue, 31 Mar 2015 13:19:57 -0500 Subject: [Freeipa-users] freeipa 4.x packages for RHEL? In-Reply-To: <20150331141651.GS3878@redhat.com> References: <20150331141651.GS3878@redhat.com> Message-ID: Excellent. Thanks guys. On Tuesday, March 31, 2015, Alexander Bokovoy wrote: > On Tue, 31 Mar 2015, Steve Neuharth wrote: > >> Hello, >> >> We're currently running RHEL in production and would love to be using all >> the goodness that is FreeIPA 4 including certmonger for certificate >> management. I don't see any mention of 4.x packages available for RHEL in >> the mailing lists and I have run into problems using the 3.3 client >> packages on a 4.x realm. >> >> When will 4.x packages be available for RHEL? >> > They are already available, starting with RHEL7.1. > > -- > / Alexander Bokovoy > -------------- next part -------------- An HTML attachment was scrubbed... URL: From yamakasi.014 at gmail.com Tue Mar 31 18:20:11 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 20:20:11 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427825445.24621.39.camel@desktop.bpk2.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427820780.8302.188.camel@willson.usersys.redhat.com> <1427822496.24621.25.camel@desktop.bpk2.com> <1427824216.8302.192.camel@willson.usersys.redhat.com> <1427824450.8302.195.camel@willson.usersys.redhat.com> <1427825445.24621.39.camel@desktop.bpk2.com> Message-ID: Simo, Yes that was where I was thinking of also, so you say faking by DNS ? @Brendan, cnames are not that nice in networks indeed. 2015-03-31 20:10 GMT+02:00 Brendan Kearney : > On Tue, 2015-03-31 at 13:54 -0400, Simo Sorce wrote: >> On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote: >> > But IPA is more complex and some operations will be performed directly >> > against the specific server name, so you need to keep 2 sets of keys >> > (one for the server name and one for the load balancer name), but that >> > does not work right now. >> >> One experiment that can be done is to remove all "per-server" HTTP >> services for the IPA server, and instead add their name as aliases on >> the common load-balancer name. >> >> This would mean that all IPA servers would have just one key in their >> HTTP keytab, but the KDC would release tickets readable by that key for >> any name the clients may ask for. >> >> It is a bit tricky, every time you build a replica you want to >> load-balance you'll have to go back and remove the service and switch >> keytabs, but it may be an option. Of course if you brick IPA then you >> get to keep the pieces :-) >> >> Simo. >> > > careful there, as kerberos balks at CNAME records. i think you need to > use A records. i ran into a couple odd issues and decided to only use > A/PTR records for my stuff and never went "exploring" for > options/alternatives. > > -- > 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 Tue Mar 31 18:22:16 2015 From: rcritten at redhat.com (Rob Crittenden) Date: Tue, 31 Mar 2015 14:22:16 -0400 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <1427825445.24621.39.camel@desktop.bpk2.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427820780.8302.188.camel@willson.usersys.redhat.com> <1427822496.24621.25.camel@desktop.bpk2.com> <1427824216.8302.192.camel@willson.usersys.redhat.com> <1427824450.8302.195.camel@willson.usersys.redhat.com> <1427825445.24621.39.camel@desktop.bpk2.com> Message-ID: <551AE5D8.3010201@redhat.com> Brendan Kearney wrote: > On Tue, 2015-03-31 at 13:54 -0400, Simo Sorce wrote: >> On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote: >>> But IPA is more complex and some operations will be performed directly >>> against the specific server name, so you need to keep 2 sets of keys >>> (one for the server name and one for the load balancer name), but that >>> does not work right now. >> >> One experiment that can be done is to remove all "per-server" HTTP >> services for the IPA server, and instead add their name as aliases on >> the common load-balancer name. >> >> This would mean that all IPA servers would have just one key in their >> HTTP keytab, but the KDC would release tickets readable by that key for >> any name the clients may ask for. >> >> It is a bit tricky, every time you build a replica you want to >> load-balance you'll have to go back and remove the service and switch >> keytabs, but it may be an option. Of course if you brick IPA then you >> get to keep the pieces :-) >> >> Simo. >> > > careful there, as kerberos balks at CNAME records. i think you need to > use A records. i ran into a couple odd issues and decided to only use > A/PTR records for my stuff and never went "exploring" for > options/alternatives. > Not DNS aliases, Kerberos principal alises. rob From yamakasi.014 at gmail.com Tue Mar 31 19:23:38 2015 From: yamakasi.014 at gmail.com (Matt .) Date: Tue, 31 Mar 2015 21:23:38 +0200 Subject: [Freeipa-users] freeipa behind a load balancer In-Reply-To: <551AE5D8.3010201@redhat.com> References: <551A9160.7060800@redhat.com> <551A9B3F.4010900@redhat.com> <551AA7F2.2070105@redhat.com> <551AAE2C.8070606@redhat.com> <551AB84C.6080004@redhat.com> <1427816508.24621.14.camel@desktop.bpk2.com> <1427820780.8302.188.camel@willson.usersys.redhat.com> <1427822496.24621.25.camel@desktop.bpk2.com> <1427824216.8302.192.camel@willson.usersys.redhat.com> <1427824450.8302.195.camel@willson.usersys.redhat.com> <1427825445.24621.39.camel@desktop.bpk2.com> <551AE5D8.3010201@redhat.com> Message-ID: OK, but we need to do this using IPA or (as IPA does some things different it seems). Anyone testing this perhaps ? (/me is multitasking atm) 2015-03-31 20:22 GMT+02:00 Rob Crittenden : > Brendan Kearney wrote: >> On Tue, 2015-03-31 at 13:54 -0400, Simo Sorce wrote: >>> On Tue, 2015-03-31 at 13:50 -0400, Simo Sorce wrote: >>>> But IPA is more complex and some operations will be performed directly >>>> against the specific server name, so you need to keep 2 sets of keys >>>> (one for the server name and one for the load balancer name), but that >>>> does not work right now. >>> >>> One experiment that can be done is to remove all "per-server" HTTP >>> services for the IPA server, and instead add their name as aliases on >>> the common load-balancer name. >>> >>> This would mean that all IPA servers would have just one key in their >>> HTTP keytab, but the KDC would release tickets readable by that key for >>> any name the clients may ask for. >>> >>> It is a bit tricky, every time you build a replica you want to >>> load-balance you'll have to go back and remove the service and switch >>> keytabs, but it may be an option. Of course if you brick IPA then you >>> get to keep the pieces :-) >>> >>> Simo. >>> >> >> careful there, as kerberos balks at CNAME records. i think you need to >> use A records. i ran into a couple odd issues and decided to only use >> A/PTR records for my stuff and never went "exploring" for >> options/alternatives. >> > > Not DNS aliases, Kerberos principal alises. > > 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 From andrew.holway at gmail.com Tue Mar 31 21:30:59 2015 From: andrew.holway at gmail.com (Andrew Holway) Date: Tue, 31 Mar 2015 23:30:59 +0200 Subject: [Freeipa-users] OTP integrations Message-ID: Hello FreeIPA people, I must say that FreeIPA v4 looks very pretty and I am looking forward to trying out the new features. I'm wondering what application and tools can be used to authenticate with the OTP in freeipa. For instance, if we wanted to set up a VPN that uses it how might we go about that? Is there a common library that I should look out for? Thanks, Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From dpal at redhat.com Tue Mar 31 22:49:15 2015 From: dpal at redhat.com (Dmitri Pal) Date: Tue, 31 Mar 2015 18:49:15 -0400 Subject: [Freeipa-users] OTP integrations In-Reply-To: References: Message-ID: <551B246B.5060104@redhat.com> On 03/31/2015 05:30 PM, Andrew Holway wrote: > Hello FreeIPA people, > > I must say that FreeIPA v4 looks very pretty and I am looking forward > to trying out the new features. > > I'm wondering what application and tools can be used to authenticate > with the OTP in freeipa. For instance, if we wanted to set up a VPN > that uses it how might we go about that? Is there a common library > that I should look out for? With VPN you usually do the following: a) Pick a VPN of your choice based on features and needs you have b) Make sure the VPN server supports different authentication methods. You need at least RADIUS which is the most popular option and I would be surprise to find VPN server that does not talk RADIUS to actually do the authentication. c) Setup freeRADIUS server on Fedora 21/RHEL 7.1/Centos 7.1 (when it happens) box , configure it to do kinit authentication or pam authentication via SSSD against IPA, see freeRADIUS manuals for more details d) Connect VPN server to the RADIUS server e) Provision tokens (or hook IPA to existing OTP solution using another RADIUS server) f) Profit If you have an application that can use RADIUS in such setup you can use FreeIPA 2FA. Also see http://www.freeipa.org/page/Web_App_Authentication how to enable any web application to take advantage of the IPA authentication including 2FA. > > Thanks, > > Andrew > > > > -- Thank you, Dmitri Pal Sr. Engineering Manager IdM portfolio Red Hat, Inc. -------------- next part -------------- An HTML attachment was scrubbed... URL: