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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
case) as the keytab.
This avoids issues in replicated setups, as we will replicate the
kpasswd key correctly (including from windows, which is why I care at
the moment).
Andrew Bartlett
(This used to be commit 849500d1aa658817052423051b1f5d0b7a1db8e0)
This extracts a remote windows domain into a keytab, suitable for use
in ethereal for kerberos decryption.
For the moment, like net samdump and net samsync, the 'password
server' smb.conf option must be set to the binding string for the
server. eg:
password server = ncacn_np:mypdc
Andrew Bartlett
(This used to be commit 272013438f53bb168f74e09eb70fc96112b84772)
backend.
The idea is that every time we open an LDB, we can provide a
session_info and/or credentials. This would allow any ldb to be remote
to LDAP. We should also support provisioning to a authenticated ldap
server.
(They are separate so we can say authenticate as foo for remote, but
here we just want a token of SYSTEM).
Andrew Bartlett
(This used to be commit ae2f3a64ee0b07575624120db45299c65204210b)
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)
authentication for user@realm logins and machine account logins.
This should avoid various protocol downgrade attacks.
Andrew Bartlett
(This used to be commit 76c2d204d0a1ec66d1ef3c935688c7571b051f46)
credentials. This works with the setup/secrets.ldif change from the
previous patch, and pretty much just re-invents the keytab.
Needed for kpasswdd work.
Andrew Bartlett
(This used to be commit cc9d167bab280eaeb793a5e7dfdf1f31be47fbf5)
authentication. This pulls the creating of the keytab back to the
credentials code, and removes the special case of 'use keberos keytab
= yes' for now.
This allows (and requires) the callers to specify the credentials for
the server credentails to GENSEC. This allows kpasswdd (soon to be
added) to use a different set of kerberos credentials.
The 'use kerberos keytab' code will be moved into the credentials
layer, as the layers below now expect a keytab.
We also now allow for the old secret to be stored into the
credentials, allowing service password changes.
Andrew Bartlett
(This used to be commit 205f77c579ac8680c85f713a76de5767189c627b)
