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!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
The first is "kerberos method" and replaces the "use kerberos keytab"
with an enum. Valid options are:
secrets only - use only the secrets for ticket verification (default)
system keytab - use only the system keytab for ticket verification
dedicated keytab - use a dedicated keytab for ticket verification.
secrets and keytab - use the secrets.tdb first, then the system keytab
For existing installs:
"use kerberos keytab = yes" corresponds to secrets and keytab
"use kerberos keytab = no" corresponds to secrets only
The major difference between "system keytab" and "dedicated keytab" is
that the latter method relies on kerberos to find the correct keytab
entry instead of filtering based on expected principals.
The second parameter is "dedicated keytab file", which is the keytab
to use when in "dedicated keytab" mode. This keytab is only used in
ads_verify_ticket.
The idea of this is that all client utils like smbpasswd and also for example
"net join" do not access our internal databases like passdb and secrets.tdb
directly anymore but pass everything throught the well-established RPC
interfaces.
The way you use this is the following: With rpc_cli_smbd_conn_init() or its
async variant you initialize a "struct rpc_cli_smbd_conn". This structure is
the link to a freshly forked smbd, ready to be used for RPC services. You
should only ever have one such structure in your program. More don't hurt, but
are plainly unnecessary.
If you want to use the SAMR pipe to change a passwort, you connect to that pipe
with rpc_pipe_open_local. Do you normal rpccli_samr calls on that and your
locally forked smbd will connect to passdb for you.
GD, this might make the distinction between the _l and _r calls in libnetapi
mostly unnecessary. At least it is intended to do so... :-)
