Stupid question on ldap_user_email
by John Hearns
I have a test system which authenticates using sssd and an LDAP provider.
So far so good!
In my LDAP object there is the field 'mail' which is my correct email
address.
I know I can get this using an ldapsearch.
However I am asking if there is any clean and small utility which will
print this out?
I am asking as obviously scripts sometimes want to send email.
In sssd.conf there s the field ldap_user_email
How would this be queried?
4 years, 10 months
group memberships not updating
by Toby Blake
Hi,
We have noticed an issue where group memberships are not being updated
on a significant number of our machines.
It appears that this has been reported in the following two bug reports:
https://pagure.io/SSSD/sssd/issue/3869
https://pagure.io/SSSD/sssd/issue/3886
There hasn't been any activity on these for a few months now, so I thought
I would add a me-too, and offer to do any debugging necessary.
Thanks
Toby Blake
School of Informatics
University of Edinburgh
--
The University of Edinburgh is a charitable body, registered in
Scotland, with registration number SC005336.
4 years, 10 months
authenticate linux using active directory without joined
by Antonio Pena Diaz
Hi,
I need to connect by ssh using users centralized on AD, but linux servers client use nslcd to retrieve the users settings and mapping attributes..
I don't want to join linux servers into domain, and not use kerberos... exist the possibility to do this with my settings nslcd ?
or how can I do same using sssd.conf to do it?
using nscld, the only issue I have is, connecting by ssh .... reach authenticated but can't retrieve the shell and is mapped when get the entries from active directory using ldap protocol.
I'm not registered into list so please answer directly to my email.
any idea?
Thanks in advance.
https://pastebin.com/1XmqF6LJ
[https://pastebin.com/i/facebook.png]<https://pastebin.com/1XmqF6LJ>
[root@centos-manager ~]# cat /etc/nslcd.conf uid nslcd gid ldap uri ldap:// - Pastebin.com
Altre info...<https://pastebin.com/1XmqF6LJ>
[APK]
Antonio Pena Diaz
Sistemisti e Sistemi Informativi Interni
Area Tecnica
APKAPPA s.r.l. sede legale Via F. Albani, 21 20149 Milano | p.iva/vat no. IT-08543640158
sede amministrativa e operativa Reggio Emilia (RE) via M. K. Gandhi, 24/ A 42123 - sede operativa Magenta (MI) via Milano 89/91 20013
tel. 02 94454 000 | fax 02 94454 339 www.apkappa.it<http://www.apkappa.it>
Seguici su:
[Facebook]<https://www.facebook.com/apkappasrl> [LinkedIn] <https://www.linkedin.com/company/apkappa>
Ai sensi e per gli effetti della Legge sulla tutela della riservatezza personale (D.Lgs. 196/03 e collegate), questa mail è destinata unicamente alle persone sopra indicate e le informazioni in essa contenute sono da considerarsi strettamente riservate.
This email is confidential, do not use the contents for any purpose whatsoever nor disclose them to anyone else. If you are not the intended recipient, you should not copy, modify, distribute or take any action in reliance on it. If you have received this email in error, please notify the sender and delete this email from your system.
4 years, 10 months
pam_sssd: reset Samba4/AD password
by Julien TEHERY
Hi there
We have a samba4 AD (installed on ubuntu servers) and also ubuntu client
workstations.
Those ubuntu workstations authenticate themselves to samba4/AD server
through pam_sssd.
Users authentication against Samba4/AD works well, but i don't know how
to allow users to change their own passwords through thios mecanism.
I tried several methods like smbpasswd, samba-tool user setpassword,
passwd or kpasswd but none of them works.
Do some of you know how to proceed to make it work with samba4/AD
authentication?
The goal is simply to allow a workstation user to change his password
whithout using a web interface.
Here is the sssd setup of the workstations:
/etc/sssd/sssd.conf:
[sssd]
config_file_version = 2
domains = mydomain.lan
services = nss, pam
default_domain_suffix = mydomain.lan
[domain/mydomain.lan]
id_provider = ad
auth_provider = ad
chpass_provider=ad
access_provider = ad
ldap_id_mapping = True
default_shell = /bin/bash
use_fully_qualified_names = False
override_homedir = /users/home/%u
fallback_homedir = /users/home/%u
krb5_use_enterprise_principal=false
krb5_validate = False
krb5_store_password_if_offline = False
ad_domain = mydomain.lan
krb5_realm = MYDOMAIN.LAN
realmd_tags = manages-system joined-with-samba
Thanks
4 years, 10 months
RHEL8 sssd-kcm can't accept credentials forwarded from sshd?
by James Ralston
Now that RHEL8 is out, our site is again looking at whether it would
be feasible to change our default Kerberos credentials storage from
the kernel persistent keyring to sssd-kcm.
Unfortunately, the answer still seems to be no, as we haven't been
able to find a way to get Kerberos ticket forwarding
(GSSAPIDelegateCredentials, in OpenSSH parlance) working when using
sssd-kcm as the credentials storage mechanism on the target host (the
one the credentials are being delegated to).
With the target host (the one the credentials are being delegated to)
using "default_ccache_name = KEYRING:persistent:%{uid}" in krb5.conf,
this is what sshd debugging shows:
debug1: temporarily_use_uid: 123456789/987654321 (e=0/0)
debug3: ssh_krb5_cc_new_unique: called
debug3: ssh_krb5_get_cctemplate: called
debug3: ssh_krb5_expand_template: called, template = KEYRING:persistent:%{uid}
debug3: ssh_krb5_get_cctemplate: returning with ccname =
KEYRING:persistent:123456789
debug3: ssh_krb5_cc_new_unique: setting default ccname to
KEYRING:persistent:123456789
debug3: ssh_krb5_cc_new_unique: calling
cc_new_unique(KEYRING:persistent:123456789)
debug3: ssh_krb5_cc_new_unique: calling cc_switch()
debug1: restore_uid: 0/0
In contrast, with "default_ccache_name = KCM:" in /etc/krb5.conf:
debug1: temporarily_use_uid: 123456789/987654321 (e=0/0)
debug3: ssh_krb5_cc_new_unique: called
debug3: ssh_krb5_get_cctemplate: called
debug3: ssh_krb5_expand_template: called, template = KCM:
debug3: ssh_krb5_get_cctemplate: returning with ccname = KCM:
debug3: ssh_krb5_cc_new_unique: setting default ccname to KCM:
debug3: ssh_krb5_cc_new_unique: calling cc_new_unique(KCM:)
debug3: ssh_krb5_cc_new_unique: calling cc_switch()
ssh_krb5_cc_new_unique(): Matching credential not found
debug1: restore_uid: 0/0
So, when sssd-kcm is in use, ssh_krb5_expand_template() fails, instead
of returning what would be expect in this case, which (based on the
kernel persistent keyring case) would be "KCM:123456789".
sssd_kcm.log contains:
(Fri May 10 12:33:34 2019) [sssd[kcm]] [get_client_cred] (0x4000):
Client creds: euid[123456789] egid[987654321] pid[8661].
(Fri May 10 12:33:34 2019) [sssd[kcm]] [setup_client_idle_timer]
(0x4000): Idle timer re-set for client [0x560fd598dc10][14]
(Fri May 10 12:33:34 2019) [sssd[kcm]] [accept_fd_handler] (0x0400):
Client connected!
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_input_parse] (0x1000):
Received message with length 4
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_get_opt] (0x2000): The
client requested operation 3
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_send] (0x0400): KCM
operation GEN_NEW
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_send] (0x1000): 0
bytes on KCM input
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_send] (0x0200):
Adding request by 123456789 to the wait queue
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_get] (0x1000): No
existing queue for this ID
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_send] (0x1000):
Queue was empty, running the request immediately
(Fri May 10 12:33:34 2019) [sssd[kcm]] [ccdb_secdb_nextid_send]
(0x1000): Generating a new ID
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_map_path] (0x1000):
Mapping prefix /kcm/
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_map_url_to_path] (0x1000):
User-specific KCM path is [/kcm/persistent/123456789/ccache/]
(Fri May 10 12:33:34 2019) [sssd[kcm]] [local_db_dn] (0x2000): Local
path for [persistent/123456789/ccache/] is
[cn=ccache,cn=123456789,cn=persistent,cn=kcm]
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_new_req] (0x1000):
Local DB path is persistent/123456789/ccache/
(Fri May 10 12:33:34 2019) [sssd[kcm]] [secdb_container_url_req]
(0x2000): Created request for URL /kcm/persistent/123456789/ccache/
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x0400):
Listing keys at [persistent/123456789/ccache/]
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x2000):
Searching for [(type=simple)] at
[cn=ccache,cn=123456789,cn=persistent,cn=kcm] with scope=subtree
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x1000): No secrets found
(Fri May 10 12:33:34 2019) [sssd[kcm]] [ccdb_secdb_nextid_send]
(0x1000): Generated next ID 39355
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_ccdb_nextid_done]
(0x1000): generated 123456789:39355
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_gen_new_done] (0x1000):
Generated a new ID 123456789:39355
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_done] (0x0400): KCM
operation GEN_NEW returned [0]: Success
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_send_reply] (0x2000):
Sending a reply
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_output_construct]
(0x1000): Sending a reply with 20 bytes of payload
(Fri May 10 12:33:34 2019) [sssd[kcm]] [queue_removal_cb] (0x0200):
Removed queue for 123456789
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_send] (0x2000): All data sent!
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_input_parse] (0x1000):
Received message with length 20
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_get_opt] (0x2000): The
client requested operation 21
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_send] (0x0400): KCM
operation SET_DEFAULT_CACHE
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_send] (0x1000): 16
bytes on KCM input
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_send] (0x0200):
Adding request by 123456789 to the wait queue
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_get] (0x1000): No
existing queue for this ID
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_op_queue_send] (0x1000):
Queue was empty, running the request immediately
(Fri May 10 12:33:34 2019) [sssd[kcm]]
[kcm_op_set_default_ccache_send] (0x1000): Setting default ccache
123456789:39355
(Fri May 10 12:33:34 2019) [sssd[kcm]] [ccdb_secdb_uuid_by_name_send]
(0x2000): Translating name to UUID
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_map_path] (0x1000):
Mapping prefix /kcm/
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_map_url_to_path] (0x1000):
User-specific KCM path is [/kcm/persistent/123456789/ccache/]
(Fri May 10 12:33:34 2019) [sssd[kcm]] [local_db_dn] (0x2000): Local
path for [persistent/123456789/ccache/] is
[cn=ccache,cn=123456789,cn=persistent,cn=kcm]
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_new_req] (0x1000):
Local DB path is persistent/123456789/ccache/
(Fri May 10 12:33:34 2019) [sssd[kcm]] [secdb_container_url_req]
(0x2000): Created request for URL /kcm/persistent/123456789/ccache/
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x0400):
Listing keys at [persistent/123456789/ccache/]
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x2000):
Searching for [(type=simple)] at
[cn=ccache,cn=123456789,cn=persistent,cn=kcm] with scope=subtree
(Fri May 10 12:33:34 2019) [sssd[kcm]] [sss_sec_list] (0x1000): No secrets found
(Fri May 10 12:33:34 2019) [sssd[kcm]] [key_by_name] (0x0080): The
container was not found
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_ccdb_uuid_by_name_done]
(0x0040): Failed to resolve cache by UUID [1432158218]: No credentials
available
(Fri May 10 12:33:34 2019) [sssd[kcm]]
[kcm_op_set_default_ccache_getbyname_done] (0x0040): Cannot get ccache
by name [1432158218]: No credentials available
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_done] (0x0040): op
receive function failed [1432158218]: No credentials available
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_cmd_request_done]
(0x0040): KCM operation failed [1432158218]: No credentials available
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_reply_error] (0x0040): KCM
operation returs failure [1432158218]: No credentials available
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_failbuf_construct]
(0x1000): Sent reply with error -1765328243
(Fri May 10 12:33:34 2019) [sssd[kcm]] [queue_removal_cb] (0x0200):
Removed queue for 123456789
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_send] (0x2000): All data sent!
(Fri May 10 12:33:34 2019) [sssd[kcm]] [kcm_recv] (0x4000): Client
closed connection.
(Fri May 10 12:33:34 2019) [sssd[kcm]] [client_close_fn] (0x2000):
Terminated client [0x560fd598dc10][14]
So, sssd-kcm definitely failed. This aligns with what sshd saw.
If I pre-create the cache on the target server (e.g., by running kinit
against a different principal) and repeat the experiment, sssd-kcm
still fails, but the debug output is slightly different:
(Fri May 10 12:56:27 2019) [sssd[kcm]] [get_client_cred] (0x4000):
Client creds: euid[123456789] egid[987654321] pid[8844].
(Fri May 10 12:56:27 2019) [sssd[kcm]] [setup_client_idle_timer]
(0x4000): Idle timer re-set for client [0x5589715428e0][14]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [accept_fd_handler] (0x0400):
Client connected!
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_input_parse] (0x1000):
Received message with length 4
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_get_opt] (0x2000): The
client requested operation 3
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_send] (0x0400): KCM
operation GEN_NEW
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_send] (0x1000): 0
bytes on KCM input
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_send] (0x0200):
Adding request by 123456789 to the wait queue
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_get] (0x1000): No
existing queue for this ID
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_send] (0x1000):
Queue was empty, running the request immediately
(Fri May 10 12:56:27 2019) [sssd[kcm]] [ccdb_secdb_nextid_send]
(0x1000): Generating a new ID
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_map_path] (0x1000):
Mapping prefix /kcm/
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_map_url_to_path] (0x1000):
User-specific KCM path is [/kcm/persistent/123456789/ccache/]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [local_db_dn] (0x2000): Local
path for [persistent/123456789/ccache/] is
[cn=ccache,cn=123456789,cn=persistent,cn=kcm]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_new_req] (0x1000):
Local DB path is persistent/123456789/ccache/
(Fri May 10 12:56:27 2019) [sssd[kcm]] [secdb_container_url_req]
(0x2000): Created request for URL /kcm/persistent/123456789/ccache/
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x0400):
Listing keys at [persistent/123456789/ccache/]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x2000):
Searching for [(type=simple)] at
[cn=ccache,cn=123456789,cn=persistent,cn=kcm] with scope=subtree
(Fri May 10 12:56:27 2019) [sssd[kcm]] [local_dn_to_path] (0x2000):
Secrets path for
[cn=2c095c7e-978f-498c-aa46-f1641ac45545-123456789,cn=ccache,cn=123456789,cn=persistent,cn=kcm]
is [2c095c7e-978f-498c-aa46-f1641ac45545-123456789]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x1000):
Returning 1 secrets
(Fri May 10 12:56:27 2019) [sssd[kcm]] [ccdb_secdb_nextid_send]
(0x1000): Generated next ID 39355
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_ccdb_nextid_done]
(0x1000): generated 123456789:39355
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_gen_new_done] (0x1000):
Generated a new ID 123456789:39355
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_done] (0x0400): KCM
operation GEN_NEW returned [0]: Success
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_send_reply] (0x2000):
Sending a reply
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_output_construct]
(0x1000): Sending a reply with 20 bytes of payload
(Fri May 10 12:56:27 2019) [sssd[kcm]] [queue_removal_cb] (0x0200):
Removed queue for 123456789
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_send] (0x2000): All data sent!
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_input_parse] (0x1000):
Received message with length 20
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_get_opt] (0x2000): The
client requested operation 21
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_send] (0x0400): KCM
operation SET_DEFAULT_CACHE
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_send] (0x1000): 16
bytes on KCM input
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_send] (0x0200):
Adding request by 123456789 to the wait queue
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_get] (0x1000): No
existing queue for this ID
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_op_queue_send] (0x1000):
Queue was empty, running the request immediately
(Fri May 10 12:56:27 2019) [sssd[kcm]]
[kcm_op_set_default_ccache_send] (0x1000): Setting default ccache
123456789:39355
(Fri May 10 12:56:27 2019) [sssd[kcm]] [ccdb_secdb_uuid_by_name_send]
(0x2000): Translating name to UUID
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_map_path] (0x1000):
Mapping prefix /kcm/
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_map_url_to_path] (0x1000):
User-specific KCM path is [/kcm/persistent/123456789/ccache/]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [local_db_dn] (0x2000): Local
path for [persistent/123456789/ccache/] is
[cn=ccache,cn=123456789,cn=persistent,cn=kcm]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_new_req] (0x1000):
Local DB path is persistent/123456789/ccache/
(Fri May 10 12:56:27 2019) [sssd[kcm]] [secdb_container_url_req]
(0x2000): Created request for URL /kcm/persistent/123456789/ccache/
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x0400):
Listing keys at [persistent/123456789/ccache/]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x2000):
Searching for [(type=simple)] at
[cn=ccache,cn=123456789,cn=persistent,cn=kcm] with scope=subtree
(Fri May 10 12:56:27 2019) [sssd[kcm]] [local_dn_to_path] (0x2000):
Secrets path for
[cn=2c095c7e-978f-498c-aa46-f1641ac45545-123456789,cn=ccache,cn=123456789,cn=persistent,cn=kcm]
is [2c095c7e-978f-498c-aa46-f1641ac45545-123456789]
(Fri May 10 12:56:27 2019) [sssd[kcm]] [sss_sec_list] (0x1000):
Returning 1 secrets
(Fri May 10 12:56:27 2019) [sssd[kcm]] [key_by_name] (0x2000): No key matched
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_ccdb_uuid_by_name_done]
(0x0040): Failed to resolve cache by UUID [1432158218]: No credentials
available
(Fri May 10 12:56:27 2019) [sssd[kcm]]
[kcm_op_set_default_ccache_getbyname_done] (0x0040): Cannot get ccache
by name [1432158218]: No credentials available
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_done] (0x0040): op
receive function failed [1432158218]: No credentials available
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_cmd_request_done]
(0x0040): KCM operation failed [1432158218]: No credentials available
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_reply_error] (0x0040): KCM
operation returs failure [1432158218]: No credentials available
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_failbuf_construct]
(0x1000): Sent reply with error -1765328243
(Fri May 10 12:56:27 2019) [sssd[kcm]] [queue_removal_cb] (0x0200):
Removed queue for 123456789
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_send] (0x2000): All data sent!
(Fri May 10 12:56:27 2019) [sssd[kcm]] [kcm_recv] (0x4000): Client
closed connection.
(Fri May 10 12:56:27 2019) [sssd[kcm]] [client_close_fn] (0x2000):
Terminated client [0x5589715428e0][14]
Before I dig into this further, or go file a support request with Red
Hat, has anyone been able to get sssd-kcm to successfully accept
forwarded credentials from sshd on RHEL8? If so, what did you have to
set or tweak to get it to work?
4 years, 10 months
SSSD with SSH key auth + MFA with Radius server
by Nerigal
Hi,
I could make sssd work fine with domain authentication with Radius
server + Azure MFA through SSH gateway using password
So the user enter his creds and then get to prompt on his phone to
accept or reject the authentication
Everything work as expected so far
The problem comes with SSH keys ...
i tried the alternate authentication in Active Directory adding users
SSH keys in altSecurityIdentities user object attribute
and configuring
ldap_user_extra_attrs = altSecurityIdentities:altSecurityIdentities
ldap_user_ssh_public_key = altSecurityIdentities
ldap_use_tokengroups = True
in sssd.conf file
and its actually working too well...
The "too well" is that it looks like as soon as the user has a working
ssh Key in Active Directory, SSSD ingore the configuration
auth_provider = proxy
proxy_pam_target = sssdproxyradiusauth
Note *
sshd_config is configured with
AuthorizedKeysCommand /usr/bin/sss_ssh_authorizedkeys
AuthorizedKeysCommandUser root
So is there a way to make SSSD always pass by the Radius regardless of
the auth mechanic ?
May be the "proxy bypass" with SSH key come from
/usr/bin/sss_ssh_authorizedkeys i can't tell at this point
4 years, 10 months
sssd[be[1320]: Backend is offline
by Harald Dunkel
Hi folks,
sssd 1.16.3-1 (rebuilt for Debian 9), systemd
At boot time sssd_nss fails to initialize. systemctl status sssd
shows
root@srvl061:~# systemctl status sssd
* sssd.service - System Security Services Daemon
Loaded: loaded (/lib/systemd/system/sssd.service; enabled; vendor preset: enabled)
Active: active (running) since Thu 2018-11-22 11:57:30 CET; 46s ago
Main PID: 1312 (sssd)
Tasks: 5 (limit: 7372)
CGroup: /system.slice/sssd.service
|-1312 /usr/sbin/sssd -i --logger=files
|-1345 /usr/lib/x86_64-linux-gnu/sssd/sssd_be --domain example.com --uid 0 --gid 0 --logger=files
|-1533 /usr/lib/x86_64-linux-gnu/sssd/sssd_nss --uid 0 --gid 0 --logger=files
|-1534 /usr/lib/x86_64-linux-gnu/sssd/sssd_pam --uid 0 --gid 0 --logger=files
`-1535 /usr/lib/x86_64-linux-gnu/sssd/sssd_pac --uid 0 --gid 0 --logger=files
Nov 22 11:57:25 srvl061.ac.example.com systemd[1]: Starting System Security Services Daemon...
Nov 22 11:57:25 srvl061.ac.example.com sssd[1312]: Starting up
Nov 22 11:57:25 srvl061.ac.example.com sssd[be[1345]: Starting up
Nov 22 11:57:30 srvl061.ac.example.com sssd[1533]: Starting up
Nov 22 11:57:30 srvl061.ac.example.com sssd[1534]: Starting up
Nov 22 11:57:30 srvl061.ac.example.com sssd[1535]: Starting up
Nov 22 11:57:30 srvl061.ac.example.com systemd[1]: Started System Security Services Daemon.
Nov 22 11:57:45 srvl061.ac.example.com sssd[be[1345]: Backend is offline
Apparently this is a problem of resolvconf generating /etc/\
resolv.conf at boot time. If I replace it by a static file, then
the problem is gone.
Question is, how can I tell systemd to wait for resolv.conf?
Is there some timeout in the backend I could adjust? Does it
wait for the network at all?
Every helpful comment is highly appreciated
Regards
Harri
4 years, 10 months
Is it possible to use the full username+domain name when using proxy_pam_target ?
by David Fournier
I've been tasked with adding two-factor authentication to one of our servers that will be exposed to the net. Requirements include using an existing 2FA system which uses RADIUS for authentication, and that users from both the client domain (unicorn.local) and the management domain (rainbow.local) can log in. The RADIUS server is the same for both domains.
I believed I could use sssd with auth_provider = proxy and then specify my RADIUS pam module in the proxy_pam_target, however after running tests it appears that sssd only provides the username part of the fully qualified username to proxy_pam_target (i.e. if the user is 'stranger(a)rainbow.local', only 'stranger' is passed to the modules specified in proxy_pam_target).
Is there a way/switch/configuration option that I would have missed that would allow passing the full username to my pam target?
Content of /etc/sssd/sssd.conf -------------------------------
[sssd]
domains = unicorn.local,rainbow.local
config_file_version = 2
services = nss, pam
full_name_format = %1$s@%2$s
[domain/unicorn.local]
id_provider = ldap
ldap_id_mapping = True
ldap_schema = AD
ldap_group_nesting_level = 8
ldap_uri = ldap://pradad1001.unicorn.local
ldap_search_base = dc=unicorn,dc=local
ldap_default_bind_dn = CN=linuxldap,CN=Users,DC=unicorn,DC=local
ldap_default_authtok_type = password
ldap_default_authtok = *************
default_shell = /bin/bash
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = L_Unicorn_SSH_Admins
auth_provider = proxy
proxy_pam_target = sssdauthproxy
[domain/rainbow.local]
id_provider = ldap
ldap_id_mapping = True
ldap_schema = AD
ldap_group_nesting_level = 8
ldap_uri = ldap://otherad2001.rainbow.local
ldap_search_base = dc=rainbow,dc=local
ldap_default_bind_dn = CN=linuxldap,CN=Users,DC=rainbow,DC=local
ldap_default_authtok_type = password
ldap_default_authtok = **************
default_shell = /bin/bash
use_fully_qualified_names = True
fallback_homedir = /home/%u@%d
access_provider = simple
simple_allow_groups = L_Rainbow_SSH_Admins
auth_provider = proxy
proxy_pam_target = sssdauthproxy
End Content of /etc/sssd/sssd.conf -------------------------------
Content of sssdauthproxy -------------------------------------
auth required pam_warn.so
auth required pam_radius_auth.so
End Content of sssdauthproxy -------------------------------------
Note that I added pam_warn.so right before pam_sss.so, the output shows the difference in users:
Apr 24 17:16:58 SAclt001 sshd[15553]: pam_warn(sshd:auth): function=[pam_sm_authenticate] service=[sshd] terminal=[ssh] user=[stranger(a)rainbow.local] ruser=[<unknown>] rhost=[bbb.bbb.bbb.bb]
Apr 24 17:16:58 SAclt001 proxy_child: pam_warn(sssdauthproxy:auth): function=[pam_sm_authenticate] service=[sssdauthproxy] terminal=[ssh] user=[stranger] ruser=[] rhost=[bbb.bbb.bbb.bb]
Thanks for reading that far!
4 years, 10 months
Local group and AD user mapping
by soham chakraborty
Hi,
I have a requirement where human users will be logging in with their AD accounts. However, there are some applications that create local user and group and at times, the AD users may need to work on the application, view/edit files owned by the application user/group, run programs etc. Therefore we need to create some sort of mapping between the AD users and the local group.
After coming through this mailing list, I realized that the recommendation is to add the remote AD users into the local group by way of modifying /etc/group file. What I am wondering is that, is this the only way to solve the problem or is there any other way (presumably better way) to handle this?
I am using Puppet already. Therefore I think I may use the augeas provider to edit /etc/group file to add the users. I also need to devise a way so that users can be deleted from /etc/group easily in an automated fashion. Has anyone got any tips under their sleeve that can be used to roll out this feature in a lot of servers?
Thanks,
4 years, 10 months