Hi,
are there any SSSD users who actively use a configuration with:
id_provider=local ?
If so, what is your use-case?
We're considering deprecating and eventually removing this provider
upstream. The replacemant for id_provider=local would be id_provider=files:
https://fedorahosted.org/sssd/wiki/DesignDocs/FilesProvider
which is already under review and later extension of the SSSD's D-Bus
interface to allow manipulating custom user attributes.
My current plan for deprecating the local provider is to only build the
provider and the tools around it if a configure-time flag is provided.
This flag would be disabled by default. Then, if noone complains,
eventually just remove the code.

Hey All,
We're receiving the following message on an older installation of SSSD
and RHEL 6.7. SSSD version is sssd-1.12.4-47.el6_7.4.x86_64.
I'm wondering under what conditions could "Expected one user entry and
got 2" be thrown and if it's fixed in higher SSSD versions.
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.

Hey All,
We are connecting a set of servers directly with AD. The AD computer
object is created for the host and is associated to a service account.
This service account works well with other hosts on the same domain.
Since this is a direct SSSD to AD setup, we are using adcli to establish
a connection to AD.
adcli populates a /etc/krb5.keytab file with a number of entries including:
* Added the entries to the keytab:
host/longhostname-host01.xyz.abc.com(a)COMPANY.COM: FILE:/etc/krb5.keytab
and runs successfully, without errors, to completion. However when
starting up sssd, we see the following in the log files:
.
.
[[sssd[ldap_child[11774]]]] [main] (0x0400): ldap_child started.
[[sssd[ldap_child[11774]]]] [main] (0x2000): context initialized
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): total buffer size: 71
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): realm_str size: 12
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): got realm_str:
COMPANY.COM
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): princ_str size: 35
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): got princ_str:
host/longhostname-host01.xyz.abc.co
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): keytab_name size: 0
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x1000): lifetime: 86400
[[sssd[ldap_child[11774]]]] [unpack_buffer] (0x0200): Will run as [0][0].
[[sssd[ldap_child[11774]]]] [privileged_krb5_setup] (0x2000): Kerberos
context initialized
[[sssd[ldap_child[11774]]]] [main] (0x2000): Kerberos context initialized
[[sssd[ldap_child[11774]]]] [become_user] (0x0200): Trying to become
user [0][0].
[[sssd[ldap_child[11774]]]] [become_user] (0x0200): Already user [0].
[[sssd[ldap_child[11774]]]] [main] (0x2000): Running as [0][0].
[[sssd[ldap_child[11774]]]] [main] (0x2000): getting TGT sync
got princ_str: host/longhostname-host01.xyz.abc.com(a)COMPANY.COM
.
.
Principal name is: [host/longhostname-host01.xyz.abc.com(a)COMPANY.COM]
.
.
followed by:
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
1492661662.219837: Looked up etypes in keytab: des-cbc-crc, des,
des-cbc-crc, rc4-hmac, aes128-cts, aes256-cts
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
1492661662.219898: Sending request (224 bytes) to COMPANY.COM
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
1492661662.220151: Initiating TCP connection to stream 1.2.3.4:88
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
1492661662.222555: Sending TCP request to stream 1.2.3.4:88
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
1492661662.226128: Received answer from stream 1.2.3.4:88
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
1492661662.226205: Response was from master KDC
[[sssd[ldap_child[11774]]]] [sss_child_krb5_trace_cb] (0x4000): [11774]
1492661662.226238: Received error from KDC: -1765328378/Client not found
in Kerberos database
Verified that the krb5.keytab has the principal and it matches exactly.
The OS is RHEL 6.7. Wondering if anyone ran into this and what could be
some of the problems that could be causing this? Do we need something
extra to be done on the AD side besides creating the computer object?
We'd take it from there to dig further since I realize I can't provide
all the details without first editing things out as I did above.
--
Cheers,
Tom K.
-------------------------------------------------------------------------------------
Living on earth is expensive, but it includes a free trip around the sun.

Hi,
Has anyone had any success while setting up SSSD with RODC AD Server? We
are setting this up on CentOS 6.8 machines but doesn't seem to work.
Computer object is created and replicated to RODC. Verified that all
configuration file parameters are identical to the ones mentioned in the
link below.
https://access.redhat.com/discussions/2838371
I assume we still have to join the server to RODC? Is the joining process
still the same as we do for a Writable DC.
When using "net ads join" I get the following error:
Failed to join domain: Failed to set account flags for machine account
(NT_STATUS_NOT_SUPPORTED)
in the logs, we also get the following( Debug level set to 7)
(Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [sdap_set_sasl_options]
(0x0100): Will look for testdmzlin(a)X.Y.LOCAL in default keytab
(Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]]
[select_principal_from_keytab] (0x0200): trying to select the most
appropriate principal from keytab
(Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab]
(0x0400): No principal matching testdmzlin(a)X.Y.LOCAL found in keytab.
(Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab]
(0x0400): No principal matching TESTDMZLIN$(a)X.Y.LOCAL found in keytab.
(Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab]
(0x0400): No principal matching host/testdmzlin(a)X.Y.LOCAL found in keytab.
(Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab]
(0x0400): No principal matching *$(a)X.Y.LOCAL found in keytab.
(Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab]
(0x0400): No principal matching host/*(a)X.Y.LOCAL found in keytab.
(Tue Feb 14 11:20:42 2017) [sssd[be[x.y.local]]] [find_principal_in_keytab]
(0x0400): No principal matching host/*@(null) found in keytab.
But if i try to query this RODC using "ldapsearch" it works.
ldapsearch -H ldap://RODC_ServerName.x.y.local/ -Y GSSAPI -N -b
"dc=x,dc=y,dc=local"
"(&(objectClass=user)(sAMAccountName=firstname.lastname))"
What else can I check to troubleshoot this issue?
Thanks,
~ Abhi

Hi.
I have the following scenario :
-'example.com' domain running on premises
-'aws.example.com' domain running on 'Amazon Microsoft AD' in VPC with VPN connection to on premises.
- One-way trust created from aws.example.com to example.com
I´m currently able to log in to a Windows server joined to aws.example.com using example.com credentials.
Now i want the same for our Linux servers running in Amazon VPC and have tried using this guide.: http://docs.aws.amazon.com/directoryservice/latest/admin-guide/join_linux...
I am able to login using credentials from aws.example.com like this .:
ssh user(a)aws.example.com (user is present in this domain)
But i am not able to do it using
ssh user(a)example.com (user is present in this domain)
I have searched a lot on this topic and saw freeipa mentioned a few times, but i would rather avoid having to use extra software if necessary.
Any help would be greatly appreciated. Please let me know if i need to provide any more details
Best regards
Kasper

Hey,
I have a question about email logins and case sensitivity. If you configure sssd to allow logins by email, can you set it up to be case insensitive yet still require normal account logins to be case sensitive? We want to allow users to authenticate with their email address or their account name but we can't set up "case_sensitive = false" due to some issues with some applications that treat "username" differently from "UserName" (for example). How have others managed this?
thanks
=G=

I'm trying to force SSSD to only communicate encrypted, because of company rules.
I think i'm missing something:
SSSD configured with: id_provider = ad
and DNS service resolution is enabled (default)
I have tried about every combination of:
ldap_id_use_start_tls = true
ldap_service_port = 636
ldap_tls_reqcert = allow
in sssd.conf [domain] section.
However, I can see SSSD LDAP connection over port 389.
# netstat -tanp | grep sssd_be
tcp 0 0 172.16.5.202:53520 172.16.1.241:389 ESTABLISHED 18080/sssd_be
Have I just missed something?
Do I need to pull the certificates from AD to make it work. I'm not really interested in verifying the certificates but only ensuring an encrypted channel.