GssapiLocalName - gss_localname() failed: No such file or directory

[TobiKr]

Hi! I am using the latest mod_auth_gssapi with apache 2.4.46 on debian 10.8 and can't get gss_localname() to work.

Kerberos Environment:

• FreeIPA
• Aditional Active Directory
• Users are on FreeIPA OR Active Directory and should be able to authenticate against the website

Authentication with GssApiLocalName off is working well, but the application is not able to handle Realms.

krb5.conf:

[libdefaults]
default_realm = WORKSTATION.OFFICE
dns_lookup_realm = false
dns_lookup_kdc = false
rdns = false
ticket_lifetime = 24h
forwardable = yes

[realms]
WORKSTATION.OFFICE= {
  kdc = ipa.workstation.office:88
  default_domain = workstation.office
}
CORPORATE.LOCAL = {
  kdc = int-ad04.corporate.local
  admin_server = int-ad04.corporate.local
  default_domain = corporate.local
  auth_to_local = RULE:[1:$1@$0](.*@CORPORATE\.LOCAL)s/@.*//
}

[domain_realm]
.workstation.office = WORKSTATION.OFFICE
workstation.office = WORKSTATION.OFFICE
.corporate.local = CORPORATE.LOCAL
corporate.local = CORPORATE.LOCAL
corporate.de = CORPORATE.LOCAL
.corporate.de = CORPORATE.LOCAL

.htaccess of the affected website:

<RequireAll>
  AuthType GSSAPI
  AuthName "GSSAPI Login"
  GssapiAllowedMech krb5
  GssapiPublishErrors On
  GssapiLocalName on

  GssapiBasicAuth forward
  GssapiCredStore keytab:/home/office/office-ad.keytab

  require valid-user
  AuthBasicProvider           ldap
  AuthLDAPGroupAttributeIsDN  on
  AuthLDAPGroupAttribute      member
  AuthLDAPUrl                 "ldaps://ldap.office/cn=accounts,dc=workstation,dc=office?uid?sub?(objectClass=inetOrgPerson)" SSL

  ## this is required to get / allow auth eq to require valid-user
  # Require ldap-filter &(objectClass=inetOrgPerson)(|(memberOf=cn=office-ita,cn=groups,cn=accounts,dc=workstation,dc=office)(memberOf=cn=office-cod,cn=groups,cn=accounts,dc=workstation,dc=office))

  require valid-user
</RequireAll>

The following errors are logged:

[Tue Jul 06 12:08:41.148773 2021] [auth_gssapi:error] [pid 30765:tid 140024582170368] [client 192.168.212.52:0] GSS ERROR gss_localname() failed: [The operation or option is not available or unsupported (No such file or directory)]
[Tue Jul 06 12:08:41.211385 2021] [auth_gssapi:error] [pid 30764:tid 140030051854080] [client 192.168.212.52:0] INTERNAL ERROR Mechanism needs continuation but neither GssapiConnectionBound nor GssapiUseSessions are configured

I already tried to find something with strace as "No such file or directory" seems more related to a missing library or something like this, but I do not see any stat/open relating to the issue.

Thanks,
Tobias

[simo5]

ENOENT is returned when a user is not found.
GssapiLocalName is based on auth_to_local rules + ability to successfully perform getpwnam() against the name returned by auth_to_local()

[TobiKr]

Perfect, thanks for the pointer! I just found two similar cases during my reasearch - probably it would be a good idea to add the behaviour to the documentation :-)

[TobiKr]

Hi @simo5

I configured LDAP via NSS and was able to call getpwnam() via perl successfully and run nslcd in debug mode, but still get ENOENT from mod_auth_gssapi. I do not see any calls initiated by mod_auth_gssapi against nss at all (but do see my perl getpwnam() calls). Do you have any idea how to debug this further?

The following code is working:

# cat test.pl
#!/usr/bin/perl

($name, $passwd, $uid, $gid, $quota, $comment, $gcos, $dir, $shell) = getpwnam("tk");
print "Name = $name\n";
print "Password = $passwd\n";
print "UID = $uid\n";
print "GID = $gid\n";
print "Quota = $quota\n";
print "Comment = $comment\n";
print "Gcos = $gcos\n";
print "HOME DIR = $dir\n";
print "Shell = $shell\n";

output:

# ./test.pl
Name = tk
Password = *
UID = 2133
GID = 513
Quota =
Comment =
Gcos = Tobias Kritten
HOME DIR =
Shell =

Thanks,
Tobias

[TobiKr]

Short Update:

• If I use GssapiLocalName off, Kerberos Authentication is working with both Realms / KDC
• getent passwd (without realm) is working well
• auth_to_local rule is checked multiple times and should be correct

I tried to build a small c++ console app to call gss_localname() to better understand the issue and get detailed error codes, but having difficulties during build:

/usr/bin/ld: /tmp/ccGE6v18.o: in function `main':
gsslocal.cpp:(.text+0x8e): undefined reference to `GSS_C_NT_USER_NAME'
/usr/bin/ld: gsslocal.cpp:(.text+0xa2): undefined reference to `gss_import_name'
collect2: error: ld returned 1 exit status

Code (wip):

#include <iostream>
#include <string>
#include <cstring>
#include <gssapi/gssapi.h>
#include <gssapi/gssapi_ext.h>
#include <gssapi/gssapi_krb5.h>

using namespace std;

int main()
{
  OM_uint32 maj, min;


  /* get username */
  char *name_string;
  cout << "Enter username: ";
  cin >> name_string;
  cout << "Username: " << name_string << endl;

  /* convert username string to gss user */
  gss_buffer_t input_name_buffer;
  gss_name_t output_name;

  input_name_buffer->value = name_string;
  input_name_buffer->length = strlen(name_string) + 1;

  maj = gss_import_name(&min, input_name_buffer,
                  GSS_C_NT_USER_NAME, &output_name);


  cout << "User Convert return code: min " << min << " / maj " << maj << std::endl;

  /* gss_localname call
  gss_OID mech_type = GSS_C_NO_OID;
  gss_buffer_desc lname = GSS_C_EMPTY_BUFFER;
  maj = gss_localname(&min, user, mech_type , &lname); */
  return 0;
}

Installed packages:

ii  libgssapi-krb5-2:amd64                1.17-3+deb10u1               amd64        MIT Kerberos runtime libraries - krb5 GSS-API Mechanism
ii  libgssrpc4:amd64                      1.17-3+deb10u1               amd64        MIT Kerberos runtime libraries - GSS enabled ONCRPC

[simo5]

Those two simbols are defined in libgssapi_krb5.so
Can you show how you are linking your binary ?

[TobiKr]

Thank you, I had to specify it manually with the compiler: g++ /usr/lib/x86_64-linux-gnu/libgssapi_krb5.so gsslocal.cpp -o test
Can this be an issue for the gssapi_auth-module as well?

[simo5]

@TobiKr did you build mod_auth_gssapi manually invoking gcc ?
Otherwise the build scripts know about dependencies and pull them in correctly (or fail if they are not available).

[TobiKr]

Hi @simo5 and @frozencemetery,

thanks for your hints! I managed to build my code and wrote a small debug program. The result is quite interesting:

• calling gss_localname() with results in maj/min = 0
• calling gss_localname() with @ results in maj/min = 0
• calling gss_localname() with @ results in maj = 1048576 / min = 2 (The operation or option is not available or unsupported)

I attached the program and strace:
strace.log
gsslocal.txt

Did I miss something, is there a configuration issue or bug?

debug program:

#include <iostream>
#include <string>
#include <cstring>
#include <gssapi/gssapi.h>
#include <gssapi/gssapi_ext.h>
#include <gssapi/gssapi_krb5.h>

using namespace std;

int main()
{
  OM_uint32 maj, min;
  OM_uint32 message_context;
  gss_buffer_desc status_string;

  /* get username */
  string tmp_name;
  cout << "Enter username: ";
  cin >> tmp_name;
  cout << "Username: " << tmp_name << std::endl;


  /* convert username string to gss user */
  char name_string[tmp_name.length() + 1];
  strcpy(name_string, tmp_name.c_str());

  gss_buffer_desc input_name_buffer;
  gss_name_t output_name;

  input_name_buffer.value = name_string;
  input_name_buffer.length = tmp_name.length() + 1;

  maj = gss_import_name(&min,&input_name_buffer,
                  GSS_C_NT_USER_NAME, &output_name);

  cout << "User Convert return code: min " << min << " / maj " << maj << std::endl;
  message_context = 0;
  do {
          gss_display_status(
                       &min,
                       maj,
                       GSS_C_GSS_CODE,
                       GSS_C_NO_OID,
                       &message_context,
                       &status_string);
          fprintf(stderr, "%.*s\n", \
               (int)status_string.length, \
               (char *)status_string.value);

          gss_release_buffer(&min, &status_string);


  } while (message_context != 0);

  /* gss_localname call */
  gss_OID mech_type = GSS_C_NO_OID;
  gss_buffer_desc lname = GSS_C_EMPTY_BUFFER;
  maj = gss_localname(&min, output_name, mech_type , &lname);

  cout << std::endl;
  cout << "gss_localname return code: min " << min << " / maj " << maj << std::endl;

  message_context = 0;
  do {
           gss_display_status(
                        &min,
                        maj,
                        GSS_C_GSS_CODE,
                        GSS_C_NO_OID,
                        &message_context,
                        &status_string);
           fprintf(stderr, "%.*s\n", \
                (int)status_string.length, \
                (char *)status_string.value);

           gss_release_buffer(&min, &status_string);


   } while (message_context != 0);

  return 0;
}

Thanks,
Tobias

[simo5]

If you want to pass in a principal name then you should probably use GSS_KRB5_NT_PRINCIPAL_NAME as the name type.
Use gss_display_name() to see how your input is translated.

[TobiKr]

I also tried GSS_KRB5_NT_PRINCIPAL_NAME, result is the same. gss_display_name() is returning the same value as input. Do you have any other idea or do you think we identified an issue with krb5 / gssapi?

[simo5]

Well at this point I would use GDB and follow through gss_localname to see where it fails and why.

[simo5]

Doh, I just read the kerberos mailing list, I should have thought about the config issue.
Sorry you had to run in circles, I guess we should document this in mod_auth_gssapi as well ...

[TobiKr]

No worries :-) auth_to_local seems not to be very well documented. After reading the man again, I did not find any explicit information on the syntax and the mentioned behaviour regarding cross-realm.

auth_to_local = RULE:[1:[email protected]](.*@CORPORATE.LOCAL)s/@.*// does not work with user [email protected]

Did I miss something? Thanks again!

[simo5]

so youmoved the rule under the dfault realm and there exists a 'tk' user in the system ?

[TobiKr]

Ah, sorry, I missed to move the rule under the default realm. It is working finally! Thank you so much for your help 🥇

[simo5]

for the record this was Greg Hudson's reply:

auth_to_local is always looked up in the default realm, not in the realm
of the principal being authorized. This is why the rule has to do the
annoying dance of explicitly including the realm in the [] part,
matching it in the () part, and removing it in the s// part.