Re: [Freeipa-users] Storing LDAP credentials in clear text.
On 06/24/2015 09:21 PM, quest monger wrote: I have a IPA server running on CentOS server. I have multiple Solaris boxes that use this IPA server for SSH authentication. When configuring the Solaris hosts to be IPA clients, one of the things i had to do was to configure LDAP. This involved editing the /etc/ldap.conf file. It looks like this now - binddn uid=sudo,cn=sysaccounts,cn=etc,dc=example,dc=com bindpw password in plain text ssl start_tls tls_cacertfile /var/ldap/cer8.db tls_checkpeer yes bind_timelimit 5 timelimit 15 uri ldap://example.com http://example.com/ sudoers_base ou=SUDOers,dc=example,dc=com TLS_CERT /var/ldap/cer8.db As you can see, the bind password is being stored in clear text. Is there a workaround for this? Has someone done this on a Solaris-11 platform? Thanks. AFAIR Solaris should have some kind of the obfuscation scheme at least used to but it might be buried in some manuals. It might be a feature or switch of the ldapclient command. HTH -- 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] hesitate to deploy freeipa
Hi folks, I have a general problem with freeipa: It is *highly* complex and depends upon too many systems working together correctly (IMHO). My concern is, if there is a problem, then the usual tools following the Unix paradigm (do one thing and do it well) don't help anymore. I can speak only for my own stomach, but it turns upside down when I think about this. Your thoughts on this? Regards Harri -- Manage your subscription for 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] UPN suffixes in AD trust
On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote: On 06/25/2015 12:56 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote: On 06/24/2015 06:45 PM, Sumit Bose wrote: On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote: Hi everybody, I established a bidirectional trust between an IPA server (version 4.1.0 on CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local. Everything is working fine, and I'm able to authenticate and logon on a linux host joined to IPA server using AD credentials (username@mydomain.local). But active directory is configured with two more UPN suffixes (otherdomain.com and sub.otherdomain.com), and I cannot logon with credentials using alternative UPN (example: john@otherdomain.com). How can I make this possible? Another trust (ipa trust-add) with the same AD? Manual configuration of krb5 and/or sssd? Have you tried to login to an IPA client or the server? Please try with an IPA server first. If this does not work it would be nice if you can send the SSSD log files from the IPA server which are generated during the logon attempt. Please call 'sss_cache -E' before to invalidate all cached entries so that the logs will contain all needed calls to AD. Using UPN suffixes were added to the AD provider some time ago and the code is available in the IPA provider as well, but I guess no one has actually tried this before. bye, Sumit First of all let me say that i feel like I'm missing some config somewhere.. Changes tried in krb5.conf to support UPN suffixes didn't helped. I can only access the server vi ssh so I've attached the logs for a successful login for account1@mydomain.local and an unsuccessful login for accou...@otherdomain.com done via ssh. Bye and thanks for your help It looks like the request is not properly propagated to sub-domains (the trusted AD domain) but only send to the IPA domain. Would it be possible for you to run a test build of SSSD which might fix this? If yes, which version of SSSD are you currently using? Then I can prepare a test build with the patch on top of this version. bye, Sumit Hi, I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for any test. Here's the packages version for sssd: sssd-common-1.12.2-58.el7_1.6.x86_64 sssd-krb5-1.12.2-58.el7_1.6.x86_64 python-sssdconfig-1.12.2-58.el7_1.6.noarch sssd-krb5-common-1.12.2-58.el7_1.6.x86_64 sssd-ipa-1.12.2-58.el7_1.6.x86_64 sssd-1.12.2-58.el7_1.6.x86_64 sssd-libwbclient-1.12.2-58.el7_1.6.x86_64 sssd-ad-1.12.2-58.el7_1.6.x86_64 sssd-ldap-1.12.2-58.el7_1.6.x86_64 sssd-common-pac-1.12.2-58.el7_1.6.x86_64 sssd-proxy-1.12.2-58.el7_1.6.x86_64 sssd-client-1.12.2-58.el7_1.6.x86_64 Please try the packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 . bye, Sumit Thanks again -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 -- Manage your subscription for 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] UPN suffixes in AD trust
On 06/25/2015 12:56 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote: On 06/24/2015 06:45 PM, Sumit Bose wrote: On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote: Hi everybody, I established a bidirectional trust between an IPA server (version 4.1.0 on CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local. Everything is working fine, and I'm able to authenticate and logon on a linux host joined to IPA server using AD credentials (username@mydomain.local). But active directory is configured with two more UPN suffixes (otherdomain.com and sub.otherdomain.com), and I cannot logon with credentials using alternative UPN (example: john@otherdomain.com). How can I make this possible? Another trust (ipa trust-add) with the same AD? Manual configuration of krb5 and/or sssd? Have you tried to login to an IPA client or the server? Please try with an IPA server first. If this does not work it would be nice if you can send the SSSD log files from the IPA server which are generated during the logon attempt. Please call 'sss_cache -E' before to invalidate all cached entries so that the logs will contain all needed calls to AD. Using UPN suffixes were added to the AD provider some time ago and the code is available in the IPA provider as well, but I guess no one has actually tried this before. bye, Sumit First of all let me say that i feel like I'm missing some config somewhere.. Changes tried in krb5.conf to support UPN suffixes didn't helped. I can only access the server vi ssh so I've attached the logs for a successful login for account1@mydomain.local and an unsuccessful login for accou...@otherdomain.com done via ssh. Bye and thanks for your help It looks like the request is not properly propagated to sub-domains (the trusted AD domain) but only send to the IPA domain. Would it be possible for you to run a test build of SSSD which might fix this? If yes, which version of SSSD are you currently using? Then I can prepare a test build with the patch on top of this version. bye, Sumit Hi, I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for any test. Here's the packages version for sssd: sssd-common-1.12.2-58.el7_1.6.x86_64 sssd-krb5-1.12.2-58.el7_1.6.x86_64 python-sssdconfig-1.12.2-58.el7_1.6.noarch sssd-krb5-common-1.12.2-58.el7_1.6.x86_64 sssd-ipa-1.12.2-58.el7_1.6.x86_64 sssd-1.12.2-58.el7_1.6.x86_64 sssd-libwbclient-1.12.2-58.el7_1.6.x86_64 sssd-ad-1.12.2-58.el7_1.6.x86_64 sssd-ldap-1.12.2-58.el7_1.6.x86_64 sssd-common-pac-1.12.2-58.el7_1.6.x86_64 sssd-proxy-1.12.2-58.el7_1.6.x86_64 sssd-client-1.12.2-58.el7_1.6.x86_64 Thanks again -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 -- Manage your subscription for 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] hesitate to deploy freeipa
On Thu, 2015-06-25 at 15:33 +, Craig White wrote: -Original Message- From: freeipa-users-boun...@redhat.com [mailto:freeipa-users-boun...@redhat.com] On Behalf Of Harald Dunkel Sent: Wednesday, June 24, 2015 12:07 AM To: freeipa-users Subject: [Freeipa-users] hesitate to deploy freeipa Hi folks, I have a general problem with freeipa: It is *highly* complex and depends upon too many systems working together correctly (IMHO). My concern is, if there is a problem, then the usual tools following the Unix paradigm (do one thing and do it well) don't help anymore. I can speak only for my own stomach, but it turns upside down when I think about this. Your thoughts on this? Well, it's a good thing that you don't use XWindows. You already have a humble opinion on something that you aren't using yet? Seriously? It's clearly not for you, thanks for playing. Craig Craig, it is a legitimate question to ask, there is no need to make snarky remarks. Harald, the reason I (and others) started this project many years ago is that trying to set up all components myself was boring and highly error prone, and you would always end up with a bag of parts that had a lot of mismatches, and some functionality was always missing or poor or incomplete, due to the imperfect integration. Yes, the whole project is complex, but not because we like complexity, it is complex because the problem space is complex and we are bound to use existing protocols, which sometimes add in complexity, and we want to offer useful features to admins, so they can think about managing stuff and not about the plumbing all the time. The best option is to study the individual components and how they are integrated, just like you (presumably) studied how a Unix/Linus OS is put together and operates. An OS is not simpler in anyway, but you probably do not see the complexity as menacing anymore because you are familiar with how it works. The same familiarity can be attained with FreeIPA, all the components are available, the configuration directives are mostly where you expect them to be, and all the glue code is in the FreeIPA repositories if you want to go deep into the minutiae, and understand the nuanced integration for some of the plumbing. It can be studied and understood. I would say that time would be better invested in learning how FreeIPA works rather than trying to build your own and be the only one that knows (or forgets) how things were put together ad hoc. Collaborating on a project means you are not alone and can share experiences, ask for help and in general get up to speed with various parts of the infrastructure as you need it, not being forced to know everything like a pro before even starting. This is my humble opinion. Simo. -- Simo Sorce * Red Hat, Inc * New York -- Manage your subscription for the Freeipa-users mailing list: https://www.redhat.com/mailman/listinfo/freeipa-users Go to http://freeipa.org for more info on the project
Re: [Freeipa-users] UPN suffixes in AD trust
On 06/25/2015 02:10 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote: On 06/25/2015 12:56 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote: On 06/24/2015 06:45 PM, Sumit Bose wrote: On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote: Hi everybody, I established a bidirectional trust between an IPA server (version 4.1.0 on CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local. Everything is working fine, and I'm able to authenticate and logon on a linux host joined to IPA server using AD credentials (username@mydomain.local). But active directory is configured with two more UPN suffixes (otherdomain.com and sub.otherdomain.com), and I cannot logon with credentials using alternative UPN (example: john@otherdomain.com). How can I make this possible? Another trust (ipa trust-add) with the same AD? Manual configuration of krb5 and/or sssd? Have you tried to login to an IPA client or the server? Please try with an IPA server first. If this does not work it would be nice if you can send the SSSD log files from the IPA server which are generated during the logon attempt. Please call 'sss_cache -E' before to invalidate all cached entries so that the logs will contain all needed calls to AD. Using UPN suffixes were added to the AD provider some time ago and the code is available in the IPA provider as well, but I guess no one has actually tried this before. bye, Sumit First of all let me say that i feel like I'm missing some config somewhere.. Changes tried in krb5.conf to support UPN suffixes didn't helped. I can only access the server vi ssh so I've attached the logs for a successful login for account1@mydomain.local and an unsuccessful login for accou...@otherdomain.com done via ssh. Bye and thanks for your help It looks like the request is not properly propagated to sub-domains (the trusted AD domain) but only send to the IPA domain. Would it be possible for you to run a test build of SSSD which might fix this? If yes, which version of SSSD are you currently using? Then I can prepare a test build with the patch on top of this version. bye, Sumit Hi, I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for any test. Here's the packages version for sssd: sssd-common-1.12.2-58.el7_1.6.x86_64 sssd-krb5-1.12.2-58.el7_1.6.x86_64 python-sssdconfig-1.12.2-58.el7_1.6.noarch sssd-krb5-common-1.12.2-58.el7_1.6.x86_64 sssd-ipa-1.12.2-58.el7_1.6.x86_64 sssd-1.12.2-58.el7_1.6.x86_64 sssd-libwbclient-1.12.2-58.el7_1.6.x86_64 sssd-ad-1.12.2-58.el7_1.6.x86_64 sssd-ldap-1.12.2-58.el7_1.6.x86_64 sssd-common-pac-1.12.2-58.el7_1.6.x86_64 sssd-proxy-1.12.2-58.el7_1.6.x86_64 sssd-client-1.12.2-58.el7_1.6.x86_64 Please try the packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 . bye, Sumit Hi, I've installed the new RPMs, now if I run on the server: id account1@mydomain.local id accou...@otherdomain.com id accou...@sub.otherdomain.com all the users are found but I'm still unable to log in via ssh with the accounts @otherdomain.com and @sub.otherdomain.com. In attachment the logs for unsuccessful login for user accou...@otherdomain.com. Bye -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 (Thu Jun 25 16:18:54 2015) [sssd[nss]] [nss_clear_memcache] (0x0400): Clearing memory caches. (Thu Jun 25 16:18:54 2015) [sssd[nss]] [nss_orphan_netgroups] (0x0400): Removing netgroups from memory cache. (Thu Jun 25 16:18:58 2015) [sssd[nss]] [accept_fd_handler] (0x0400): Client connected! (Thu Jun 25 16:18:58 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Received client version [1]. (Thu Jun 25 16:18:58 2015) [sssd[nss]] [sss_cmd_get_version] (0x0200): Offered version [1]. (Thu Jun 25 16:18:58 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [accou...@otherdomain.com]. (Thu Jun 25 16:18:58 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7fd3aa0776b0:domains@ipa.mydomain.local] (Thu Jun 25 16:18:58 2015) [sssd[nss]] [sss_dp_get_domains_msg] (0x0400): Sending get domains request for [ipa.mydomain.local][otherdomain.com] (Thu Jun 25 16:18:58 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7fd3aa0776b0:domains@ipa.mydomain.local] (Thu Jun 25 16:18:58 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0100): Requesting info for [accou...@otherdomain.com@ipa.mydomain.local] (Thu Jun 25 16:18:58 2015) [sssd[nss]] [sysdb_search_user_by_upn] (0x0400): No entry with upn [accou...@otherdomain.com] found. (Thu Jun 25 16:18:58 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7fd3aa075e40:1:accou...@otherdomain.com:U@ipa.mydomain.local] (Thu Jun 25 16:18:58 2015) [sssd[nss]] [sss_dp_get_account_msg] (0x0400): Creating request for
Re: [Freeipa-users] hesitate to deploy freeipa
+1. After maintaining these components separately for years, getting everything as a single package with tested integration between them from release-to-release is huge. If you are worried about the complexity, take a look at any good Windows Server documentation set. It's thousands of pages. RH IPA doesn't have this advantage, but the fact that it's gaining traction without that all that says a lot of good things to me. Sent from my iPhone On Jun 25, 2015, at 07:40, Petr Spacek pspa...@redhat.com wrote: On 24.6.2015 09:06, Harald Dunkel wrote: Hi folks, I have a general problem with freeipa: It is *highly* complex and depends upon too many systems working together correctly (IMHO). My concern is, if there is a problem, then the usual tools following the Unix paradigm (do one thing and do it well) don't help anymore. I can speak only for my own stomach, but it turns upside down when I think about this. Your thoughts on this? Yes, FreeIPA is complex. On the other hand, you will get the same complexity when you try to integrate the same services yourself + you will get all the maintenance cost as a bonus. I can speak from my own sysadmin experience :-) -- 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 -- Manage your subscription for 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] UPN suffixes in AD trust
On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote: On 06/25/2015 02:10 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote: On 06/25/2015 12:56 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote: On 06/24/2015 06:45 PM, Sumit Bose wrote: On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote: Hi everybody, I established a bidirectional trust between an IPA server (version 4.1.0 on CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local. Everything is working fine, and I'm able to authenticate and logon on a linux host joined to IPA server using AD credentials (username@mydomain.local). But active directory is configured with two more UPN suffixes (otherdomain.com and sub.otherdomain.com), and I cannot logon with credentials using alternative UPN (example: john@otherdomain.com). How can I make this possible? Another trust (ipa trust-add) with the same AD? Manual configuration of krb5 and/or sssd? Have you tried to login to an IPA client or the server? Please try with an IPA server first. If this does not work it would be nice if you can send the SSSD log files from the IPA server which are generated during the logon attempt. Please call 'sss_cache -E' before to invalidate all cached entries so that the logs will contain all needed calls to AD. Using UPN suffixes were added to the AD provider some time ago and the code is available in the IPA provider as well, but I guess no one has actually tried this before. bye, Sumit First of all let me say that i feel like I'm missing some config somewhere.. Changes tried in krb5.conf to support UPN suffixes didn't helped. I can only access the server vi ssh so I've attached the logs for a successful login for account1@mydomain.local and an unsuccessful login for accou...@otherdomain.com done via ssh. Bye and thanks for your help It looks like the request is not properly propagated to sub-domains (the trusted AD domain) but only send to the IPA domain. Would it be possible for you to run a test build of SSSD which might fix this? If yes, which version of SSSD are you currently using? Then I can prepare a test build with the patch on top of this version. bye, Sumit Hi, I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for any test. Here's the packages version for sssd: sssd-common-1.12.2-58.el7_1.6.x86_64 sssd-krb5-1.12.2-58.el7_1.6.x86_64 python-sssdconfig-1.12.2-58.el7_1.6.noarch sssd-krb5-common-1.12.2-58.el7_1.6.x86_64 sssd-ipa-1.12.2-58.el7_1.6.x86_64 sssd-1.12.2-58.el7_1.6.x86_64 sssd-libwbclient-1.12.2-58.el7_1.6.x86_64 sssd-ad-1.12.2-58.el7_1.6.x86_64 sssd-ldap-1.12.2-58.el7_1.6.x86_64 sssd-common-pac-1.12.2-58.el7_1.6.x86_64 sssd-proxy-1.12.2-58.el7_1.6.x86_64 sssd-client-1.12.2-58.el7_1.6.x86_64 Please try the packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 . bye, Sumit Hi, I've installed the new RPMs, now if I run on the server: id account1@mydomain.local id accou...@otherdomain.com id accou...@sub.otherdomain.com all the users are found but I'm still unable to log in via ssh with the accounts @otherdomain.com and @sub.otherdomain.com. In attachment the logs for unsuccessful login for user accou...@otherdomain.com. Bother, I forgot to add the fix to the pam responder as well, please try new packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=10212212 . bye, Sumit Bye -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 -- Manage your subscription for 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] hesitate to deploy freeipa
On 24.6.2015 09:06, Harald Dunkel wrote: Hi folks, I have a general problem with freeipa: It is *highly* complex and depends upon too many systems working together correctly (IMHO). My concern is, if there is a problem, then the usual tools following the Unix paradigm (do one thing and do it well) don't help anymore. I can speak only for my own stomach, but it turns upside down when I think about this. Your thoughts on this? Yes, FreeIPA is complex. On the other hand, you will get the same complexity when you try to integrate the same services yourself + you will get all the maintenance cost as a bonus. I can speak from my own sysadmin experience :-) -- 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
Re: [Freeipa-users] UPN suffixes in AD trust
On 06/25/2015 05:44 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 04:29:37PM +0200, Giorgio Biacchi wrote: On 06/25/2015 02:10 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 01:06:22PM +0200, Giorgio Biacchi wrote: On 06/25/2015 12:56 PM, Sumit Bose wrote: On Thu, Jun 25, 2015 at 12:22:16PM +0200, Giorgio Biacchi wrote: On 06/24/2015 06:45 PM, Sumit Bose wrote: On Wed, Jun 24, 2015 at 05:11:07PM +0200, Giorgio Biacchi wrote: Hi everybody, I established a bidirectional trust between an IPA server (version 4.1.0 on CentOS 7.1), ipa.mydomain.local and an AD (Windows 2012 r2), mydomain.local. Everything is working fine, and I'm able to authenticate and logon on a linux host joined to IPA server using AD credentials (username@mydomain.local). But active directory is configured with two more UPN suffixes (otherdomain.com and sub.otherdomain.com), and I cannot logon with credentials using alternative UPN (example: john@otherdomain.com). How can I make this possible? Another trust (ipa trust-add) with the same AD? Manual configuration of krb5 and/or sssd? Have you tried to login to an IPA client or the server? Please try with an IPA server first. If this does not work it would be nice if you can send the SSSD log files from the IPA server which are generated during the logon attempt. Please call 'sss_cache -E' before to invalidate all cached entries so that the logs will contain all needed calls to AD. Using UPN suffixes were added to the AD provider some time ago and the code is available in the IPA provider as well, but I guess no one has actually tried this before. bye, Sumit First of all let me say that i feel like I'm missing some config somewhere.. Changes tried in krb5.conf to support UPN suffixes didn't helped. I can only access the server vi ssh so I've attached the logs for a successful login for account1@mydomain.local and an unsuccessful login for accou...@otherdomain.com done via ssh. Bye and thanks for your help It looks like the request is not properly propagated to sub-domains (the trusted AD domain) but only send to the IPA domain. Would it be possible for you to run a test build of SSSD which might fix this? If yes, which version of SSSD are you currently using? Then I can prepare a test build with the patch on top of this version. bye, Sumit Hi, I'm using sssd 1.12.2 (sssd --version) on CentOS 7.1.1503 and I'm available for any test. Here's the packages version for sssd: sssd-common-1.12.2-58.el7_1.6.x86_64 sssd-krb5-1.12.2-58.el7_1.6.x86_64 python-sssdconfig-1.12.2-58.el7_1.6.noarch sssd-krb5-common-1.12.2-58.el7_1.6.x86_64 sssd-ipa-1.12.2-58.el7_1.6.x86_64 sssd-1.12.2-58.el7_1.6.x86_64 sssd-libwbclient-1.12.2-58.el7_1.6.x86_64 sssd-ad-1.12.2-58.el7_1.6.x86_64 sssd-ldap-1.12.2-58.el7_1.6.x86_64 sssd-common-pac-1.12.2-58.el7_1.6.x86_64 sssd-proxy-1.12.2-58.el7_1.6.x86_64 sssd-client-1.12.2-58.el7_1.6.x86_64 Please try the packages at http://koji.fedoraproject.org/koji/taskinfo?taskID=10210844 . bye, Sumit Hi, I've installed the new RPMs, now if I run on the server: id account1@mydomain.local id accou...@otherdomain.com id accou...@sub.otherdomain.com all the users are found but I'm still unable to log in via ssh with the accounts @otherdomain.com and @sub.otherdomain.com. In attachment the logs for unsuccessful login for user accou...@otherdomain.com. Bother, I forgot to add the fix to the pam responder as well, please try new packages from http://koji.fedoraproject.org/koji/taskinfo?taskID=10212212 . bye, Sumit Hi, I've updated all the packages but still no login. Logs follows. Thanks again -- gb PGP Key: http://pgp.mit.edu/ Primary key fingerprint: C510 0765 943E EBED A4F2 69D3 16CC DC90 B9CB 0F34 (Thu Jun 25 18:49:44 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0080): No matching domain found for [accou...@otherdomain.com], fail! (Thu Jun 25 18:49:44 2015) [sssd[nss]] [sss_dp_req_destructor] (0x0400): Deleting request: [0x7f2fd335e6b0:domains@ipa.mydomain.local] (Thu Jun 25 18:49:44 2015) [sssd[nss]] [nss_cmd_getbynam] (0x0400): Running command [17] with input [accou...@otherdomain.com]. (Thu Jun 25 18:49:44 2015) [sssd[nss]] [sss_dp_issue_request] (0x0400): Issuing request for [0x7f2fd335e6b0:domains@ipa.mydomain.local] (Thu Jun 25 18:49:44 2015) [sssd[nss]] [sss_dp_get_domains_msg] (0x0400): Sending get domains request for [ipa.mydomain.local][otherdomain.com] (Thu Jun 25 18:49:44 2015) [sssd[nss]] [sss_dp_internal_get_send] (0x0400): Entering request [0x7f2fd335e6b0:domains@ipa.mydomain.local] (Thu Jun 25 18:49:44 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0400): User [accou...@otherdomain.com] does not exist in [ipa.mydomain.local]! (negative cache) (Thu Jun 25 18:49:44 2015) [sssd[nss]] [nss_cmd_getpwnam_search] (0x0080): No matching domain found for [accou...@otherdomain.com], fail! (Thu Jun 25 18:49:44 2015) [sssd[nss]]
Re: [Freeipa-users] hesitate to deploy freeipa
On 06/25/2015 12:12 PM, Thomas Sailer wrote: Am 25.06.2015 um 17:47 schrieb Simo Sorce: Yes, the whole project is complex, but not because we like complexity, it is complex because the problem space is complex and we are bound to use existing protocols, which sometimes add in complexity, and we want to offer useful features to admins, so they can think about managing stuff and not about the plumbing all the time. Sure, the problem space is a lot more complex than say ls. But I think there is room for improvement, by making the individual tools somewhat more resilient to unexpected behaviour in other components. +1 - just look at the bug lists for freeipa, 389, sssd, dogtag, etc. For example, if there's any nsuniqueid group present in a users entry, login authentication via sssd breaks with a cryptic error message. It would be nice, IMO, if it didn't break or if it at least issued a better error message. Sure. For starters, there's https://fedorahosted.org/389/ticket/48161 Furthermore, a good graphical generic LDAP editor would make the admin's life significantly easier, IMO. I so far haven't found one. There's gq, which works, mostly, but crashes relatively frequently. I'm mostly using ldapvi now, which works quite well but only after studying its manual. Have you tried Apache Directory Studio? Thomas -- Manage your subscription for 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] hesitate to deploy freeipa
Am 25.06.2015 um 17:47 schrieb Simo Sorce: Yes, the whole project is complex, but not because we like complexity, it is complex because the problem space is complex and we are bound to use existing protocols, which sometimes add in complexity, and we want to offer useful features to admins, so they can think about managing stuff and not about the plumbing all the time. Sure, the problem space is a lot more complex than say ls. But I think there is room for improvement, by making the individual tools somewhat more resilient to unexpected behaviour in other components. For example, if there's any nsuniqueid group present in a users entry, login authentication via sssd breaks with a cryptic error message. It would be nice, IMO, if it didn't break or if it at least issued a better error message. Furthermore, a good graphical generic LDAP editor would make the admin's life significantly easier, IMO. I so far haven't found one. There's gq, which works, mostly, but crashes relatively frequently. I'm mostly using ldapvi now, which works quite well but only after studying its manual. Thomas -- Manage your subscription for 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] hesitate to deploy freeipa
On Thu, Jun 25, 2015 at 12:30:24PM -0600, Rich Megginson wrote: On 06/25/2015 12:12 PM, Thomas Sailer wrote: Am 25.06.2015 um 17:47 schrieb Simo Sorce: Yes, the whole project is complex, but not because we like complexity, it is complex because the problem space is complex and we are bound to use existing protocols, which sometimes add in complexity, and we want to offer useful features to admins, so they can think about managing stuff and not about the plumbing all the time. Sure, the problem space is a lot more complex than say ls. But I think there is room for improvement, by making the individual tools somewhat more resilient to unexpected behaviour in other components. +1 - just look at the bug lists for freeipa, 389, sssd, dogtag, etc. For example, if there's any nsuniqueid group present in a users entry, login authentication via sssd breaks with a cryptic error message. It would be nice, IMO, if it didn't break or if it at least issued a better error message. Sure. For starters, there's https://fedorahosted.org/389/ticket/48161 On the SSSD side there's https://fedorahosted.org/sssd/ticket/2605 to deal with this problem. I'm genuinely interested in hearing how we can improve SSSD! Please file tickets or start threads on sssd-users/sssd-devel! -- Manage your subscription for 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 replica failure
On Mon, Jun 22, 2015 at 12:49:01PM -0400, Rob Crittenden wrote:
You aren't seeing a replication agreement. You're seeing the Replication
Update Vector (RUV).
See http://directory.fedoraproject.org/docs/389ds/howto/howto-cleanruv.html
You need to do something like:
# ldapmodify -D cn=directory manager -W -a
dn: cn=clean 97, cn=cleanallruv, cn=tasks, cn=config
objectclass: extensibleObject
replica-base-dn: o=ipaca
replica-id: 97
cn: clean 97
Great, thanks for the clarification.
Curious what's the difference between running the ldapmodify above and
ipa-replica-manage clean-ruv?
Nothing, for the IPA data. This is a remanant from a CA replication
agreement and it was an oversight not to add similar RUV management options
to the ipa-careplica-manage tool.
I'm still seeing some inconsistencies. Forgive me if I'm mis-interpreting any
of this output (still learning the ropes with FreeIPA here)..
Just trying to wrap my head around the RUVs. Trying to follow the docs here:
http://directory.fedoraproject.org/docs/389ds/howto/howto-cleanruv.html
And after running the ldapsearch command to check for obsolete masters
I'm not seeing the replica ID for the old replica we deleted (rep2):
$ ldapsearch -xLLL -D cn=directory manager -W -s sub -b cn=config
objectclass=nsds5replica
Enter LDAP Password:
dn: cn=replica,cn=dc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
objectClass: nsds5replica
objectClass: top
objectClass: extensibleobject
nsDS5ReplicaType: 3
nsDS5ReplicaRoot: dc=ccr,dc=buffalo,dc=edu
nsds5ReplicaLegacyConsumer: off
nsDS5ReplicaId: 4
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindDN: krbprincipalname=ldap/rep2@CCR.BUFFA
LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu
nsDS5ReplicaBindDN: krbprincipalname=ldap/rep3@CCR.BUFFA
LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu
nsState:: BABIa4xVJAABAA==
nsDS5ReplicaName: a0957886-df9c11e4-a351aa45-2e06257b
nsds5ReplicaChangeCount: 1687559
nsds5replicareapactive: 0
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
objectClass: top
objectClass: nsDS5Replica
objectClass: extensibleobject
nsDS5ReplicaRoot: o=ipaca
nsDS5ReplicaType: 3
nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-rep2
falo.edu-pki-tomcat,ou=csusers,cn=config
nsDS5ReplicaBindDN: cn=Replication Manager masterAgreement1-rep3
falo.edu-pki-tomcat,ou=csusers,cn=config
cn: replica
nsDS5ReplicaId: 96
nsDS5Flags: 1
nsState:: YAAPa4xVAAkACgABAA==
nsDS5ReplicaName: c458be8e-df9c11e4-a351aa45-2e06257b
nsds5ReplicaChangeCount: 9480
nsds5replicareapactive: 0
I see:
dn: cn=replica,cn=dc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config)
nsds5replicaid: 4
and
dn: cn=replica,cn=o\3Dipaca,cn=mapping tree,cn=config
nsDS5ReplicaId: 96
In the above output I only see the old replica showing up under:
nsDS5ReplicaBindDN: krbprincipalname=ldap/rep2@CCR.BUFFA...
According to the docs I need the nsds5replicaid for use in the CLEANALLRUV
task?
I also checked the RUV tombstone entry as per the docs:
# ldapsearch -xLLL -D cn=directory manager -W -b dc=ccr,dc=buffalo,dc=edu
'((nsuniqueid=---)(objectclass=nstombstone))'
Enter LDAP Password:
dn: cn=replica,cn=dc\3Dccr\2Cdc\3Dbuffalo\2Cdc\3Dedu,cn=mapping tree,cn=config
cn: replica
nsDS5Flags: 1
objectClass: nsds5replica
objectClass: top
objectClass: extensibleobject
nsDS5ReplicaType: 3
nsDS5ReplicaRoot: dc=ccr,dc=buffalo,dc=edu
nsds5ReplicaLegacyConsumer: off
nsDS5ReplicaId: 4
nsDS5ReplicaBindDN: cn=replication manager,cn=config
nsDS5ReplicaBindDN: krbprincipalname=ldap/rep2@CCR.BUFFA
LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu
nsDS5ReplicaBindDN: krbprincipalname=ldap/rep3@CCR.BUFFA
LO.EDU,cn=services,cn=accounts,dc=ccr,dc=buffalo,dc=edu
nsState:: BADycYxVJAABAA==
nsDS5ReplicaName: a0957886-df9c11e4-a351aa45-2e06257b
nsds50ruv: {replicageneration} 5527f7110004
nsds50ruv: {replica 4 ldap://rep1:389} 5527f77100040
000 558c722800020004
nsds50ruv: {replica 5 ldap://rep3:389} 5537c77300050
000 5582c7f600060005
nsds5agmtmaxcsn:
dc=ccr,dc=buffalo,dc=edu;meTorep3;rep3;389;5;558c572b000a0004
nsruvReplicaLastModified: {replica 4 ldap://rep1:389} 55
8c7204
nsruvReplicaLastModified: {replica 5 ldap://rep3:389} 00
00
nsds5ReplicaChangeCount: 1689129
nsds5replicareapactive: 0
And only see nsds50ruv attributes for rep1, and rep3. However, still seeing
rep2 in the nsDS5ReplicaBindDN.
If I'm parsing this output correct, it appears RUVs for rep2 is already
cleaned? If so, how come the nsDS5ReplicaBindDN still exist?
Also, why is there a nsds50ruv attribute for rep2 listed when I run this query
(but not the others above):
$ ldapsearch -xLLL -D cn=directory manager -W -b cn=mapping tree,cn=config
objectClass=nsDS5ReplicationAgreement
dn:
