Re: [Freeipa-users] AD Trust LDAP Compat mode w/ RHEL5/AIX
I have default_domain_suffix = example.com in my [sssd] section of sssd.conf. On RHEL6/7 systems, I’m able to login or issue any other command without the suffix. Is it safe to assume it works the same in RHEL5? I also tried with domain in all lower case and all upper case as well. On 5/13/15, 9:16 AM, Martin Kosek mko...@redhat.com wrote: On 05/12/2015 10:48 PM, Gould, Joshua wrote: Hopefully I¹m missing something simple. For an IPA user: $ ldapsearch -x ³((uid=ipa_user)(objectclass=posixAccount))² -b dc=ipa,dc=example,dc=com This returns a match. For an AD user: $ ldapsearch -x ³((uid=ad_user)(objectclass=posixAccount))² -b cn=compat,dc=ipa,dc=example,dc=com Does not return any matches. I verified that all my IPA servers have the compatibility plugin enabled. # ipa-compat-manage status Directory Manager password: Plugin Enabled # I may be asking the obvious, but ad_user is fully qualified, right? I.e. adu...@my.ad.domain.test? Testing the log in on the server system as Dmitri advised is also a good test to make. On 5/12/15, 2:14 PM, Alexander Bokovoy aboko...@redhat.com wrote: Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a base cn=compat,dc=ipa,dc=example,dc=com. Simple ldapsearch needs to include proper filter, like what SSSD or nss_ldap are using. slapi-nis is programmed to specifically respond to their queries, not to any request over compat tree. If you want to check from the command line, use a filter like ((uid=AD_user)(objectclass=posixaccount)) -- / Alexander Bokovoy [((uid=goul09)(objectclass=posixAccount))][cn=accounts,dc=unix,dc=osumc, dc =edu] -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust LDAP Compat mode w/ RHEL5/AIX
I can login to a RHEL6/7 server as an IPA user and SU to an AD user and it works fine. I can also login directly as an AD user as well. For my RHEL5 system, I can login as a IPA user but can not su - or login as a AD user. -sh-3.2$ su - ad_user su: user goul09 does not exist As I mentioned before, queries to the compat part of the tree do not return any matches either. On my RHEL6 client, I saw this, which indicates there’s a different approach used. (Tue May 12 12:10:10 2015) [sssd[be[unix.osumc.edu]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [((sAMAccountName=ad_user)(objectclass=user)(sAMAccountName=*)(objectSID=* ))][dc=example,dc=com]. On 5/12/15, 5:24 PM, Dmitri Pal d...@redhat.com wrote: On 05/12/2015 04:48 PM, Gould, Joshua wrote: Hopefully I¹m missing something simple. For an IPA user: $ ldapsearch -x ³((uid=ipa_user)(objectclass=posixAccount))² -b dc=ipa,dc=example,dc=com This returns a match. For an AD user: $ ldapsearch -x ³((uid=ad_user)(objectclass=posixAccount))² -b cn=compat,dc=ipa,dc=example,dc=com Does not return any matches. I verified that all my IPA servers have the compatibility plugin enabled. # ipa-compat-manage status Directory Manager password: Plugin Enabled # Can you log into a server as an IPA user and then su to an AD user with authentication? If that works it means that trust is actually working. I would start with confirming that part. If we know that the trust is actually working we can move to debugging the compat-plugin. If it is not working we would know why nothing is showing up in the tree. Looking at SSSD trace on IPA server that corresponds to the time when you run the LDAP search might shed some light on what is going on. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust LDAP Compat mode w/ RHEL5/AIX
Thank you. I had originally went with the RH documentation. I followed the guide and was able to get my RHEL5 client working. AIX6 is closer to working as well. On 5/13/15, 9:31 AM, Alexander Bokovoy aboko...@redhat.com wrote: Have you actually read the definitive guide we have? https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeipa.org_images _0_0d_FreeIPA33-2Dlegacy-2Dclients.pdfd=AwIFAgc=k9MF1d71ITtkuJx-PdWme51d KbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24m=axYK-L XpDnB6taF3q8whBGDW0q7jDMqS2Wv5kOEFsKks=BnxBd_Jlajh36QyW5WUwRx66b0wQsahXds 0jLtMUgFAe= , linked from https://urldefense.proofpoint.com/v2/url?u=http-3A__www.freeipa.org_page_D ocumentationd=AwIFAgc=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0 y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24m=axYK-LXpDnB6taF3q8whBGDW0q7jDMqS 2Wv5kOEFsKks=uxaGUOkBbxd11-Nx8G2bGLeRCHdDmsc2Oc6CwUf7q5ce= It looks like you have missed it, given your answers and attempts to use non-fully qualified user names. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] AD Trust LDAP Compat mode w/ RHEL5/AIX
We’re using IPA Server 4.1.0-18. We have a trust between IPA and AD with SID mapping. In our setup, AD would be example.com and IPA would be say ipa.example.com. I’m having some issues configuring both RHEL5 and AIX to work with the compat tree. In both cases, kerberos works with IPA and AD users but LDAP only works with IPA users and not AD users. Should AD users be returned if I search uid=AD_user under cn=users,cn=compat,dc=ipa,dc=example,dc=com? Is this where my RHEL5 and AIX clients should be searching? I’m not getting any matches and I’ve verified that the compat plugin is enabled on our servers. I need a little more to go on as far as if I’m looking in the wrong sub-tree or going about this the wrong way. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] AD Trust LDAP Compat mode w/ RHEL5/AIX
Hopefully I¹m missing something simple. For an IPA user: $ ldapsearch -x ³((uid=ipa_user)(objectclass=posixAccount))² -b dc=ipa,dc=example,dc=com This returns a match. For an AD user: $ ldapsearch -x ³((uid=ad_user)(objectclass=posixAccount))² -b cn=compat,dc=ipa,dc=example,dc=com Does not return any matches. I verified that all my IPA servers have the compatibility plugin enabled. # ipa-compat-manage status Directory Manager password: Plugin Enabled # On 5/12/15, 2:14 PM, Alexander Bokovoy aboko...@redhat.com wrote: Can you configure SSSD on RHEL5 clients? A simple LDAP provider with a base cn=compat,dc=ipa,dc=example,dc=com. Simple ldapsearch needs to include proper filter, like what SSSD or nss_ldap are using. slapi-nis is programmed to specifically respond to their queries, not to any request over compat tree. If you want to check from the command line, use a filter like ((uid=AD_user)(objectclass=posixaccount)) -- / Alexander Bokovoy [((uid=goul09)(objectclass=posixAccount))][cn=accounts,dc=unix,dc=osumc,dc =edu] -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Allow user or group to switch user without password and not becoming root
For the NOPASSWD option, I found that using !authenticate in the sudo option is what IPA wants instead. $ ipa sudorule-add-option readfiles Sudo Option: !authenticate - Added option !authenticate to Sudo rule readfiles - From: Dmitri Pal d...@redhat.commailto:d...@redhat.com Organization: Red Hat Reply-To: d...@redhat.commailto:d...@redhat.com d...@redhat.commailto:d...@redhat.com Date: Tuesday, May 12, 2015 at 5:32 PM To: freeipa-users@redhat.commailto:freeipa-users@redhat.com freeipa-users@redhat.commailto:freeipa-users@redhat.com Subject: Re: [Freeipa-users] Allow user or group to switch user without password and not becoming root On 05/12/2015 04:44 PM, Andrey Ptashnik wrote: Hello Team, We have RHEL 7.1 and IPA server 4.1.0 in our environment as well as stack of Oracle software that require existence of local passwordless users like weblogic and oracle. Users log in to servers via domain accounts at IPA server. I’m trying to configure Sudo policy in IPA server that will allow users in the company to log in to servers in IPA domain and switch to weblogic or oracle user without having to enter any passwords, but also without increasing their privileges to root. Using plain /etc/sudoers file it can be accomplished something like below: %users ALL = (root) Users will be who of the IPA sudo rule NOPASSWD: This will be an option that you would put into the sudo rule /bin/su – oracle This will be the command. You create a command and then reference it in the rule. At least this is what I would try. How can I configure this behavior in IPA server? Regards, Andrey -- Thank you, Dmitri Pal Director of Engineering for 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
[Freeipa-users] LDAP bind failing on new IPA setup
We setup our new IPA server (RHEL7) with a trust against our AD domain. The trust and ID range look right in IPA [root sssd]# ipa trust-show Realm name: example.com Realm name: EXAMPLE.COM Domain NetBIOS name: EXAMPLE Domain Security Identifier: S-1-5-21- Trust direction: Two-way trust Trust type: Active Directory domain [root sssd]# ipa idrange-find --all 2 ranges matched dn: cn=EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=examle,dc=com Range name: EXAMPLE.COM_id_range First Posix ID of the range: 200 Number of IDs in the range: 90 First RID of the corresponding RID range: 0 Domain SID of the trusted domain: S-1-5-21- Range type: Active Directory domain range iparangetyperaw: ipa-ad-trust objectclass: ipatrustedaddomainrange, ipaIDrange dn: cn=UNIX.EXAMPLE.COM_id_range,cn=ranges,cn=etc,dc=example,dc=com Range name: UNIX.EXAMPLE.COM_id_range First Posix ID of the range: 36960 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range iparangetyperaw: ipa-local objectclass: top, ipaIDrange, ipaDomainIDRange Number of entries returned 2 [root sssd]# I see that the bind fails but I’m not sure why. Here are the errors. Could someone point me in the right direction please? (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_get_server_opts_from_rootdse] (0x0100): Setting AD compatibility level to [4] (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_send] (0x0400): Attempting kinit (default, host/xxx, UNIX.EXAMPLE.COM, 86400) (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_next_kdc] (0x1000): Resolving next KDC for service EXAMPLE.COM (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [fo_resolve_service_send] (0x0100): Trying to resolve service 'EXAMPLE.COM' (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [get_server_status] (0x1000): Status of server 'domain_controller.EXAMPLE.COM' is 'name resolved' (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [fo_resolve_service_activate_timeout] (0x2000): Resolve timeout set to 6 seconds (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [resolve_srv_send] (0x0200): The status of SRV lookup is resolved (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [get_server_status] (0x1000): Status of server 'domain_controller.EXAMPLE.COM' is 'name resolved' (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [be_resolve_server_process] (0x1000): Saving the first resolved server (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [be_resolve_server_process] (0x0200): Found address for server domain_controller.EXAMPLE.COM: [1.2.3.4] TTL 3600 (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_kinit_kdc_resolved] (0x1000): KDC resolved, attempting to get TGT... (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [create_tgt_req_send_buffer] (0x0400): buffer size: 70 (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_handler_setup] (0x2000): Setting up signal handler up for pid [8734] (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_handler_setup] (0x2000): Signal handler set up for pid [8734] (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [set_tgt_child_timeout] (0x0400): Setting 6 seconds timeout for tgt child (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_process_result] (0x2000): Trace: sh[0x7f6ca7b71b70], connected[1], ops[(nil)], ldap[0x7f6ca7b89f20] (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_process_result] (0x2000): Trace: ldap_result found nothing! (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [write_pipe_handler] (0x0400): All data has been sent! (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_sig_handler] (0x1000): Waiting for child [8734]. (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [child_sig_handler] (0x0100): child [8734] finished successfully. (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [read_pipe_handler] (0x0400): EOF received, client finished (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_get_tgt_recv] (0x0400): Child responded: 0 [FILE:/var/lib/sss/db/ccache_UNIX.EXAMPLE.COM], expired on [1429366284] (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_cli_auth_step] (0x0100): expire timeout is 900 (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sdap_cli_auth_step] (0x1000): the connection will expire at 1429280784 (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sasl_bind_send] (0x0100): Executing sasl bind mech: gssapi, user: host/ipa_server.unix.EXAMPLE.COM (Fri Apr 17 10:11:24 2015) [sssd[be[unix.EXAMPLE.COM]]] [sasl_bind_send] (0x0020): ldap_sasl_bind failed (-2)[Local error] (Fri Apr 17 10:11:24 2015)
[Freeipa-users] FreeIPA 4.1 on RHEL7/Power?
We have the option to deploy our production IPA environment on either x86_64/VMWare or IBM Power. The RHEL7 IDM doc states that only x86_64 is supported. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/prereqs.html#Operating_System_Requirements If we went ahead with either a mix of Power/x86_64 or entirely Power for IDM, would that be a Red Hat supported configuration? The docs are pretty clear, but documentation is usually the last thing to get updated! Anything else as far as current IPA plans/roadmap/etc. for Power vs. x86_64? Joshua -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Sudo rules w/ external users (RHEL7)
On 4/13/15, 11:37 AM, Alexander Bokovoy aboko...@redhat.com wrote: Through external users' groups mechanism we use for any other AD users mapping in HBAC and SUDO. These are not local (not defined in IPA but defined on the host) groups and users but rather AD groups and users. ipa group-add --external gould_group_ext ipa group-add-member gould_group_ext --external=gould@test.osuwmc ipa group-add gould_group ipa group-add-member gould_group --groups=gould_group_ext And now make sudo rule that allows users of gould_group to run needed commands. SSSD will pull in all membership information for gould_group, including AD users. Just curious, but if we don¹t plan on using any IPA native users, could you skip the last two commands and add gould_group_ext to the sudo rule? I¹ve seen this same basic example used for HBAC, but it never was clear to me why the IPA group needed to be added if you¹re only concerned with AD users? Does it need to be added or do the examples include the IPA group because they assume that you¹ll be wanting to use a mix of AD and IPA users for HBAC and sudo? Joshua -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Sudo rules w/ external users (RHEL7)
I’ve looked at the docs and it looks as if I can specify an external user who can have sudo rights via IPA. https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Linux_Domain_Identity_Authentication_and_Policy_Guide/defining-sudorules.html#about-external-sudo The issue being that when I try to add my AD Trust user, it doesn’t allow the @ sign. (ex. gould@test.osuwmc). If I modify the sudo rule to allow all users, I can see that it allows my AD account sudo rights. $ sudo –l User gould@test.osuwmc may run the following commands on this host: (ALL : ALL) ALL How can I configure the rule to allow certain AD users to be able to execute certain sudo rules? -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubleshooting SSO
On 4/6/15, 2:26 PM, Gould, Joshua joshua.go...@osumc.edu wrote: On 4/4/15, 9:57 AM, Sumit Bose sb...@redhat.com wrote: Really strange but SSO is working from the test Windows box to both the IPA server and client. No changes were made other than I added the linux client to the IPA domain. (It was with ipa-client-install, it auto-discovered the values, which I used and I enrolled it with the admin ad-user). Note: ssh connection from Windows test machine to IPA client and IPA server used the exact same saved putty config other than changing the hostname. SSO from Windows to our two IPA clients seems to work intermittently today. (no config changes on either end) In both cases, the first attempted to connect via Putty/SSO failed but signin to password worked. We then disconnected the ssh session and immediately tried SSO via SSH to the same client SSO worked. We were able to replicate this for both clients. SSH output from the failed SSO logins: (Sorry but the kvno and other command were not captured) To Test Client01: -sh-4.2$ export KRB5_TRACE=/dev/stdout -sh-4.2$ kinit ad-user@TEST.OSUWMC [23557] 1428416095.525107: Getting initial credentials for ad-user@TEST.OSUWMC [23557] 1428416095.527977: Sending request (170 bytes) to TEST.OSUWMC [23557] 1428416095.529496: Resolving hostname test-dc-vt01.test.osuwmc. [23557] 1428416095.530694: Sending initial UDP request to dgram 10.0.0.239:88 [23557] 1428416095.531745: Received answer (187 bytes) from dgram 10.0.0.239:88 [23557] 1428416095.531978: Response was not from master KDC [23557] 1428416095.532006: Received error from KDC: -1765328359/Additional pre-authentication required [23557] 1428416095.532039: Processing preauth types: 16, 15, 19, 2 [23557] 1428416095.532053: Selected etype info: etype aes256-cts, salt TEST.OSUWMCad-user, params [23557] 1428416095.532094: PKINIT client has no configured identity; giving up [23557] 1428416095.532111: PKINIT client has no configured identity; giving up [23557] 1428416095.532122: Preauth module pkinit (16) (real) returned: 22/Invalid argument [23557] 1428416095.532132: PKINIT client has no configured identity; giving up [23557] 1428416095.532139: Preauth module pkinit (14) (real) returned: 22/Invalid argument Password for ad-user@TEST.OSUWMC: [23557] 1428416098.700510: AS key obtained for encrypted timestamp: aes256-cts/BA80 [23557] 1428416098.700574: Encrypted timestamp (for 1428416098.622522): plain 301AA011180F32303135303430373134313435385AA1050203097FBA, encrypted DDE7C80B8F1F1B5877E7E05764895E024E65D83CA6BFB633E4281384E03D60F27AB6A6EDF68 C161720933FD481FF881BE203238F816D4393 [23557] 1428416098.700600: Preauth module encrypted_timestamp (2) (real) returned: 0/Success [23557] 1428416098.700605: Produced preauth for next request: 2 [23557] 1428416098.700626: Sending request (248 bytes) to TEST.OSUWMC [23557] 1428416098.701350: Resolving hostname test-dc-vt01.test.osuwmc. [23557] 1428416098.701661: Sending initial UDP request to dgram 10.0.0.239:88 [23557] 1428416098.703161: Received answer (94 bytes) from dgram 10.0.0.239:88 [23557] 1428416098.703374: Response was not from master KDC [23557] 1428416098.703397: Received error from KDC: -1765328332/Response too big for UDP, retry with TCP [23557] 1428416098.703403: Request or response is too big for UDP; retrying with TCP [23557] 1428416098.703408: Sending request (248 bytes) to TEST.OSUWMC (tcp only) [23557] 1428416098.703735: Resolving hostname test-dc-vt01.test.osuwmc. [23557] 1428416098.704667: Initiating TCP connection to stream 10.0.0.239:88 [23557] 1428416098.705090: Sending TCP request to stream 10.0.0.239:88 [23557] 1428416098.706260: Received answer (1649 bytes) from stream 10.0.0.239:88 [23557] 1428416098.706268: Terminating TCP connection to stream 10.0.0.239:88 [23557] 1428416098.706486: Response was not from master KDC [23557] 1428416098.706522: Processing preauth types: 19 [23557] 1428416098.706530: Selected etype info: etype aes256-cts, salt TEST.OSUWMCad-user, params [23557] 1428416098.706538: Produced preauth for next request: (empty) [23557] 1428416098.706546: AS key determined by preauth: aes256-cts/BA80 [23557] 1428416098.706600: Decrypted AS reply; session key is: aes256-cts/21BF [23557] 1428416098.706605: FAST negotiation: unavailable [23557] 1428416098.706629: Initializing KEYRING:persistent:2398410:krb_ccache_v8K2ML2 with default princ ad-user@TEST.OSUWMC [23557] 1428416098.706675: Removing ad-user@TEST.OSUWMC - krbtgt/TEST.OSUWMC@TEST.OSUWMC from KEYRING:persistent:2398410:krb_ccache_v8K2ML2 [23557] 1428416098.706683: Storing ad-user@TEST.OSUWMC - krbtgt/TEST.OSUWMC@TEST.OSUWMC in KEYRING:persistent:2398410:krb_ccache_v8K2ML2 [23557] 1428416098.706754: Storing config in KEYRING:persistent:2398410:krb_ccache_v8K2ML2 for krbtgt/TEST.OSUWMC@TEST.OSUWMC: pa_type: 2 [23557] 1428416098.706771: Removing ad-user@TEST.OSUWMC - krb5_ccache_conf_data/pa_type/krbtgt\/TEST.OSUWMC\@TEST.OSUWMC@X-CACHECONF: from KEYRING:persistent:2398410
Re: [Freeipa-users] Troubleshooting SSO
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 joshua.go...@osumc.edu wrote: Klist in Windows showed one ticket for the IPA domain. #0Client: adm-faru03 @ test.osuwmc Server: krbtgt/UNIX.TEST.OSUWMC @ TEST.OSUWMC KerbTicket Encryption Type: AES-256-CTS-HMAC-SHA1-96 Ticket Flags 0x40a4 - 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@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.osu...@unix.test.OSUWMC = 2 Verbose logging in putty gave the following error: On 3/31/15, 3:30 AM, Sumit Bose sb...@redhat.com 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@TEST.OSUWMC kvno host/name.of.the.ipa-client.to.login@IPA.REALM ssh -v -l adm-faru03@test.osuwmc name.of.the.ipa-client.to.login -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubleshooting SSO
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 0x40a4 - 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@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.osu...@unix.test.OSUWMC = 2 Verbose logging in putty gave the following error: On 3/31/15, 3:30 AM, Sumit Bose sb...@redhat.com 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@TEST.OSUWMC kvno host/name.of.the.ipa-client.to.login@IPA.REALM ssh -v -l adm-faru03@test.osuwmc name.of.the.ipa-client.to.login -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Troubleshooting SSO
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 keepal...@openssh.com want_reply 1 Mar 30 08:50:05 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepal...@openssh.com want_reply 1 Mar 30 08:51:57 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepal...@openssh.com want_reply 1 Mar 30 08:52:57 mid-ipa-vp01 sshd[9317]: debug1: server_input_global_request: rtype keepal...@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@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@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@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@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@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@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@test.osuwmc Mar 30 08:54:00
Re: [Freeipa-users] Troubleshooting SSO
I configured the .k5login per the RH docs. $ cat .k5login adm-faru03@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-sha...@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@openssh.c om,aes256-...@openssh.com,chacha20-poly1...@openssh.com,aes128-cbc,3des-cbc ,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@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@openssh.c om,aes256-...@openssh.com,chacha20-poly1...@openssh.com,aes128-cbc,3des-cbc ,blowfish-cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-cbc@lysato r.liu.se [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: hmac-md5-...@openssh.com,hmac-sha1-...@openssh.com,umac-64-...@openssh.com, umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-etm@op enssh.com,hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac- md5-96-...@openssh.com,hmac-md5,hmac-sha1,umac...@openssh.com,umac-128@open ssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@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-...@openssh.com,hmac-sha1-...@openssh.com,umac-64-...@openssh.com, umac-128-...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-etm@op enssh.com,hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac- md5-96-...@openssh.com,hmac-md5,hmac-sha1,umac...@openssh.com,umac-128@open ssh.com,hmac-sha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd160@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,z...@openssh.com [preauth] Mar 30 09:57:20 mid-ipa-vp01 sshd[12793]: debug2: kex_parse_kexinit: none,z...@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-...@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:
Re: [Freeipa-users] Troubleshooting SSO
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 jpazdzi...@redhat.com 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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubleshooting SSO
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: 100 Number of IDs in the range: 90 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: 23360 Number of IDs in the range: 20 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 Range type: local domain range iparangetyperaw: ipa-local objectclass: top, ipaIDrange, ipaDomainIDRange Number of entries returned 2 # # id adm-faru03@test.osuwmc uid=1398410(adm-faru03@test.osuwmc) gid=1398410(adm-faru03@test.osuwmc) groups=1398410(adm-faru03@test.osuwmc), 23368(citrix_users) # On 3/30/15, 10:55 AM, Jan Pazdziora jpazdzi...@redhat.com 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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubleshooting SSO
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 jpazdzi...@redhat.com 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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Troubleshooting SSO
On 3/30/15, 11:56 AM, Dmitri Pal d...@redhat.com 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-sha...@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@openssh.c om,aes256- g...@openssh.com,chacha20-poly1...@openssh.com,aes128-cbc,3des-cbc,blowfish- cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@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@openssh.c om,aes256- g...@openssh.com,chacha20-poly1...@openssh.com,aes128-cbc,3des-cbc,blowfish- cbc,cast128-cbc,aes192-cbc,aes256-cbc,arcfour,rijndael-...@lysator.liu.se [prea uth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: hmac-md5-...@openssh.com,hmac-sha1-...@openssh.com,umac-64-...@openssh.com, umac-128-e t...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-etm @ope nssh.com,hmac-md5,hmac-sha1,umac...@openssh.com,umac-...@openssh.com,hmac-s ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@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-...@openssh.com,hmac-sha1-...@openssh.com,umac-64-...@openssh.com, umac-128-e t...@openssh.com,hmac-sha2-256-...@openssh.com,hmac-sha2-512-...@openssh.com, hmac-ripemd160-...@openssh.com,hmac-sha1-96-...@openssh.com,hmac-md5-96-etm @ope nssh.com,hmac-md5,hmac-sha1,umac...@openssh.com,umac-...@openssh.com,hmac-s ha2-256,hmac-sha2-512,hmac-ripemd160,hmac-ripemd...@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,z...@openssh.com [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2: kex_parse_kexinit: none,z...@openssh.com [preauth] Mar 30 13:33:35 mid-ipa-vp01 sshd[13750]: debug2:
Re: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX
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 jhro...@redhat.com 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=AwIBAgc=k9MF1d71ITt kuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwo jC24m=Q_JEJ-95yaJpaXtkuLwVxfpPN9Dm_PXXZhd4bG1d0ZYs=6dKxT6QZrN5FoquwdwM62 Y4GJFQ6QqWn6Y6aGj4CXIce= 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.. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX
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@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@test.osuwmc Mar 19 10:48:34 mid-ipa-vp01 sshd[16198]: Accepted password for goul09@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@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@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@test.osuwmc Mar 16 14:28:01 mid-ipa-vp01 sshd[13723]: Accepted password for gould@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@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] -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX
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 jhro...@redhat.com 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=AwIFAwc=k9MF1d71 ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv JwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=bYcFLFGsd6BT_1ozcn 1r1WaYFWJ4_5xT5ddR7d45Z08e= 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-2Dusersd=AwIFAwc=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S FEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1 q4PY8RVJA2iLwWLK_U7aXS1gss=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2ke= Go to https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.orgd=AwIFAwc =k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk 8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=F_LQz74bb hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznwe= for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] Really slow logins with AD SID Mapping vs. POSIX
You are correct. 7.1. Sent with Good (www.good.com) -Original Message- From: Jakub Hrozek [jhro...@redhat.commailto:jhro...@redhat.com] Sent: Thursday, March 19, 2015 11:37 AM Eastern Standard Time To: Gould, Joshua Cc: freeipa-users@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 jhro...@redhat.com 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=AwIFAwc=k9MF1d71 ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_Sv JwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=bYcFLFGsd6BT_1ozcn 1r1WaYFWJ4_5xT5ddR7d45Z08e= 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-2Dusersd=AwIFAwc=k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8S FEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1 q4PY8RVJA2iLwWLK_U7aXS1gss=uJUobRCfTZ-jS6M4XSLW8ScMXv_1sIQ-OSoy54M7b2ke= Go to https://urldefense.proofpoint.com/v2/url?u=http-3A__freeipa.orgd=AwIFAwc =k9MF1d71ITtkuJx-PdWme51dKbmfPEvxwt8SFEkBfs4r=C8H0y1Bn8C6Mf5i9qrqkUDy3xSk 8zPbIs_SvJwojC24m=YA1l-b8irE5VE9qVc1q4PY8RVJA2iLwWLK_U7aXS1gss=F_LQz74bb hG6_BKutjgbdRMTvIBRYggIgNj1QZoEznwe= for more info on the project -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] sssd options ignored?
On 3/18/15, 3:55 AM, Sumit Bose sb...@redhat.com 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 = 10 ldap_idmap_range_size = 90 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. -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] sssd options ignored?
On 3/18/15, 9:48 AM, Alexander Bokovoy aboko...@redhat.com wrote: On Wed, 18 Mar 2015, Gould, Joshua wrote: On 3/18/15, 4:28 AM, Alexander Bokovoy aboko...@redhat.com 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 hostname of AD DC $ 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@mid-ipa-vp01 ~]$ kdestroy kdestroy: No credentials cache found while destroying cache [goul09@mid-ipa-vp01 ~]$ kinit admin Password for ad...@unix.test.OSUWMC: [goul09@mid-ipa-vp01 ~]$ kvno -S cifs svr-addc-vt01.test.osuwmc cifs/svr-addc-vt01.test.osuwmc@TEST.OSUWMC: kvno = 16 [goul09@mid-ipa-vp01 ~]$ klist -ef Ticket cache: FILE:/tmp/krb5cc_998 Default principal: ad...@unix.test.OSUWMC Valid starting Expires Service principal 03/18/2015 10:15:28 03/19/2015 10:15:25 krbtgt/unix.test.osu...@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.osu...@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@TEST.OSUWMC Flags: FA, Etype (skey, tkt): aes256-cts-hmac-sha1-96, aes256-cts-hmac-sha1-96 [goul09@mid-ipa-vp01 ~]$ -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] 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@test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x0400): Processing user farus@test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x1000): Mapping user [farus@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@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 = 90 #ldap_idmap_range_range = 3602000 ldap_idmap_range_size=100 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
Re: [Freeipa-users] sssd options ignored?
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=10 --range-size=90 --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: 10 Number of IDs in the range: 90 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 = 10 ldap_idmap_range_size = 90 From: Gould, Joshua Gould joshua.go...@osumc.edu Date: Tuesday, March 17, 2015 at 6:08 PM To: freeipa-users@redhat.com freeipa-users@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@test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x0400): Processing user farus@test.osuwmc (Tue Mar 17 17:10:34 2015) [sssd[be[unix.test.osuwmc]]] [sdap_save_user] (0x1000): Mapping user [farus@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@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 = 90 #ldap_idmap_range_range = 3602000 ldap_idmap_range_size=100 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
Re: [Freeipa-users] AD integration: Could not convert objectSID to a UNIX 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 = 182460 ldap_idmap_range_size = 200 Setting these two identically let me resolve AD ID¹s with the id command. Hopefully this works for you too. From: Guertin, David S. guer...@middlebury.edu Date: Tuesday, March 17, 2015 at 11:18 AM To: freeipa-users@redhat.com freeipa-users@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: 182460 Number of IDs in the range: 200 First RID of the corresponding RID range: 1000 First RID of the secondary RID range: 1 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: 1 Number of IDs in the range: 200 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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] IPA Trusts
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 erinn.looneytri...@gmail.com 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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] New Trust - AD id's not resolving
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@mid-ipa-vp02 ~]$ id farus@test.osuwmc id: farus@test.osuwmc: no such user I enabled debugging in sssd. Here¹s what I saw in the lookup for ³id farus@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@mid-ipa-vp01 ~]$ kinit admin Password for ad...@unix.test.OSUWMC: [gould@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-X-X-X Trust direction: Two-way trust Trust type: Active Directory domain [gould@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 -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
[Freeipa-users] ipa-server setup with external CA fails
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=mscs 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
Re: [Freeipa-users] ipa-server setup with external CA fails
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 d...@redhat.com 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=mscs 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
