On Wed, 2009-11-18 at 11:15 -0500, Simo Sorce wrote:
>
> It doesn't hurt to.
Agreed. Additional configurability is great, as long as reasonable
defaults are in place.
> We may decide to make "*" the default though.
Seems this has been decided already, which is of course, excellent!
Cheers,
b
On Tue, 2009-11-17 at 09:02 -0500, Simo Sorce wrote:
>
> We don't support shadow maps so we never return shadow information
> currently.
So you should _never_ return an "x" in the passwd map either then. It
doesn't even need a distro/site/admin configuration option. Simply
change the "x" that
On Mon, 2009-11-16 at 18:38 -0500, Brian J. Murrell wrote:
>
> Does this patch do anything about not returning "x" in the password
> field of the passwd map
NM. I just saw the patch for #266. And commented on it.
b.
signature.asc
Description: This is a digitally
On Tue, 2009-11-17 at 01:01 +0100, Jakub Hrozek wrote:
> Per the discussion on sssd-devel list, nss_sss should not return a
> hardcoded value but this should rather be configurable to allow whatever
> the OS or distribution thinks is the best for the particular case.
I disagree with the nature of
On Mon, 2009-11-16 at 14:06 +0100, Sumit Bose wrote:
> Hi,
>
> this patch should fix #279 by ignoring the shadow attributes by
> default.
Does this patch do anything about not returning "x" in the password
field of the passwd map if the shadow object class is not present in the
user's LDAP entry
On Wed, 2009-11-11 at 19:03 -0500, Simo Sorce wrote:
>
> I have tested this yesterday (with git master), if you set FILE:%
> d/krb5cc_%U sssd will happily refresh the crdentials at screen unlock.
Ahhh. ~light bulb goes on~ I am finally coming around to what you are
saying. Wow. It's even mor
On Wed, 2009-11-11 at 09:35 +0100, Sumit Bose wrote:
>
> ah, sorry, I misinterpreted your original post. I thought a ccache file
> wasn't created at all when using gnome-screensaver.
No, you didn't mis-interpret I don't think. Here's what happened:
1. Logged into gnome, got a ccache file
On Mon, 2009-11-09 at 21:19 +0100, Sumit Bose wrote:
>
> Does this mean you are still seeing [Credentials cache I/O operation
> failed XXX] in krb5_child.log?
No. I am seeing nothing new at all in the krb5_child.log when
authentications happen.
> this indicates that everything is ok, please se
On Mon, 2009-11-09 at 10:06 -0500, Stephen Gallagher wrote:
>
> Please also attach sssd_KRB5.log. That is more likely to have the
> relevant information.
Not at all I'm afraid.
The last timestamp I have in that file is 1257770543 and the last
timestamp of the gnome-screensaver use that I sent p
On Mon, 2009-11-09 at 15:47 +0100, Sumit Bose wrote:
>
> yes, can you send the log files for the gnome-screensaver case ?
Sure. Nothing new in the krb5_child.log, however, sssd_pam.log:
(1257778320) [sssd[pam]] [accept_fd_handler] (4): Client connected!
(1257778320) [sssd[pam]] [sss_cmd_get_ve
On Mon, 2009-11-09 at 08:59 -0500, Simo Sorce wrote:
>
> If someone opens a bug for that, yes :-)
Done. https://fedorahosted.org/sssd/ticket/266
> However keep in mind that I don't care much for what pam_unix does in
> any pam target,
That's fair enough, but you have to respect what other pam
On Mon, 2009-11-09 at 15:13 +0100, Sumit Bose wrote:
>
> This error indicates a short write.
Ahhh. Now that is meaningful to me. :-)
> Can you check if a ccache file is
> create at all and if yes check the content with klist?
I didn't realize it was the ccache it was complaining about and I
On Mon, 2009-11-09 at 14:34 +0100, Sumit Bose wrote:
>
> Can you send krb5_child.log, too?
Nothing too exciting:
(1257770543) [[sssd[krb5_child[23777 [get_and_save_tgt] (1): 241:
[-1765328191][Credentials cache I/O operation failed XXX]
(1257770543) [[sssd[krb5_child[23777 [tgt_req_chi
On Mon, 2009-11-09 at 07:58 -0500, Stephen Gallagher wrote:
>
> If you create an account at https://admin.fedoraproject.org/accounts you
> will not be required to validate the captcha.
That's what site (including the https) I am at. Anyway, I seem to have
found one I could actually read.
> Bri
On Mon, 2009-11-09 at 08:05 -0500, Stephen Gallagher wrote:
>
> Sorry Brian, we discussed this off-list in #freeipa the other day.
> Transcript included here for posterity.
OK...
> ==
> 07:51:45 AM) sgallagh: sbose: Unrelated:
On Thu, 2009-11-05 at 16:27 -0500, Brian J. Murrell wrote:
>
I didn't see any response to the following. As far as I can see and
have explained this is still a problem. If you disagree, please present
your argument so that I can take it back to the pam_unix folks for their
considerati
On Mon, 2009-11-09 at 07:33 -0500, Stephen Gallagher wrote:
> Brian, can you open a bug at https://fedorahosted.org
I would but I can't make out the stupid captcha and there is no button
to generate a new one! I really hate captchas you know. They are
getting to the point where nobody can read
On Sat, 2009-11-07 at 20:02 -0500, Simo Sorce wrote:
>
> It should work, any chance you can check if this fails to work with
> master as well ?
Master fails in a completely different way:
Nov 8 18:19:41 laptop login[17852]: pam_sss(login:auth): user info:
[Credentials cache I/O operation fail
I've got SSSD 0.7.1 installed on a laptop here for my wife. She
authenticates with kerberos on that laptop via sssd.
So, when she first logs in, sssd manages to get her a tgt and everything
is good. However when gnome-screensaver locks her screen and she uses
her (kerberos of course) password to
[ Apologies if this winds up being a duplicate. I have tried to post
this a few times and not seen it distributed despite waiting
days. Probably getting lost somewhere. No worries. ]
On Tue, 2009-11-03 at 07:14 -0500, Stephen Gallagher wrote:
> - From passwd(5):
> "If the encrypted passwor
On Tue, 2009-11-03 at 14:30 -0500, Stephen Gallagher wrote:
>
> This is not a known issue. There should be no places in the SSSD where
> we require the SELinux libraries except in the tools. Could you please
> attach the build failures you see when building without the patch below?
Sure:
/bin/b
On Tue, 2009-11-03 at 14:30 -0500, Stephen Gallagher wrote:
>
> This is not a known issue. There should be no places in the SSSD where
> we require the SELinux libraries except in the tools. Could you please
> attach the build failures you see when building without the patch below?
Sure:
/bin/b
I found I needed the following patch to build on Ubuntu Karmic:
+--- sssd-0.7.1.orig/server/Makefile.am
sssd-0.7.1/server/Makefile.am
+@@ -233,13 +233,13 @@
+ $(NSS_LIBS) \
+ libsss_crypt.la
+
+-TOOLS_LIBS = \
+-$(SSSD_LIBS)
+-
+ if BUILD_SELINUX
+-TOOLS_LIBS += $(SELINUX_LIB
Is sssd IPv6 aware/ready? I notice that despite the fact that my
network is IPv6 capable and my DNS returns records, sssd seems to
prefer IPv4 connections to LDAP and kerberos, etc.
Is there a config and/or build option I'm just missing?
b.
signature.asc
Description: This is a digitally
I was going to file this as a bug in Trac but it's not clear how one
creates an account there.
Witness the difference between nss_ldap and sssd (0.7.1) with regard to
the password in passwd map entries:
nss_ldap $ getent passwd brian
brian:*:1001:1001:Brian J. Murrell:/home/brian:/bin/bash
25 matches
Mail list logo
