[PATCH SET] AD_PROVIDER: ad_enabled_domains
by Petr Cech
Hello list,
there is patch set attached resolving:
https://fedorahosted.org/sssd/ticket/2828
You can also see:
https://github.com/celestian/sssd/commits/subdomains_v2
This patch set is without tests yet.
I will send tests after Pavel B. refactor of AD provider.
I would like to remark couple of things:
1) Option ad_enabled_domains disabled by default.
2) We use labels master domain and root domain in code. Master domain
belongs to one that SSSD is connected to. Root domain means AD forest root.
3) There is a lot of different environment setup. So this option has
slightly different meaning in each of them.
4) There is secret feature if you forget fill in master domain to the
option it will be added automatically.
What is this option good for?
Let's imagine environment like:
A (forest root)
|
|-- S1 (SSSD client)
|
|-- B (AD client)
| |
| |-- S2 (SSSD client)
|
|-- C (AD client)
|
|-- D (AD client)
A ... forest root
B, C, D ... AD clients
S1 ... SSSD client connected to A
S2 ... SSSD client connected to B
We could write:
* on S1: ad_enabled_domain = A, B, C
and then S1 will not attempt to connect D.
* on S1: ad_enabled_domain = B, C
the same as above because A is automagically
filled in.
* on S2: ad_enabled_domain = A, C
and then B is filled in automatically
and S2 will not attempt to connect D.
* on S2: ad_enabled_domain = C
and then B is filled in automatically
and S2 will not attempt to connect D and A.
(I am wondering that it is possible but it
happened during manual testing.)
Regards
--
Petr^4 Čech
7 years, 8 months
[PATCH] FO: Set port to NOT_WORKING when trying a next server
by Jakub Hrozek
Hi,
attached is a patch that I think is correct and it did solve a bug I was
seeing, but I'm not sure if it's the right thing to do since the code
was stable since 2009..
What I was seeing was a scenario where an LDAP server was listening on port
389, so we were able to connect there with a socket, but then all searches
timed out during rootDSE discovery.. What happened in the sdap_id_ops.c
code was that we hit this part:
810 switch (retval) {
811 case EIO:
812 ---> case ETIMEDOUT:
813 /* this currently the only possible communication error after connection is established */
814 communication_error = true;
815 break;
816
817 default:
818 communication_error = false;
819 break;
820 }
821
And then we went here, because the connection was already established:
822 if (communication_error && current_conn != 0
823 && current_conn == op->conn_cache->cached_connection) {
824 /* do not reuse failed connection */
825 op->conn_cache->cached_connection = NULL;
826
827 DEBUG(SSSDBG_FUNC_DATA,
828 "communication error on cached connection, moving to next server\n");
829 ----> be_fo_try_next_server(op->conn_cache->id_conn->id_ctx->be,
830 op->conn_cache->id_conn->service->name);
831 }
But I admit I don't understand why does be_fo_try_next_server() set the
port status to NEUTRAL. That caused the connection code to run again,
hit the same timeout issue and then cycle again and again..
Can anyone parse from the code why do we set the port to neutral instead
of not_working in be_fo_try_next_server() ?
7 years, 9 months
[PATCH] SYSDB: Fixing DB update
by Petr Cech
Hi,
there is patch for #3023 attached.
Reason for this patch is explained in commit message.
I am open to discussion. In my opinion we don't need to connect sysdb
pointer with domain structure because it is not used in other upgrade
functions too.
Regards
--
Petr^4 Čech
7 years, 9 months
[PATCH] PAM: Allow to configure pam services for smartcards
by Lukas Slebodnik
ehlo,
attached patch should fix ticket #2926
The default case (no adding, no removing services) is tested
by pam-srv-tests.
If the patch is not ready for stable branch sssd-1-13
then we might merge this case with GPO code which uses slightly
modified way using hash tables.
LS
7 years, 9 months
[PATCH] SSH-CERT: always initialize cert_verify_opts
by Sumit Bose
Hi,
please find attached two small patches related to the conversion of the
public key in a certificate to a public ssh-key.
The first fixes an issue which should only happen in master. The second
might be useful for already released versions as well, but I would wait
until we get a report that the old scheme fails with some certificates.
bye,
Sumit
7 years, 9 months
[PATCH] sudo: solve problems with fully qualified names
by Pavel Březina
See commit message for details.
Two configurations needs to be tested -- a domain with
use_fully_qualified_name = true and configuration with IPA-AD trusts
where default_domain_suffix is set to AD domain.
7 years, 9 months
fully qualified sysdb names for users and groups
by Jakub Hrozek
Hi,
here is my branch that implements using the fully qualified names in sysdb
for users and groups:
https://github.com/jhrozek/sssd/commits/sysdb-fqdn
The SSSD code changes are done. There are some downstream tests that are
failing (some sudo and some HBAC tests), but I think I can chase those
down quickly.
But -- I still don't have the upgrade code written and I only tested the
IPA overrides and IPA-AD trust code manually, so there might be a lot of
bugs there. It is also a lot of stuff to review.
With that in mind, I would like to ask other developers for opinions --
should we still pursue pushing this refactoring into 1.14? Or should we
release 1.14.0 first and push this patchset as the first thing into
1.15?
I'm really on the fence myself.
7 years, 9 months