|
Delivered-To: oezr@gapps.redhat.com
|
|
Received: by 2002:a5d:8243:0:0:0:0:0 with SMTP id n3csp1931889ioo;
|
|
Fri, 8 Feb 2019 07:46:52 -0800 (PST)
|
|
X-Google-Smtp-Source: AHgI3IYZGuZeDVV24GG5nrIKsaWmFjlWmLcZtSdtqXWi4yWqOwUmmpduVPGUJsTvJL4QRKCXe5a7
|
|
X-Received: by 2002:ac8:7412:: with SMTP id p18mr16556130qtq.176.1549640812620;
|
|
Fri, 08 Feb 2019 07:46:52 -0800 (PST)
|
|
ARC-Seal: i=1; a=rsa-sha256; t=1549640812; cv=none;
|
|
d=google.com; s=arc-20160816;
|
|
b=kt0QkoGhyxsBnMSF46k242wzNk4aBYFMKhBdYw0RCgWCEW8sT+5atqHqyLqsEylsY2
|
|
0Mvd89UdDg82HzuRs4E6Nqr9HDZO7g4sMWA6xUCrxbFvn1I0E/ebI8UD/GGFf1EbwljJ
|
|
dz65DLjXaWb7Zxj8EQRojBJXlM1qOyswnFCRp2o5KvMwTtn1pcP6WeF3QR8leafzoK8V
|
|
AdSc7fWlggXa0V4iGo6Q8yKlYJ7x/PG3wxDrh/7NjSbWISklnSyE0dSmvIj0PzEFNZw0
|
|
IhYj4UzuI35es2yBjduuXdWCJYuA627hXTr/nQPMDBuOkutgULuNe9VWPSXWFWzw05lx
|
|
vf+A==
|
|
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816;
|
|
h=content-transfer-encoding:mime-version:references:in-reply-to
|
|
:message-id:date:subject:cc:to:from:delivered-to;
|
|
bh=mxm+tM2LRleZ/rc7iRkKW8sj1mG9Ub4KbQfpKXTUmmw=;
|
|
b=xqleADUxbOlX0/vy7CTb2mHsNDn56oe653mDSjSwOsZO4mj6tvhDwfjqiBPZtjF980
|
|
GeYi1PvR2kZvT3kUS0MvZ2/gJKted1YHkzvS0q2UYHMrjS/MiR5kkexQ/Y2pfpi3SZ+F
|
|
EhmwE6eK4pTmvalN+yAimYUyyoETQez7sCfdA8wQ+mUTssv6qw+iAsMAhheB9qckcLIv
|
|
d/dmxSVYDKFDMpGVZFTLU5qwgkb+O113YcBinrwpP1y7XVVCNwDppjC6MK2tUziZCW5D
|
|
QF79ioHBgrekD+djkSr6OMFoXfZCVNaKhwepEeYTExALwwEaIYFc9WHnWN9NGL96i9Tv
|
|
N7Pw==
|
|
ARC-Authentication-Results: i=1; mx.google.com;
|
|
spf=pass (google.com: domain of mhulan@redhat.com designates 209.85.221.72 as permitted sender) smtp.mailfrom=mhulan@redhat.com
|
|
Return-Path: <mhulan@redhat.com>
|
|
Received: from mx1.redhat.com (mx1.redhat.com. [209.132.183.28])
|
|
by mx.google.com with ESMTPS id m186si1786215qkf.144.2019.02.08.07.46.52
|
|
for <oezr@gapps.redhat.com>
|
|
(version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128);
|
|
Fri, 08 Feb 2019 07:46:52 -0800 (PST)
|
|
Received-SPF: pass (google.com: domain of mhulan@redhat.com designates 209.85.221.72 as permitted sender) client-ip=209.85.221.72;
|
|
Authentication-Results: mx.google.com;
|
|
spf=pass (google.com: domain of mhulan@redhat.com designates 209.85.221.72 as permitted sender) smtp.mailfrom=mhulan@redhat.com
|
|
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16])
|
|
(using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
|
|
(No client certificate requested)
|
|
by mx1.redhat.com (Postfix) with ESMTPS id 93AC287628
|
|
for <oezr@gapps.redhat.com>; Fri, 8 Feb 2019 15:46:51 +0000 (UTC)
|
|
Received: by smtp.corp.redhat.com (Postfix)
|
|
id 8ABC95C269; Fri, 8 Feb 2019 15:46:51 +0000 (UTC)
|
|
Delivered-To: oezr@redhat.com
|
|
Received: from mx1.redhat.com (ext-mx06.extmail.prod.ext.phx2.redhat.com [10.5.110.30])
|
|
by smtp.corp.redhat.com (Postfix) with ESMTPS id 83B555C22E
|
|
for <oezr@redhat.com>; Fri, 8 Feb 2019 15:46:51 +0000 (UTC)
|
|
Received: from mail-wr1-f72.google.com (mail-wr1-f72.google.com [209.85.221.72])
|
|
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
|
|
(No client certificate requested)
|
|
by mx1.redhat.com (Postfix) with ESMTPS id 333B12D7E8
|
|
for <oezr@redhat.com>; Fri, 8 Feb 2019 15:46:51 +0000 (UTC)
|
|
Received: by mail-wr1-f72.google.com with SMTP id e2so1440906wrv.16
|
|
for <oezr@redhat.com>; Fri, 08 Feb 2019 07:46:51 -0800 (PST)
|
|
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
|
|
d=1e100.net; s=20161025;
|
|
h=x-gm-message-state:from:to:cc:subject:date:message-id:in-reply-to
|
|
:references:mime-version:content-transfer-encoding;
|
|
bh=mxm+tM2LRleZ/rc7iRkKW8sj1mG9Ub4KbQfpKXTUmmw=;
|
|
b=Jzsb2FfZL2vjK28uZ6jF0mu9ifi7KLVcT9hGQsg3+n9WwxAUnwEt1RXKeISrswzAIO
|
|
YqI56XUE5M5fUYTS0gYWRcb8RGLERTyje1FYarURP28yMfsigj2htv2QUbWyukPSvkUn
|
|
WF8wYeJW2X6d3ElsaXnJK2qQwOBEg21BvXT67Ct/JjTinGVnw9pzPse+oC2eOE4YubPe
|
|
akmZZiF6wKG+VYeboowymd+Ulrrw/q9KLjiafhv3FVXtlrBE4W2OBPXCplKlqaCFWI38
|
|
XYxqQmRtGYUyHXQCrOO3mT10WVdemUiE+6LkXCZCoDVFq+/AWohTkwf6Jhf+RBEKsQCs
|
|
4wXw==
|
|
X-Gm-Message-State: AHQUAuYphTsbmfe/Wpysz0Jw/QUACY6MZxMa5sj4n3gHWM53+sZxMa8j
|
|
ENqwoWeYjk3W7QW2iC/qsiP4jvlESvqJskZQYI1+uwmv+9ePFTXXJCBsRR1Qoe759FHRpYJmKlp
|
|
zNKaYnwn+JQ==
|
|
X-Received: by 2002:adf:e3cb:: with SMTP id k11mr2236153wrm.263.1549640809274;
|
|
Fri, 08 Feb 2019 07:46:49 -0800 (PST)
|
|
X-Received: by 2002:adf:e3cb:: with SMTP id k11mr2236123wrm.263.1549640808889;
|
|
Fri, 08 Feb 2019 07:46:48 -0800 (PST)
|
|
Received: from tony.localnet (ip4-83-240-30-43.cust.nbox.cz. [83.240.30.43])
|
|
by smtp.googlemail.com with ESMTPSA id v6sm4786697wrd.88.2019.02.08.07.46.47
|
|
(version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256);
|
|
Fri, 08 Feb 2019 07:46:47 -0800 (PST)
|
|
From: Marek =?ISO-8859-1?Q?Hul=E1n?= <mhulan@redhat.com>
|
|
To: satellite-tech-list@redhat.com
|
|
Cc: Bryan Kearney <bkearney@redhat.com>, Ondrej Ezr <oezr@redhat.com>
|
|
Subject: Re: [satellite-tech] External ldap usergroups - change proposal
|
|
Date: Fri, 08 Feb 2019 16:46:46 +0100
|
|
Message-ID: <3724194.YL3Voepitn@tony>
|
|
In-Reply-To: <09407e4f-466a-c2da-b76d-6b2ff80a8049@redhat.com>
|
|
References: <CAKk__X4KErtX0VsdZ40YLZ0xnp_7Xx53kaP=tCypYi+TRWkg3Q@mail.gmail.com> <09407e4f-466a-c2da-b76d-6b2ff80a8049@redhat.com>
|
|
MIME-Version: 1.0
|
|
Content-Transfer-Encoding: quoted-printable
|
|
Content-Type: text/plain; charset="UTF-8"
|
|
X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16
|
|
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Fri, 08 Feb 2019 15:46:51 +0000 (UTC)
|
|
|
|
Having two ldap records in different server each with different login is no=
|
|
t a=20
|
|
problem. The problem arises when two ldaps are linked and both contain same=
|
|
=20
|
|
ldap login but in fact these are two different people.
|
|
|
|
Well it could be acquisition of two companies, both employing John Connor,=
|
|
=20
|
|
both Johns have login jconnor. After acquisition, before single LDAP is use=
|
|
d,=20
|
|
it can be added as second auth source in order to grant access to shared=20
|
|
Satellite instance. While second John couldn't login, the first would gain=
|
|
=20
|
|
second John's permissions. This feels as bug.
|
|
|
|
The valid use case I see is this. There's one LDAP managed by my company=20
|
|
sysadmin departments, it's very hard to convince them, I need a new account=
|
|
=20
|
|
for new employee or that existing colleague needs more permissions. So for=
|
|
=20
|
|
colleagues in my group, I install separate LDAP. While users authenticate=20
|
|
against comapny LDAP and have some basic permissions granted in it, I can d=
|
|
o=20
|
|
more granular and faster permissions modifications there. This use case wou=
|
|
ld=20
|
|
be dropped.
|
|
|
|
Both seems as quite edge cases and I'd be all from dropping this. I think=20
|
|
99.9% of users will not notice. That means, we'd only sync usergroups from=
|
|
=20
|
|
auth source, that was used for user authentication (auth source is linked o=
|
|
n=20
|
|
user object). That does not affect ability to have two or more auth sources=
|
|
=2E=20
|
|
In fact customers today define multiple authsource using the same ldap=20
|
|
instance in order to have different default default taxonomies for users in=
|
|
=20
|
|
different user groups. This would still work, unless they combine permissio=
|
|
ns=20
|
|
from multiple taxonomies.
|
|
|
|
It would be great to have ack from PM and/or people from the field. If ther=
|
|
e's=20
|
|
no strong opinion, we'll proceed with the change.
|
|
|
|
Thanks
|
|
|
|
=2D-
|
|
Marek
|
|
|
|
On pond=C4=9Bl=C3=AD 4. =C3=BAnora 2019 16:37:02 CET Bryan Kearney wrote:
|
|
> Why would you have 2 different ldaps with different unique user names?
|
|
> -- bk
|
|
>=20
|
|
> On 2/4/19 3:16 AM, Ondrej Ezr wrote:
|
|
> > Hi all,
|
|
> >=20
|
|
> > I am working on speed up synchronization of LDAP groups at user login.
|
|
> >=20
|
|
> > I have stumbled upon a problem:
|
|
> > Currently we are supposing, that if there is a login matching the user's
|
|
> > login in any LDAP (not just the one user is authenticated by), the user
|
|
> > is supposed to be a member of that group.
|
|
> >=20
|
|
> > So let's have two LDAPs A and B. We have G1 ldap B, and user User1
|
|
> > authenticated by ldap A. Ldap B is saying G2 has a member called User2.
|
|
> >=20
|
|
> > Currently if we got external group connected to the G2 LDAP group, user
|
|
> > is a member of that external group.
|
|
> >=20
|
|
> > I see a problem in there, because user User1, can be a totally different
|
|
> > user and thus it can present a security issue of adding permissions to
|
|
> > the user he shouldn't have.
|
|
> >=20
|
|
> > On the other hand some users can already use it like that and they can
|
|
> > have this handled on the LDAP side.
|
|
> >=20
|
|
> > But as we can't assure this on the Satellite side, I would like to say
|
|
> > this behaviour is a *BUG*.
|
|
> >=20
|
|
> > I would like to hear your thoughts on this, before I will say it's a bug
|
|
> > and repair it.
|
|
> >=20
|
|
> > Thanks for your time and considerations,
|
|
> > Ond=C5=99ej Ezr
|
|
|
|
|
|
|
|
|
