| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
add on update)
(This used to be commit 3ebecc662e0ace4a87153aabe644dcf18969435b)
|
|
- pdb_guest (including change defaults)
- 'default' passdb actions (instead of 'not implemented' stubs in each module)
- net_rpc_samsync no longer assumes pdb_unix
Andrew Bartlett
(This used to be commit 4bec53c8c81019f0f06a93c4df0800bbf7281dd6)
|
|
The work here includes:
- metze' set/changed patch, which avoids making changes to ldap on unmodified
attributes.
- volker's group mapping in passdb patch
- volker's samsync stuff
- volkers SAMR changes.
- mezte's connection caching patch
- my recent changes (fix magic root check, ldap ssl)
Andrew Bartlett
(This used to be commit 2044d60bbe0043cdbb9aba931115672bde975d2f)
|
|
(This used to be commit e026b84815ad1a5fa981c24fff197fefa73b4928)
|
|
(This used to be commit 3928578b52cfc949be5e0ef444fce1558d75f290)
|
|
to using SIDs instead of RIDs.
The new funciton sid_peek_check_rid() takes an 'expected domain sid' argument.
The idea here is to prevent mistakes where the SID is implict, but isn't
the same one that we have in the struct.
Andrew Bartlett
(This used to be commit 04f9a8ff4c7982f6597c0f6748f85d66d4784901)
|
|
passdb interface change, now the passdb modules will be asked for SID not for rid, the modules have been updated with a passthrough function that calls the old getsampwrid() functions.
srv_samr_nt.c functions that made use of the pdb_getsampwrid funcion has been updated to use the SID one.
(This used to be commit f5c6496c33fa7f5c2826540ffb4a49d8a5790fb3)
|
|
pointer.
(This used to be commit 38012edaca4c181f3d3a9e9df4fc434bba78f9dc)
|
|
Kill off the silly code that attempts to do NT -> Unix username mapping.
This is done well before here, no need to repeat it.
Add some small fixes and extra debugs, trying to track down current build
farm failures.
pdb_unix:
When 'updating' a pdb_unix account, instead add it to the default passdb.
This means that you don't need to specify '-a' to smbpasswd any more when
messing with an existing unix user, the account is simply 'upgraded'.
The idea here is that these accounts are just as 'real' as any other, they
just don't have the extra attributes an smbpasswd file does.
I'm open for debate on the pdb_unix issue, and will remove it if given
good reason. (without this, an attempt to add an account already in
pdb_unix to smbpasswd would fail, as it would fail to update pdb_unix).
rpc_server/srv_netlog_nt.c
Change a couple of things around, so as to show the client workstation etc.
WRONG_PASSWORD is certainly not the right default error. Try ACCESS_DENIED
for now.
Andrew Bartlett
(This used to be commit d78b74b338df9accd9ad84c56a49fa4f787425e2)
|
|
cleanup some of the code in net_rpc_join re const warnings and
fstrings.
Passdb:
Make the %u and %U substituions in passdb work.
This is done by declaring these paramters to be 'const' and doing
the substitution manually. I'm told this is us going full circle,
but I can't really see a better way.
Finally these things actually seem to work properly...
Make the lanman code use the pdb's recorded values for homedir etc
rather than the values from lp_*()
Add code to set the plaintext password in the passdb, where it can
decide how to store/set it. For use with a future 'ldap password
change' option, or somthing like that...
Add pdb_unix, so as to remove the 'not in passdb' special cases from the
local_lookup_*() code. Quite small, as it uses the new 'struct passwd ->
SAM_ACCOUNT' code that is now in just one place. (also used by pdb_smbpasswd)
Other:
Fix up the adding of [homes] at session setup time to actually pass
the right string, that is the unix homedir, not the UNC path.
Fix up [homes] so that for winbind users is picks the correct name.
(bad interactions with the default domain code previously)
Change the rpc_server/srv_lsa_nt.c code to match NT when for the
SATUS_NONE_MAPPED reply: This was only being triggered on
no queries, now it is on the 'no mappings' (ie all mappings failed).
Checked against Win2k.
Policy Question: Should SID -> unix_user.234/unix_group.364 be
considered a mapping or not? Currently it isn't.
Andrew Bartlett
(This used to be commit c28668068b5a3b3cf3c4317e5fb32ec9957f3e34)
|
