Public bug reported:
Identified on Ubuntu 18.04
/etc/os-release:
NAME="Ubuntu"
VERSION="18.04.5 LTS (Bionic Beaver)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 18.04.5 LTS"
VERSION_ID="18.04"
HOME_URL="https://www.ubuntu.com/;
SUPPORT_URL="https://help.ubuntu.com/;
On 05/06/2016 10:16 AM, Wojciech Giel wrote:
> Public bug reported:
>
> Hello,
>
> User can't login to machine or ssh to it using domain account. User is
> immediately kicked off from login or disconnected from ssh.
>
> excerpt from auth.log
> May 6 14:59:06 openmanage sshd[3967]: Connection
Those are two separate bugs. The lock-screen one was SSSD legitimately
denying access because its configuration said it should (the PAM service
wasn't on the list, so it defaults to denial).
However, the error you're seeing with polkit is different:
May 5 11:55:20 uatlantico
Patch proposed upstream at:
https://lists.fedorahosted.org/archives/list/sssd-
de...@lists.fedorahosted.org/thread/F5IRGD4DONMTRCR3EAATVTHVMZMYVSRA/
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Looks to me like it's because the PAM service "unity" (which runs the
screensaver) isn't listed in the `ad_gpo_map_interactive` option in
sssd.conf. This list should have distro-specific defaults (since
different distributions use different PAM service names)
The fix should be to add unity to the
On 05/03/2016 06:27 AM, Robie Basak wrote:
> Thank you for helping with this Jakub. From Franz's response I presume
> this issue is now resolved? Setting this bug as Invalid accordingly. If
> this is incorrect please feel free to open with an explanation.
>
> ** Changed in: sssd (Ubuntu)
>
On Wed, 2015-01-28 at 19:19 +, Jakub Hrozek wrote:
Here is the most important part of the log:
(Wed Jan 28 15:41:48 2015) [sssd[be[default]]] [sdap_auth4chpass_done]
(0x0020): Changing shadow password attributes not implemented.
The functionality you request is simply not implemented.
On Jun 14, 2014, at 1:01 AM, Vladimir vo...@vovan.nl wrote:
In some cases, SSSD will write the keytab with root permissions and then
chown it to the user later.
Personally I've just tried to reproduce this behavior and it doesn't work. I
see following in the ssd log file:
(Sat Jun 14
While it's certainly not expected that the template should fail to be
accepted, I'd like to *strongly* caution you against the use of
FILE:%d/krb5cc_%U
This is a very well-known (and heavily-exploited) security
vulnerability. In some cases, SSSD will write the keytab with root
permissions and
By default, SSSD doesn't allow listing all users because that's very
slow and processor intensive. Try getent passwd username instead of
just getent passwd.
On May 26, 2014, at 9:25 AM, Thomas Schweikle 1322...@bugs.launchpad.net
wrote:
yes, that is working like charm! But getent doesn't
The LDAP access_provider option wasn't added in SSSD until 1.2.0.
The versions of SSSD still supported by upstream are:
1.5.x: Security fixes only, LTM
1.8.x: Fully supported, LTM
1.9.x Fully supported.
You're not going to see a major feature like this backported to 1.0.x
ever.
--
You
Thomas, 1.9.1 changed the default behavior so that we do not enable the
matching rule by default, but I suspect that the same issue is likely
present if it is re-enabled manually.
The SSSD is *supposed* to be properly detecting whether the server it's
talking to is capable of understanding that
-1 commonly appears as part of an ancient NFS bug that returns -1 as the
value of the UID if the user is being cast into 'nobody'. We've seen a
similar bug elsewhere in the code before.
That log message *is* related. It looks like in certain places we're
casting the value to signed before
Recommends: sssd:i386 but it is not going to be installed
That doesn't sound right to me. You don't want to have a 32-bit and
64-bit version of the daemon package running on the same system. It's
wasteful and potentially harmful. The 64-bit server talks to the clients
over sockets, so the clients
Just for the record, 'getent group username' and 'groups' should NOT be
identical.
Just plain groups will list the set of groups that were assigned to
you *at login time*, whereas 'getent group username' or 'groups
username' gives you the list of groups that would be assigned to you if
you logged
You are actually seeing intentional behavior here. What is happening is
that the initial login is occurring while SSSD is operating in offline
mode. Usually this happens when some application makes a request of SSSD
during startup before it has access to the remote LDAP server. As a
result, it
I understand your issue. Right now, your best bet is to operate with
'cache_credentials = False', which will at least deny access completely
until SSSD has re-established connection to the LDAP and KDC servers. As
I said above, we always operate in offline mode for a period of 1-2
minutes after
As an additional data point, libdbus is a strict dependency for both
certmonger and SSSD. The proper place to fix this bug is to add that
strict dependency to those two packages, rather than freeipa-client
(which should pick it up through dependency-resolution).
--
You received this bug
Note from upstream: Heimdal support is spotty at best. We have some
contributed patches that enable support for most features of Heimdal,
but they are untested by upstream.
We strongly recommend using MIT kerberos with SSSD at this time. If you
choose to switch to Heimdal, you will be required to
Sorry, my previous comment was unclear.
There is no formal support for Heimdal in the upstream SSSD. We have
accepted some submissions in the past that make it possible for the SSSD
services to operate with the Heimdal client libraries, but they are
known to function in a degraded mode (some
Changing the default of ldap_tls_reqcert to anything but 'demand' is a
security vulnerability. Period.
Setting it to allow means that certificates for which you do not have
complete trust (i.e. self-signed or malicious certificates) are blindly
allowed to be used for the encrypted communication.
This might be related to
https://bugs.launchpad.net/ubuntu/+source/openldap/+bug/929888
Could you check whether downgrading to openldap libraries 2.4.26 or
older fixes the issue?
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
Then let's have this bug closed as a dup of 929888.
Please open a new bug with the logs of the new issue.
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/932823
Title:
sssd sedfault in
Interestingly, rhel6 and Debian still have sssd 1.2. This is not true
about RHEL 6 (exactly). RHEL 6.0 shipped with SSSD 1.2, but RHEL 6.1 and
6.2 shipped with SSSD 1.5. Our expectation is for RHEL 6.3 to update to
SSSD 1.8.0 (the upcoming upstream LTM release). Each Fedora release sees
the latest
Interestingly, rhel6 and Debian still have sssd 1.2. This is not true
about RHEL 6 (exactly). RHEL 6.0 shipped with SSSD 1.2, but RHEL 6.1 and
6.2 shipped with SSSD 1.5. Our expectation is for RHEL 6.3 to update to
SSSD 1.8.0 (the upcoming upstream LTM release). Each Fedora release sees
the latest
Can you please be more explicit?
Please describe if you're getting this behavior from SSSD or from using
the 'kinit' command directly.
For now, let's investigate the problem using only kinit (that will
narrow down the problem to Kerberos and Active Directory, thus
eliminating SSSD for the time
'generic preauthentication failure' == KRB5KDC_ERR_PREAUTH_FAILED (Which
is therefore different from KRB5KDC_ERR_KEY_EXP. So yeah, the Active
Directory server is not sending the correct response from the KDC. We
can't do anything about that (since KRB5KDC_ERR_PREAUTH_FAILED is the
same error code
I'm going to make a guess, because you didn't include the packets
between KRB5KDC_ERR_KEY_EXP and KRB5KDC_ERR_PREAUTH_REQUIRED. I suspect
that what happened is that AD returned the correct error that the key
was expired, and the MIT libraries then went and tried to acquire a
password-change token
You need to use:
access_provider = ldap
ldap_access_order = expire
ldap_account_expire_policy = ad
From sssd-ldap(5):
ldap_account_expire_policy (string)
With this option a client side evaluation of access control
attributes can be enabled.
Please note that it
(in addition to any included in installed backends)
That list is just the internal special providers. The installed
backends are those for ldap and kerberos.
What do you see in /var/log/secure when doing that authentication that
fails?
Is it showing just pam_sss.so:auth or is it also getting to
create_homedir option is applicable only to users in an id_provider =
local domain (and then only when they are created with the sss_useradd
tool).
SSSD does not handle automatic creation of home directories for remote
users. For this, you should use pam_mkhomedir.so or
pam_oddjob_mkhomedir.so
Notes from upstream:
1) The libsemanage dependency can be dropped by passing --without-
semanage as an argument to configure. (Similarly, we also have a
--without-selinux option that removes the other SELinux features used by
the sss_[user|group]_* tools.) These features are available so that
Notes from upstream:
1) The libsemanage dependency can be dropped by passing --without-
semanage as an argument to configure. (Similarly, we also have a
--without-selinux option that removes the other SELinux features used by
the sss_[user|group]_* tools.) These features are available so that
The patch attached to this bug is irrelevant to this issue. However, it
is definitely correct, and I will be pushing it upstream later today.
Thanks, Krzysztof!
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
I've pushed your patch (as well as porting it forward to the master and
1.6.x branches).
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/893043
Title:
Update sssd to 1.5.15
To manage notifications
SSSD 1.5.9 saw a large series of changes to our LDAP code, mostly to be
able to better support Active Directory as an identity source. However,
we had to quickly turn out 1.5.10 and 1.5.11 as we discovered that the
new features were breaking some existing configurations.
The 1.5.12 release saw a
Richard, please open a new bug, as this crash is not related to the
issue described here.
Please include:
sssd.conf (sanitized as needed)
Your PAM stack (not sure what it is on Ubuntu. On Fedora it would be
/etc/pam.d/system-auth)
sssd_domainname.log (set debug_level = 9 in the
Sorry folks, this bug completely fell off my radar (mostly because no
one reported it upstream).
I should point out that SSSD 1.2.x is EOL in favor of SSSD 1.5.x LTM
(long-term maintenance).
It would be best to get your package maintainer to update to a supported
package. Otherwise, I can't
Etienne, it's actually not definite yet. SSSD 1.5.x is the first long-
term maintenance branch we've declared.
In general, as the SSSD upstream is largely sponsored by Red Hat and is
a main component of Red Hat Enterprise Linux, it would be reasonable to
assume that it will be maintained until
RHEL 6.0 shipped with 1.2.1, but it was decided that it was
insufficient. RHEL 6.1 (currently in beta) carries SSSD 1.5.1 (plus a
variety of patches that makes it effectively identical to 1.5.5)
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to
Public bug reported:
Binary package hint: sssd
The System Security Services Daemon upstream declares certain releases
to be Long-Term Maintenance releases that will continue to receive
bugfixes, security fixes and minor enhancements for longer periods (at
least a full year).
Ubuntu is still
That's an unrelated issue. You wouldn't see this with 'enumerate =
false', for one thing.
What it's telling you is that 300s isn't long enough to fully process
all users, groups and group memberships. Chances are that you have a
very large or complicated group setup.
Try setting
The commits:
23e8d84320ae8b76d244764c02e44036e96cd4df
21f28bdbab10881b9fb0b890dfa15af429326606
29dfae2a89551026f861f1f857187c22e30730c9
bd880fde928e0cb0eee5d59e2fd5f26d75698b5c
Are the necessary upstream changes to fix this issue. They don't apply
cleanly on the 1.2.x branch since the primary
I think the appropriate behavior here would be to make libnss-
sss.so(32-bit) a recommended package for SSSD. The reason you might
not want to install the 32-bit libnss-sss.so by default is that it would
immediately require the 32-bit glibc as a dependency. For platforms that
want to remain 100%
This needs to be fixed, as without this directory, Kerberos
functionality will not work at all.
It should be a trivially easy fix.
--
missing /var/lib/sss/pubconf/
https://bugs.launchpad.net/bugs/557394
You received this bug notification because you are a member of Ubuntu
Bugs, which is
I strongly recommend upgrading to SSSD 1.0.1, rather than 0.7.1. It is
more feature-complete and stable.
--
needs update to 0.7.1
https://bugs.launchpad.net/bugs/473262
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
--
ubuntu-bugs
Public bug reported:
I manually created my partitions before installing Mythbuntu in the following
pattern:
/dev/sda1 100MiB ext3 /boot
/dev/sda2 2048MiB swap swap
/dev/sda3 extended
/dev/sda5 10GiB ext4 /
/dev/sda6 140GiB lvm2
/dev/sdd1 730GiB lvm2
Created a volume group data_archive from
47 matches
Mail list logo
