IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
This is based on f56a3b1846c7d462542f2e9527f4d0ed8a34748d in my heimdal-wip repo.
metze
(This used to be commit 467a1f2163a63cdf1a4c83a69473db50e8794f53)
This merges Samba4 with lorikeet-heimdal, which itself has been
tracking Heimdal CVS for the past couple of weeks.
This is such a big change because Heimdal reorganised it's internal
structures, with the mechglue merge, and because many of our 'wishes' have been granted: we now have DCE_STYLE GSSAPI, send_to_kdc hooks and many other features merged into the mainline code. We have adapted to upstream's choice of API in these cases.
In gensec_gssapi and gensec_krb5, we either expect a valid PAC, or NO
PAC. This matches windows behavour. We also have an option to
require the PAC to be present (which allows us to automate the testing
of this code).
This also includes a restructure of how the kerberos dependencies are
handled, due to the fallout of the merge.
Andrew Bartlett
(This used to be commit 4826f1735197c2a471d771495e6d4c1051b4c471)
for referencing an existing in-MEMORY keytab (required for the new way
we push that to GSSAPI).
Andrew Bartlett
(This used to be commit 2426581dfb9f5f0f9367f846c01dfd3c30fea954)
This merges Samba4 up to current lorikeet-heimdal, which includes a
replacement for some Samba-specific hacks.
In particular, the credentials system now supplies GSS client and
server credentials. These are imported into GSS with
gss_krb5_import_creds(). Unfortunetly this can't take an MEMORY
keytab, so we now create a FILE based keytab as provision and join
time.
Because the keytab is now created in advance, we don't spend .4s at
negprot doing sha1 s2k calls. Also, because the keytab is read in
real time, any change in the server key will be correctly picked up by
the the krb5 code.
To mark entries in the secrets which should be exported to a keytab,
there is a new kerberosSecret objectClass. The new routine
cli_credentials_update_all_keytabs() searches for these, and updates
the keytabs.
This is called in the provision.js via the ejs wrapper
credentials_update_all_keytabs().
We can now (in theory) use a system-provided /etc/krb5.keytab, if
krb5Keytab: FILE:/etc/krb5.keytab
is added to the secrets.ldb record. By default the attribute
privateKeytab: secrets.keytab
is set, pointing to allow the whole private directory to be moved
without breaking the internal links.
(This used to be commit 6b75573df49c6210e1b9d71e108a9490976bd41d)
