[PATCH] Add experimental support to receive PAC via GSSAPI
by Sumit Bose
Hi,
this series of patches adds support to receive a windows PAC via GSSAPI
and to create a user based on the data in the PAC. This is useful
because in an environment with lots of trust relationships between AD
server it might be quite time consuming to find out about all the group
memberships of a domain user by querying the domain controllers. But the
PAC contains all information about group memberships of the
corresponding user.
The general idea is to add the user, if it doesn't exist in the cache,
to the cache of the corresponding domain (see thread about sub-domains,
currently this patch add the user to the local domain for simplicity)
and to add all group memberships (currently not implemented). If one of
the groups cannot be found in the cache a dummy entry with all data
needed to resolve this group quickly is added to the cache.
Currently there are a couple of loose end, e.g.
- groups and group memberships are not handled
- PAC is not validated
- missing sub-domains
- no real SID to uid/gid mapping
etc, but I like to start the discussion about the code and the general
direction as soon as possible. Currently sssd with these patches can
only be build on rawhide, because of the dependencies to the samba4
package (libndr-krb5pac).
Patch 0007 contains a little example that demonstrates that the pac
responder can also be used to add user and groups based on other input,
e.g. it can be used as a backend for the sss_* utilities. This would
allow a much better control about which user is allowed to do what kind
of operation. Currently only the root user can add and modify user and
group entries with the sss_* tools.
I have used 'pac' as a part of names here because this was the original
target, but I would be happy to change it to a more generic keyword if
anyone has a good suggestion.
bye,
Sumit
12 years, 10 months
Announcing the release of SSSD 1.5.9
by Stephen Gallagher
The SSSD team is proud to announce the latest bugfix and enhancement
release to the long-term maintenance 1.5.x branch of the System Security
Services Daemon.
As always, it can be downloaded from
https://fedorahosted.org/sssd
== Highlights ==
=== New Features ===
* Support for overriding home directory, shell and primary GID locally
* Properly honor TTL values from SRV record lookups
* Support non-POSIX groups in nested group chains (for RFC2307bis LDAP
servers)
=== Important Bugfixes ===
* Properly escape IPv6 addresses in the failover code
* Do not crash if inotify fails (e.g. resource exhaustion)
* Don't add multiple TGT renewal callbacks (too many log messages)
== Detailed Changelog ==
Jakub Hrozek (15):
* Add utility function to return IP address as string
* Add a utility function to escape IPv6 address for use in URIs
* Use escaped IP addresses in LDAP provider
* Escape IPv6 IP addresses in the IPA provider
* Add a new option to override primary GID number
* Add a new option to override home directory value
* Add new options to override shell value
* Add new resolv_hostent data structure and utility functions
* Resolve hosts by name from files into resolv_hostent
* Resolve hosts by name from DNS into resolv_hostent
* Switch resolver to using resolv_hostent and honor TTL
* Provide TTL structure names for c-ares < 1.7
* Test NULL server hostname in fail over tests
* Log nsupdate message
* Don't pass NULL to printf for TLS errors
Jan Zeleny (4):
* Added sysdb_attrs_get_bool() function
* Non-posix group processing - sysdb changes
* Non-posix group processing - ldap provider and nss responder
* Fall back to polling when inotify fails
Kaushik Banerjee (1):
* Changing default to Default for consistency
Stephen Gallagher (6):
* Update version to 1.5.9
* Fix typo in initgroups negative cache check
* Ensure that SSSD always Requires: the primary-arch sssd-client
* Fix bad merge
* Clear up -Wunused-but-set-variable warnings
* Updating translation files for SSSD 1.5.9
Sumit Bose (7):
* Add online callback only once for TGT renewal
* Delete cached ccache file if password is expired
* Do not check pwdAttribute
* Add sockaddr_storage to sdap_service
* Add sdap_call_conn_cb() to call add connection callback directly
* Use name based URI instead of IP address based URIs
* Use ldap_init_fd() instead of ldap_initialize() if available
12 years, 10 months
[PATCHES] Use ldap_init_fd() instead of ldap_initialize() if available
by Sumit Bose
Hi,
currently we have two competing features in the LDAP provider. One the
one hand we want to avoid further DNS lookups by the OpenLDAP client
libraries and want to talk to the same LDAP server as long as possible.
To achieve this we create LDAP URIs with the IP instead of the server
name and pass them to ldap_initialize(). But this in general leads to
failures when TLS/SSL certificates are validated, because here the node
part of the URI is extracted and compared to the common name and the
subject alternative names in the certificate. If the IP address of the
server is not among them, which in general is the case, the validation
fails.
To solve this this series of patches substitutes ldap_initialize() by a
sequence of socket(), connect() and ldap_init_fd(). Now we can use the
IP address during connect() and the URI iwth the server name in
ldap_init_fd().
The corresponding trac ticket is
https://fedorahosted.org/sssd/ticket/905 .
bye,
Sumit
12 years, 10 months
Discussion of debug log levels (take 2)
by Stephen Gallagher
Ok, I'm going to try to summarize the responses from Simo and Jakub,
then hopefully we'll accept them and we can add this information to the
coding and contribution guidelines. (I have intentionally broken the
thread).
I agree with Simo that we should break this into a bitfield. I'm going
to suggest that we consider a match of 0x000F to be an error, 0x00F0 to
be informational and 0x0F00 to be developer. This adjusts Simo's numbers
slightly, but it makes a little more room available at each level in
case we want to add a new level in the middle.
I also think we should change the config file option name to "debug"
rather than "debug_mask". I think it's more readable.
#define SSSDBG_FATAL_FAILURE 0x0000 /* level 0 */
Fatal failures. Anything that would prevent SSSD from starting up or
causes it to cease running. (Example: sssd.conf fails to parse)
#define SSSDBG_CRIT_FAILURE 0x0001 /* level 1 */
Critical failures. An error that doesn't kill the SSSD, but one that
indicates that at least one major feature is not going to work properly
(Example: Kerberos keytab does not have a valid principal for
SASL/GSSAPI LDAP)
#define SSSDBG_OP_FAILURE 0x0002 /* level 2 */
Serious failures. An error announcing that a particular request or
operation has failed. (Example: DP returns PAM_SYSTEM_ERR)
#define SSSDBG_MINOR_FAILURE 0x0004 /* level 3 */
Minor failures. These are the errors that would percolate down to
cause the operation failure of 2. (Example: The above PAM_SYSTEM_ERR was
due to the krb5_child returning an unexpected error)
#define SSSDBG_CONF_SETTINGS 0x0010 /* level 4 */
Configuration settings (E.g. the dp_option loading)
#define SSSDBG_FUNC_DATA 0x0020 /* level 5 */
Function data (E.g. LDAP search request data, Dynamic DNS message)
#define SSSDBG_TRACE_FUNC 0x0040 /* level 6 */
Trace messages for operation functions (e.g. getAccountInfo,
pamHandler)
#define SSSDBG_TRACE_LIBS 0x0100 /* level 7 */
Trace messages for internal control functions (e.g. ping,
resetOffline)
#define SSSDBG_TRACE_INTERNAL 0x0200 /* level 8 */
Contents of function-internal variables that may be interesting
#define SSSDBG_TRACE_ALL 0x0400 /* level 9 */
Extremely low-level tracing information (Example: adding/removing
D-BUS watches)
For backwards compatibility, we would map the existing debug_level
values as below:
SSS_DEBUG0: SSSDBG_FATAL_FAILURE
SSS_DEBUG1: SSS_DEBUG0 & SSSDBG_CRIT_FAILURE
SSS_DEBUG2: SSS_DEBUG1 & SSSDBG_OP_FAILURE
SSS_DEBUG3: SSS_DEBUG2 & SSSDBG_MINOR_FAILURE
SSS_DEBUG4: SSS_DEBUG3 & SSSDBG_CONF_SETTINGS
SSS_DEBUG5: SSS_DEBUG4 & SSSDBG_FUNC_DATA
SSS_DEBUG6: SSS_DEBUG5 & SSSDBG_TRACE_FUNC
SSS_DEBUG7: SSS_DEBUG6 & SSSDBG_TRACE_LIBS
SSS_DEBUG8: SSS_DEBUG7 & SSSDBG_TRACE_INTERNAL
SSS_DEBUG9: SSS_DEBUG8 & SSSDBG_TRACE_ALL
If we agree on these definitions, I will write it up on the wiki and
we'll put the following policy in place:
All new code MUST use the new DEBUG definitions. Existing code being
modified SHOULD convert related DEBUG messages to the new macros. It is
NOT required to mass-convert existing messages at this time, but patches
are welcome :)
12 years, 10 months
[PATCHES] Some optimizations of memeberof plugin
by Jan Zelený
This is the first part of some optimization I'd like to propose in memberof
plugin.
035 - mbof_dn_array optimization
This change can bring better performance in certain cases of deep and/or
circular membership structure. It reduces the complexity of some places in
code from N^3 to N^2. It has similar use case in later patches (even in those
I've not completed yet) as well.
036 - duplicate checking
This can improve performance when adding a group with many direct members,
reducing the complexity of adding a member from N^2 to N.
037 - unnecessary reallocation
I just don't like those cases when we realloc many times, each time growing
the array by 1 element. This patch removes one such case where it was
completely unnecessary.
038 - redundant duplicate checking
This one is little tricky to figure out and to be honest I'm still only 99%
sure about it. When analyzed how addop appending works, this check is totally
useless, since it will never find anything - all duplicates should be already
found by addop appending. Of course I was only considering one process modyfing
the database at a time thanks to transactions. If anyone needs a deeper
analysis, let me know, I'll explain you my train of thoughts.
Right now I'm working on the membership counter patch. It seemed to be quite
easy at first, but right now it seems that it'll take some time to make
everything work.
I'll be happy to answer any questions regarding these patches, feel free to
ping me.
Jan
12 years, 10 months
new ldap users inconsistently able to auth on existing servers
by Johnny Tan
I recently setup sssd (sssd-1.2.1-39.el5) in our environment. We have
an LDAP server running openldap-servers-2.3.43-12.el5_5.2.x86_64.
It seems that certain users can't authenticate to certain servers. All
servers have identical sssd.conf, nsswitch.conf, and system-auth-ac
files (pushed by puppet). I haven't yet found a pattern as to which
users and which servers, as it seems to be random.
I've included a couple config files.
== sssd.conf begin ==
[sssd]
config_file_version = 2
reconnection_retries = 3
sbus_timeout = 30
services = nss, pam
domains = LDAP
[nss]
filter_groups = root
filter_users = root
reconnection_retries = 3
[pam]
reconnection_retries = 3
[domain/LDAP]
id_provider = ldap
auth_provider = ldap
ldap_schema = rfc2307
ldap_uri = ldap://xxxxxxxxxxx/
ldap_search_base = dc=renttherunway,dc=com
ldap_id_use_start_tls = true
ldap_tls_reqcert = never
cache_credentials = true
enumerate = true
== sssd.conf end ==
== system-auth-ac begin ==
#%PAM-1.0
# This file is auto-generated.
# User changes will be destroyed the next time authconfig is run.
auth required pam_env.so
auth sufficient pam_unix.so nullok try_first_pass
auth requisite pam_succeed_if.so uid >= 500 quiet
auth sufficient pam_sss.so use_first_pass
auth required pam_deny.so
account required pam_unix.so broken_shadow
account sufficient pam_succeed_if.so uid < 500 quiet
account [default=bad success=ok user_unknown=ignore] pam_sss.so
account required pam_permit.so
password requisite pam_cracklib.so try_first_pass retry=3
password sufficient pam_unix.so md5 shadow nullok try_first_pass
use_authtok
password sufficient pam_sss.so use_authtok
password required pam_deny.so
session optional pam_mkhomedir.so
session optional pam_keyinit.so revoke
session required pam_limits.so
session [success=1 default=ignore] pam_succeed_if.so service in
crond quiet use_uid
session sufficient pam_sss.so
session required pam_unix.so
== system-auth-ac end ==
On the same server, debug level set to 5, here's an example of a
successful ssh attempt:
== successful-auth sssd_pam.log begin ==
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [accept_priv_fd_handler] (4):
Client connected to privileged pipe!
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_cmd_get_version] (5):
Received client version [3].
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_cmd_get_version] (5):
Offered version [3].
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_cmd_authenticate] (4):
entering pam_cmd_authenticate
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_AUTHENTICATE
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 8
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6524
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_dp_send_acct_req_create]
(4): Sending request for [LDAP][3][1][name=jt]
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_dp_get_reply] (4): Got
reply (0, 0, Success) from Data Provider
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_send_req] (4): Sending
request with the following data:
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_AUTHENTICATE
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: LDAP
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 8
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6524
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dom_forwarder] (4):
pam_dp_send_req returned 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_process_reply] (4):
received: [0][LDAP]
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): pam_reply get called.
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): pam_reply get called.
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): blen: 21
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_cmd_acct_mgmt] (4):
entering pam_cmd_acct_mgmt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_ACCT_MGMT
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6524
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_send_req] (4): Sending
request with the following data:
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_ACCT_MGMT
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: LDAP
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6524
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dom_forwarder] (4):
pam_dp_send_req returned 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_process_reply] (4):
received: [0][LDAP]
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): pam_reply get called.
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): blen: 21
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_cmd_setcred] (4): entering
pam_cmd_setcred
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_SETCRED
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6524
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_dp_send_acct_req_create]
(4): Sending request for [LDAP][3][1][name=jt]
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_dp_get_reply] (4): Got
reply (0, 0, Success) from Data Provider
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_send_req] (4): Sending
request with the following data:
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_SETCRED
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: LDAP
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6524
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dom_forwarder] (4):
pam_dp_send_req returned 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_process_reply] (4):
received: [0][LDAP]
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): pam_reply get called.
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): blen: 21
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_cmd_open_session] (4):
entering pam_cmd_open_session
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_OPEN_SESSION
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6524
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_send_req] (4): Sending
request with the following data:
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_OPEN_SESSION
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: LDAP
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6524
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dom_forwarder] (4):
pam_dp_send_req returned 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_process_reply] (4):
received: [0][LDAP]
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): pam_reply get called.
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): blen: 21
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [accept_fd_handler] (4): Client
connected!
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_cmd_get_version] (5):
Received client version [3].
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_cmd_get_version] (5):
Offered version [3].
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_cmd_setcred] (4): entering
pam_cmd_setcred
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_SETCRED
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6526
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_dp_send_acct_req_create]
(4): Sending request for [LDAP][3][1][name=jt]
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [sss_dp_get_reply] (4): Got
reply (0, 0, Success) from Data Provider
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_send_req] (4): Sending
request with the following data:
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_SETCRED
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): domain: LDAP
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): user: jt
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): priv: 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6526
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dom_forwarder] (4):
pam_dp_send_req returned 0
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_dp_process_reply] (4):
received: [0][LDAP]
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): pam_reply get called.
(Fri Jun 17 21:05:49 2011) [sssd[pam]] [pam_reply] (4): blen: 21
==
And same server, different user, just a couple minutes later (but this
user 'iambot' can ssh/auth to other identically-configured servers):
== failed-auth sssd_pam.log begin ==
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [accept_priv_fd_handler] (4):
Client connected to privileged pipe!
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [sss_cmd_get_version] (5):
Received client version [3].
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [sss_cmd_get_version] (5):
Offered version [3].
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_cmd_authenticate] (4):
entering pam_cmd_authenticate
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_AUTHENTICATE
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): domain: (null)
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): user: iambot
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 1
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 16
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6564
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [sss_dp_send_acct_req_create]
(4): Sending request for [LDAP][3][1][name=iambot]
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [sss_dp_get_reply] (4): Got
reply (1, 14, Init Groups Failed) from Data Provider
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_check_user_dp_callback]
(2): Unable to get information from Data Provider
Error: 1, 14, Init Groups Failed
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_dp_send_req] (4): Sending
request with the following data:
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): command:
PAM_AUTHENTICATE
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): domain: LDAP
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): user: iambot
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): service: sshd
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): tty: ssh
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): ruser: (null)
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): rhost:
204.145.76.74
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): authtok type: 1
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): authtok size: 16
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): newauthtok type: 0
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): newauthtok size: 0
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): priv: 1
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_print_data] (4): cli_pid: 6564
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_dom_forwarder] (4):
pam_dp_send_req returned 0
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_dp_process_reply] (4):
received: [9][LDAP]
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_reply] (4): pam_reply get called.
(Fri Jun 17 21:07:25 2011) [sssd[pam]]
[sysdb_cache_auth_get_attrs_done] (4): Cached credentials not
available.
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_reply] (4): pam_reply get called.
(Fri Jun 17 21:07:25 2011) [sssd[pam]] [pam_reply] (4): blen: 21
== failed-auth end ==
My own hypothesis is that the successful auth is using cached
credentials (since jt has logged in previously), but the failed one is
from a user that has not successfully logged into the server. But if
I'm correct, what I don't get is why sssd cannot pull information from
the LDAP provider. It's online and serving out requests, and the
failed user on this machine has successfully logged in for the first
time on a couple other servers in the same timeframe.
Thoughts?
johnny
12 years, 10 months
one liner sort of :)
by Simo Sorce
I pushed the following patch directly, it is a one liner in the sense
that is the same typo in a comment cut&pasted around a few times.
There is no code change whatsoever so I think it's ok to skip review.
Simo.
commit ec425320a9bf42954a5a28b79cb567e3a9a58ecc
Author: Simo Sorce <ssorce(a)redhat.com>
Date: Sat Jun 25 15:25:47 2011 -0400
fix typos
--
Simo Sorce * Red Hat, Inc * New York
12 years, 10 months
Discussion of debug log levels
by Stephen Gallagher
We've put this off for far too long, but I think we need to decide on a
formal specification of what the various log levels mean in SSSD (and
then open a ticket to go through them all clean them up).
We didn't do this in the past because we had expected that this would be
handled when we eventually integrated with the ELAPI (Event-Logging API)
project. Unfortunately, that project stalled upstream and its future is
unknown.
So I think we need to document the exact purpose of each log level and
publish this information so that consumers of the SSSD can have a good
understanding of what level they should set (or leave running in
production).
I'll give my first suggestions, and then I'll listen to criticism :)
First, I think we need to break the debug levels up into three ranges,
roughly corresponding to error messages, informational messages and
developer messages.
So I propose that error messages should be 0-3
0: Fatal failures. Anything that would prevent SSSD from starting up or
causes it to cease running. (Example: sssd.conf fails to parse)
1: Critical failures. An error that doesn't kill the SSSD, but one that
indicates that at least one major feature is not going to work properly
(Example: Kerberos keytab does not have a valid principal for
SASL/GSSAPI LDAP)
2: Serious failures. An error announcing that a particular request or
operation has failed. (Example: DP returns PAM_SYSTEM_ERR)
3. Minor failures. These are the errors that would percolate down to
cause the operation failure of 2. (Example: The above PAM_SYSTEM_ERR was
due to the krb5_child returning an unexpected error)
Informational messages should be 4-6
4. Configuration settings (E.g. the dp_option loading)
5. Function data (E.g. LDAP search request data, Dynamic DNS message)
6. Tracing messages for functions (Example: received DBUS method call
"ping")
Developer messages should be 7-9
7. Contents of function-internal variables that may be interesting
8. ???
9. Extremely low-level tracing information (Example: adding/removing
D-BUS watches)
12 years, 10 months