Hello,
after upgrading sssd package from 1.13.0-40.el7_2.1 to 1.13.0-40.el7_2.9 and upgrading the cyrus-sasl Packages from 2.1.26-19.2.el7 to 2.1.26-20.el7_2
i got the following Message after restarting sssd:
sssd_be[30849]: ldapdb_canonuser_plug_init() failed in sasl_canonuser_add_plugin(): invalid parameter supplied
sssd_be[30849]: _sasl_plugin_load failed on sasl_canonuser_init for plugin: ldapdb
I don't change any configuration in sssd.conf or saslauthd.conf.
Setting the relevant debug_level = 9 in sssd.conf don't help, so perhaps can give me a hint?
greets
Steffen

CentOS 7 install fully updated (sssd-1.13.0-40.el7_2.9.x86_64).
Samba setup, SSSD setup, using AD with SFU attributes.
wbinfo isn't doing SID -> UID/GID mappings properly.
# wbinfo -n correctuser
failed to call wbcLookupName: WBC_ERR_UNKNOWN_FAILURE
Could not lookup name correctuser
# wbinfo -n MYDOMAIN\\correctuser
S-1-5-21-XXXXX SID_USER (1) # Correct
# wbinfo -s S-1-5-21-XXXXX
failed to call wbcLookupSid: WBC_ERR_UNKNOWN_FAILURE
Could not lookup sid S-1-5-21-XXXXX
# wbinfo --user-sidinfo=S-1-5-21-XXXXX
correctuser:*:12345:678:Correct User:/correct/home:/bin/bash
I get basically the same behaviour with groups.
Results in the display of SIDs in Windows rather than resolved names.
Swap out to use winbind instead:
alternatives --set libwbclient.so.0.12-64 /usr/lib64/samba/wbclient/libwbclient.so.0.12
All works perfectly well, with all of those cases working fine, and Windows
clients happy as Larry.
If I restart SSSD and run wbinfo -s, I see in the logs that it find the right
record, in as much as it does a sane query, finds a the correctuser record,
and stores the user, and it declares that it found the SID later:
[sdap_search_user_process] (0x0400): Search for users, returned 1 results.
...
[sdap_save_user] (0x0400): Storing info for user correctuser
...
[ad_master_domain_next_done] (0x0400): Found SID [S-1-5-21-XXXXX]
Nothing looks pained, but it doesn't work.
Any clues how to debug this?
jh

We are migrating to a new domain AD domain and I got cross domain trust problems(there is a bidirectional
cross trust between the two ADs, how can I test this works from Linux?). All users in domain A
has been copied to domain B(using the same UID/GID as in domain A).
I have managed to configure sssd for both domains(lets call the old domain A and the new B),
joined to both domains and I can login using any of the 2 domains.
But here is the problem:
If I use the new domain(B) as default login domain, I cannot ssh to another system still in domain A
password less(without entering my password again) or access files on NFS mounted files exported from domain A.
I know very little about cross trust etc. so I want to ask:
1) Is this even possible?
2) I have no idea where to start looking for what went wrong, need som pointers.
We are using sssd 1.13.4 on the new domain B machines while servers
in domain A uses an older sssd(1.12.5)
Jocke

Hi ,
After upgrade to sssd-13.4, dyndns updates don't work in AD cross realm environment
Our DNS server is :
-not on the identity server (exactly, not on the default DC for the domain)
-DNS server and reverse DNS server are different machines
It worked in previous release (also, DNS updates only)
Now, for fixing this I need to use the option 'dyndns_server' for explicitly point to the server.
It is not possible for dyndns_ptr updates, since sssd obviously assumes that there is one DNS for both A and PTR records.
Do you plan 'dyndns_ptr_server' option as well in future realeseS?
Best,
Longina

Hi List,
Or RH-7 box I am getting message like this:
[root@spartacus bin]# kinit
kinit: Disk quota exceeded while getting default ccache
Google gave this: https://bugzilla.redhat.com/show_bug.cgi?id=1017683
Which suggests big keys needs to be enabled for kernel and suggests kernel 3.11
However, RHEL-7 is based on 3.10 kernels - do we know whether big Kerberos keys are supported there?
Thanks,
Ondrej
-----
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s). Please direct any additional queries to: communications(a)s3group.com. Thank You. Silicon and Software Systems Limited (S3 Group). Registered in Ireland no. 378073. Registered Office: South County Business Park, Leopardstown, Dublin 18.

Trying to get make automatic keyring unlock work with pam_sss and it fails :)
I have in my pam conf:
auth required pam_env.so
auth sufficient pam_unix.so try_first_pass likeauth nullok
auth sufficient pam_sss.so forward_pass use_first_pass
auth optional pam_gnome_keyring.so
auth optional pam_group.so
auth required pam_deny.so
But this fails to unlock the keyring, but if I move pam_gnome_keyring.so before pam_sss.so
it works. It looks to as the forward_pass option fails to preserve the password.
Any pointers?
Jocke