On Mon, Feb 29, 2016 at 05:05:41PM +0100, Jakub Hrozek wrote:
> On Mon, Feb 29, 2016 at 04:23:18PM +0100, Jan Pazdziora wrote:
> >
> > I don't really like this approach. You won't be able to do an "OR"
> > operation, granting access to users from gro
se, but
if we miss the rule existence altogether, we've just granted access
we were not supposed to grant.
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
___
sssd-devel mailing list
sssd-devel@lists.fedor
y is to treat the prefix hostname/ as separate "object"
to hostname/admin/. So whatever allow rules you put in for hostname/
will not be inherited / will not affect hostname/admin/.
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
___
problems getting the IPA admins create the HBAC
rules for them, but creating the extra user groups might be frowned
upon by their IT department.
Ideally the premissions should be able to work with the existing
groups and users.
--
Jan Pazdziora
Senior Principal Software Eng
e -- could we run the pam_start with the certificate
as the login name parameter and pam_sss.so would check that the login
name has newlines in it and starts with the correct PEM armor, so
it would do the (equivalent of)
org.freedesktop.sssd.infopipe.Users.FindByCertificate internally?
We would t
ts semantics is likely
to stay.
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Tue, Jun 30, 2015 at 02:15:27PM +0200, Jan Pazdziora wrote:
>
> > If for the applications realm is also useful, then
> > a) the app can query the sssd dbus interface for the matching realm
> > for the domain
> > b) we can also return the realm, although
the
> full given name.
But realms are case sensitive, aren't they? So while it should work
for ad...@example.test, it should not for ad...@example.test.
--
Jan Pazdziora
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
__
.@xxexample.test) ...
So it's nice that the canonical fully qualified name uses the SSSD
domain (the same which I expect PAM stack to return in
PAM_ENV_AUTH_DOMAIN), but: why am I able to authenticate as
ad...@example.test@client.example.tst
even if there is no example.test domain defi
On Tue, Jun 30, 2015 at 02:09:31PM +0200, Sumit Bose wrote:
> On Tue, Jun 30, 2015 at 01:47:01PM +0200, Jan Pazdziora wrote:
> >
> > My only concern is that the domain name as returned by sssd is
> > lowercase which does not really match the realm as seen by say
On Tue, Jun 30, 2015 at 02:00:16PM +0200, Jakub Hrozek wrote:
> On Tue, Jun 30, 2015 at 01:47:01PM +0200, Jan Pazdziora wrote:
> >
> > My only concern is that the domain name as returned by sssd is
> > lowercase which does not really match the realm as seen by say
match the realm as seen by say
mod_auth_kerb or mod_auth_gssapi. But I guess uppercasing the string
is up to consumer of that value.
--
Jan Pazdziora | adelton at #ipa*, #brno
Senior Principal Software Engineer, Identity Management Engineering, Red Hat
___
7;s easy to observe what is
going on without getting into too much detail.
> - anything that causes SSSD to fail to start should also emit a syslog
> message. Admins don't really know about sssd debug logs.
We have a ticket https://fedorahosted.org/sssd/ticket/2687 filed for
this
On Fri, Feb 20, 2015 at 01:54:15PM +0100, Sumit Bose wrote:
>
> So the calling application will see PAM_CONV_ERR but not the backends.
Great.
Thank you,
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
__
If at that point the caller (mod_authnz_pam.c) decides it needs to
redirect to different web page to prompt the user with multiple
password textfields and returns PAM_CONV_ERR, will that count as
failed authentication on the backend side?
--
Jan Pazdziora
Principal Software Engineer, Identity Ma
xtra page to ask for
the second factor?
--
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
On Wed, Nov 12, 2014 at 03:02:43PM +0100, Jakub Hrozek wrote:
> On Wed, Nov 12, 2014 at 02:48:28PM +0100, Jan Pazdziora wrote:
> >
> > I think Requires(pre) is the recommended syntax these days. It helps
> > people remember that they can also use it for other scriptlet time
ommon = %{version}-%{release}
I think Requires(pre) is the recommended syntax these days. It helps
people remember that they can also use it for other scriptlet times if
they need to.
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
___
pes not just define what their are,
but also the behaviour of the rest of the sssd towards that object. It
feels a bit more natural to say "for this domain, these users can
consume the identities", than go the other way round.
--
Jan Pazdziora
Principal Software E
when the client can pass
"u...@domain.they.should.not.know.ABOUT" to pam_start?
--
Jan Pazdziora
Principal Software Engineer, Identity Management Engineering, Red Hat
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.f
s allowed/supposed to use. For this to
work, sssd.conf would need to be amended each time and sssd restarted,
adding new uid of the new Apache setup to the list of
pam_trusted_users.
Why eactly does the list of domains need to be protected by the list
of uids?
--
Jan Pazdzior
sing the PAM stack to find out which domain (and thus
which identity) sssd actually used. So for "login", was it
"lo...@emea.example.com" or "lo...@hq.example.com" that was used?
Do we have a way to return the information to the application?
--
Jan Pazdzi
h "login" or "lo...@emea.example.com"?
--
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat
___
sssd-devel mailing list
sssd-devel@lists.fedorahosted.org
https://lists.fedorahosted.org/mailman/listinfo/sssd-devel
m dependencies if they need to. I wouldn't put it under
sssd just yet -- maybe few years down the road it will become so
widely used that it will be natural to have it in the list. I don't
think we are there yet.
--
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Eng
let IFP spawn a client socket and implement
> only a single 'command' to retry the connection. But that seems like an
> overkill to me. The disadvantage of the signal is that it's also used to
> reset the online status so in theory there might be some timeouts in the
> offl
gt; - support of BOMs - encodings at the beginning of the file
> - adding and or modifying comments
Using set #comment should work.
> - allowing to wrap values
> - processing lists of values in a convenient way
True.
--
Jan Pazdziora | adelton at
rk enhancing Augeas
sssd.conf lens to perhaps support things it cannot do today? For
puppet-based projects and products, expressing the sssd.conf changes
using Augeas is the most native way.
--
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineer
l have general benefit
It can modify the ini files.
> Cons of augeas
> - not integrated into SSSD and GSS proxy
> - does not have advanced features (to be verified)
> - less control and thus slower turn around
It's probably bigger code than smaller-purpose library.
--
Jan P
LookupUserAttr firstname REMOTE_USER_FIRSTNAME
LookupUserAttr lastname REMOTE_USER_LASTNAME
--
Jan Pazdziora | adelton at #ipa*, #brno
Principal Software Engineer, Identity Management Engineering, Red Hat
___
sssd-devel mailing
hough I wonder, should the order be the reverse ?
> I think of it as assignments so mentally I would visualize them as:
> ldap_user_extra_attrs = internal_name_1:ldap_name_1,
> internal_name_2:ldap_name_2
How about
ldap_user_extra_attrs = internal_name_1=ldap_name_1,
internal_name_2=ld
30 matches
Mail list logo
