The prior structure of the code was safe but can appear otherwise to
static analyzers since the assignment to pids[i] occurs after exitting
the for() loop.
While here use calloc() instead of malloc()/memset().
Change-Id: I8455aa259fd8c7c17778827937ec26127fe0785c
if krb5_get_config_strings() returns the empty string do not return
immediately. Instead the for() loop will be skipped because the empty
string represents the end of the string list permitting
krb5_config_free_strings() to free the allocated memory.
Change-Id: Ia6fdb13f716c07b53c8b3857af4f7ab8be578882
Commit 4b6bd40106 made hdb_ldap_create and
hdb_ldapi_create static in the OPENLDAP_MODULE case. However, by
failing to leave a blank line between the static and the function
declaration the perl program that produces the hdb-protos.h file
skips the functions.
Add appropriate spacing.
Change-Id: I9ad24176fc31a0bce92b51f7adab141e8fa70fa3
read_master_keytab() should always return with *mkey == NULL on
failure. Doing otherwise can result in memory leaks or use of
an uninitialized pointer.
Change-Id: Ice1fd504ca573d73bb51dd3b01770c3f8bc59fd4
Apparmor on Ubuntu prevents slapd from using the Unix domain socket we
want it to. The fix is to copy the slapd executable into the objdir,
which disables the apparmor profile for slapd.
Also, make sure the ldapi: URI has the right path for the socket in
krb5.conf.
This fixes the following problems from #210:
- hdb_ldap doesn't load even when installed correctly
- loadable hdb backends not listed by kdc --builtin-hdb
Not fixed:
- hdb_ldap.so not installed in plugin dir
When building the lib/krb5 tests link against HEIMBASE in order to
make use of heim_abort() and friends.
Change-Id: Ifaf54177bbb14cddf0f3544add370cda158783d1
In krb5_parse_name_flags(), if the principal name is not an enterprise
name, is one component in length and contains an '@', set the principal
type to NT-SMTP-NAME as specified by RFC 4120.
Treat principals of type NT-UNKNOWN as NT-SRV-HST if the first component
of the principal name is "host".
Change-Id: I28fb619379daac827436040e701d4ab7b279852b
The _kdc_is_anonymous() helper function must take into account
that principals of type NT-UNKNOWN can match any other principal
type including NT-WELLKNOWN.
Change-Id: I6085b9471f6f1d662119e359491bbdce629ef048
This is part of the fix to #173. MSFT RODCs insist on the name type for
krbtgt principals be set to KRB5_NT_SRV_INST.
Commentary from Jeffrey Altman <jaltman@secure-endpoints.com>
As reported by David Mulder of Dell's Quest, Active Directory will
return a BAD_INTEGRITY error when a request for a krbtgt service
ticket is received with principal type NT-PRINCIPAL instead of NT-SRV-INST
as required by RFC 4120.
[Nico: RFC4120 does not require this. See the description of the
name-type field of PrincipalName on page 55.]
ERROR: VAS_ERR_KRB5: Failed to obtain credentials.
Client: SLED10-32$@F.QAS,
Service: SLED10-32$@F.QAS, Server: ad2-f.f.qas
Caused by: KRB5KRB_AP_ERR_BAD_INTEGRITY (-1765328353): Decrypt integrity check failed
Microsoft began enforcing principal type checking for RODCs in 2008R2.
Microsoft does state that ALL krgtgt/REALM tickets SHOULD be sent using
principal name type of KRB5_NT_SRV_INST instead of KRB5_NT_PRINCIPAL.
From Microsoft:
"I believe we discovered the problem. There isn't a bug in Windows.
There's been a code change to address another issue which puts in additional
checks for Kerberos tickets. The problem is with the Unix clients when the
client request a TGT. The Unix clients are using Name-type Principal
[KRB_NT_PRINCIPAL (1)] instead of using Name-type Service and Instance
[KRB_NT_SRV_INST (2)]...."
This change assigns the NT-SRV-INST principal type each time a krbtgt
service principal is created. Unlike Microsoft, the Heimdal mostly does
not care about the name-type of any principals, with the exception of
referrals, where the name type is needed to decide how to find a
next-hop realm.
