[PATCH] krb5_child: set debugging sooner
by Jakub Hrozek
Both krb5_child and ldap_child would emit a "child started" message and
only after that set up debugging to file. This might confuse users,
because unless there is an error, the krb5_child.log might actually be
empty.
I'm thinking we might also add a couple of "tracing" DEBUG messages so
that we can follow the flow in the subprocess more easily.
12 years, 1 month
pam_krb5 & wrong principal in request
by Ondrej Valousek
Hello,
I am running sssd on RHEL-6 with AD and recently found out, that I can no longer authenticate via ssh.
The message is:
pam_krb5[27045]: TGT failed verification using keytab and key for 'nfs/draco.prague.s3group.com(a)DUBLIN.AD.S3GROUP.COM': Wrong principal in
request
My krb5.keytab file has been created using Samba with "net ads join".
I can still run 'kinit <username>' to obtain a TGT.
Does anyone know what is going on here? Why is sshd verifying the TGT via just the nfs/ service principal?
Sorry for a bit off-topic question, but I hoped someone in this list might point me in the right direction.
Ondrej
12 years, 1 month
GDB pretty printers
by Jakub Hrozek
Hi,
I've been using the attached GDB helper script when debugging and I
figured it might be useful for the others, too.
I sometimes need to print and examine the contents of struct sysdb_attrs,
ldb_message or similar. Using just the print command is quite tedious.
The pretty printers can recursively print the contents of several commonly
used structures. For example this is how the first several attributes of
the IPA admin user look like:
(gdb) p *attrs
$1 = { <struct sysdb_attrs> num = 14
{ <struct ldb_message_element> flags = 0, name = 0x85ba30 "originalDN", num_values = 1
{ <struct ldb_val> data = 0x85dca0 "uid=admin,cn=users,cn=accounts,dc=idm,dc=lab,dc=bos,dc=redhat,dc=com", length = 68 } }
{ <struct ldb_message_element> flags = 0, name = 0x85b060 "name", num_values = 1
{ <struct ldb_val> data = 0x85b130 "admin", length = 5 } }
{ <struct ldb_message_element> flags = 0, name = 0x85afc0 "uidNumber", num_values = 1
The other part is a new gdb command "tbr" which sets a breakpoint to the
callback of a tevent_req without having to examine the contents of the
tevent_req structure. For example:
Breakpoint 1, sdap_get_users_process (subreq=0x85bf50) at src/providers/ldap/sdap_async_users.c:483
483 {
(gdb) n
484 struct tevent_req *req = tevent_req_callback_data(subreq,
(gdb)
486 struct sdap_get_users_state *state = tevent_req_data(req,
(gdb) tbr req
Breakpoint 2 at 0x7fe6c211b9c1: file src/providers/ldap/ldap_id.c, line 185.
(gdb) c
Continuing.
Breakpoint 2, users_get_done (subreq=0x900004000) at src/providers/ldap/ldap_id.c:185
185 {
(gdb)
The script can be loaded into gdb with the "source" command:
(gdb) source /path/to/the/script.py
12 years, 1 month