Re: [PATCH] sam backend parameter
[EMAIL PROTECTED] wrote:
>
> On Thu, Oct 03, 2002 at 04:06:37PM +1000, Andrew Bartlett wrote:
> >
> > The use of multiple backends in passdb has acknowledged issues, and I'm
> > not particularly fussed if you feel it should not ship with this
> > functionality enabled. However, please do note that this *is* being
> > used at present, and cannot be 'just removed'. (We map our non-passdb
> > users into the system via this method). Volker has some solutions to
> > this issue however, which look very neat. I'll need to check if they
> > actually catch it all the cases.
>
> Well it's not being used really, as it's not in a production
> release. We don't make guarentees until it gets into a production
> release. What "non-passdb" users are being mapped into the system
> via this method ? Surely as a PDC we need passdb entries for every
> user we're exporting ?
I mean it's being used by code.
The problem is mainly on the fileserver: For the DC side of things,
every user is in the SAM, or they can't really do much. But on the
fileserver side, we have the problem that a user may select to view the
Owner or the ACL entries of a file.
This file may have a completely arbitrary owner.
- Winbind user? Fine. (we simply lookup the uid->sid with wibnind, and
we simply proxy requests for the name->sid/sid->name to the DC)
- passdb user? Again, OK.
In 2.2, we just used an algorithmic mapping of all such users. Remember
'2*uid+1000'? :-) Names were then looked up in the system get{pw,gr}*
calls
In HEAD, we tried to make this a bit smarter. This may or may not have
been a good thing, because it can be slow. We do getpwuid(uid), then
lookup that name in the passdb. The returned SID is sent to the client.
For names, it's a bit easier, we lookup the SID in passdb then return
the name. The reverse for name->sid. I did it this way to allow for
arbitrary RIDs.
- not in either... Not so pretty:
The tricky bit is users not in passdb. The code that deals with this is
hideous, particularly because we don't have a unified groupdb/passdb,
and mostly because I wanted to support arbitrary RIDs. (Hence one of the
reasons I started trying to rewrite this).
We need to allocate this 'unknown' user or group a RID. We need to
ensure it does not conflict with other users, and that it 'maps back'.
Why? Well, there are system accounts etc, and there are users who
appear in the system via NIS etc. The 2.2 code maps these to
SIDs/Names, and I took this as a requirement that we must do the same in
3.0
The addition of 'unixsam' was designed to put common code together.
Other parts of passdb had to deal with making a SAM entry from a passwd
struct, so I merged the code. I had considered a complete merge with
smbpasswd, but never got that far. Volker has noted a number of areas
in the auth code that could be simplified by exploiting this.
This also assisted in moving our calls to Get_Pwnam() into a very small
number of places. It is very rarely called now.
If required, this code could be split back out again, however we still
have the issue of RID allocation. (the cascading change did not affect
this, it is noted for completeness).
The rids in HEAD are allocated by '2*uid+lp_algorithmic_rid_base()', to
allow the administrator to 'push' the algorithmic space 'out of the
way'. We should look into 'automatic' RID allocation, but I am wary of
inflicting this on all our file-server users.
Andrew Bartlett
--
Andrew Bartlett [EMAIL PROTECTED]
Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED]
Student Network Administrator, Hawker College [EMAIL PROTECTED]
http://samba.org http://build.samba.org http://hawkerc.net
Re: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 04:06:37PM +1000, Andrew Bartlett wrote: > > The use of multiple backends in passdb has acknowledged issues, and I'm > not particularly fussed if you feel it should not ship with this > functionality enabled. However, please do note that this *is* being > used at present, and cannot be 'just removed'. (We map our non-passdb > users into the system via this method). Volker has some solutions to > this issue however, which look very neat. I'll need to check if they > actually catch it all the cases. Well it's not being used really, as it's not in a production release. We don't make guarentees until it gets into a production release. What "non-passdb" users are being mapped into the system via this method ? Surely as a PDC we need passdb entries for every user we're exporting ? Jeremy.
Re: [PATCH] sam backend parameter
[EMAIL PROTECTED] wrote: > > On Thu, Oct 03, 2002 at 03:36:48PM +1000, Andrew Bartlett wrote: > > Simo Sorce wrote: > > > > > > Multi domain DC is never going to happen in samba, it just doesn't make > > > sense, as the protocols used (eg. SMB) will not be able to support such > > > thing, so please let's stop to talk about multi-DC samba. > > > > I'm not so sure on this one. > > > > Some parts of the protocol might need to be told 'if not specified, use > > this', but I'm not sure the statement holds across everything. > > > > For example, I don't see any reason why we can't 'pretend' that any > > secondary domain is a 'trusted domain'. This would allow (for example) > > a resource DC, which has each machine in it, but no users, and an > > organizational DC to coexist nicely. (This is quite a common setup, > > btw). > > But not on the same machine. Sorry, I meant to indicate that resource domains are common, and that I like the idea that a resource DC could actually handle the authentication itself. > > For the rare cases where clients contact the trusted domain directly, we > > could have either a separate Samba on another IP, or they could contact > > the remote DC directly. > > That's the point. All this multi-domain stuff is "rare". > I don't want the complexity in mainline Samba. I don't > think Simo, Gerry, Volker or JF do either. > > Let just remove the multi-domain stuff for now and try > and get 3.0 in a shippable state. The 'new SAM' stuff is not being proposed for 3.0! Certainly not yet, we have a *lot* of work to do, before it gets there! Also, *please* don't confuse that with the multi-backend stuff. That has a very different purpose, and was not included in the new SAM design for exactly the reasons people don't want it in passdb. The use of multiple backends in passdb has acknowledged issues, and I'm not particularly fussed if you feel it should not ship with this functionality enabled. However, please do note that this *is* being used at present, and cannot be 'just removed'. (We map our non-passdb users into the system via this method). Volker has some solutions to this issue however, which look very neat. I'll need to check if they actually catch it all the cases. (In particular, we have the nasty requiremnt that we map NIS users and the like to and from names). Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 03:36:48PM +1000, Andrew Bartlett wrote: > Simo Sorce wrote: > > > > Multi domain DC is never going to happen in samba, it just doesn't make > > sense, as the protocols used (eg. SMB) will not be able to support such > > thing, so please let's stop to talk about multi-DC samba. > > I'm not so sure on this one. > > Some parts of the protocol might need to be told 'if not specified, use > this', but I'm not sure the statement holds across everything. > > For example, I don't see any reason why we can't 'pretend' that any > secondary domain is a 'trusted domain'. This would allow (for example) > a resource DC, which has each machine in it, but no users, and an > organizational DC to coexist nicely. (This is quite a common setup, > btw). But not on the same machine. > For the rare cases where clients contact the trusted domain directly, we > could have either a separate Samba on another IP, or they could contact > the remote DC directly. That's the point. All this multi-domain stuff is "rare". I don't want the complexity in mainline Samba. I don't think Simo, Gerry, Volker or JF do either. Let just remove the multi-domain stuff for now and try and get 3.0 in a shippable state. Jeremy.
Re: [PATCH] sam backend parameter
Simo Sorce wrote: > > Multi domain DC is never going to happen in samba, it just doesn't make > sense, as the protocols used (eg. SMB) will not be able to support such > thing, so please let's stop to talk about multi-DC samba. I'm not so sure on this one. Some parts of the protocol might need to be told 'if not specified, use this', but I'm not sure the statement holds across everything. For example, I don't see any reason why we can't 'pretend' that any secondary domain is a 'trusted domain'. This would allow (for example) a resource DC, which has each machine in it, but no users, and an organizational DC to coexist nicely. (This is quite a common setup, btw). The advantage is that this one installation could have the 'organizational' users in replicated LDAP, so it would not need to make external connections for authentication. For the rare cases where clients contact the trusted domain directly, we could have either a separate Samba on another IP, or they could contact the remote DC directly. I see this as a powerful way to push Samba into places that it currently can't go, and I would like a chance to explore it. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 12:16:53AM +0200, Simo Sorce wrote about 'Re: [PATCH] sam backend parameter': > yes a thing I'm not sure has ever been a good idea. > to be able to have sam2sam that is really read a backend + store all > info into another backend we may take several ways. > We never need the 2 backend to be loaded at the same time to do the > operation, we may easily read all the accounts chnage the backend and > store them into the new one, or simply make custom code to load 2 > different backends, and use theyr calls. > It's easy to have 2 structures calle backend1 and backend2 that holds > the functon pointers for 2 backends. > Al the context things always seemed to me overcomplicated even for > multiple backend code. the context stuff has been in passdb since the beginning and is not at all used for multiple backends - multiple backends are achieved by having multiple 'methods' structs in one context. Next to that, a 'multidb' backend will have to use multiple contexts. We don't want to spoil global name space with the variables sam_context contains. If we are removing multiple domain support, we could remove sam_methods perhaps and move all the functions in sam_methods to sam_context, but sam_context definitely has to stay... Jelmer > On Wed, 2002-10-02 at 23:56, Jelmer Vernooij wrote: > > > - what is all the context thing needed for? > > Sometimes we need multiple contexts. For example, when doing sam2sam. > > Please notice that passdb has this as well... -- Jelmer Vernooij <[EMAIL PROTECTED]> - http://nl.linux.org/~jelmer/ Development And Underdevelopment: http://library.thinkquest.org/C0110231/ Listening to 07:18:45 up 12 min, 4 users, load average: 0.09, 0.05, 0.01
Re: Explaining the new SAM
Jean Francois Micouleau wrote: > It's getting clear that you are reinventing something we already have. > All your SAM api is simply the SAMR server pipe code. Why do you want to > implement a new api as we already have one ? I have a history of doing this - and I intend to continue... It could be argued that the AuthRewrite was just a duplication of the NETLOGON code. Indeed, my original plans on that front called for the use of NETLOGON to perform the operations. However, I find the idea that the rest of Samba should call MS-defined SAMR APIs less than appealing. (As you well know, this is the approach taken by Samba-TNG). Instead, I prefer to construct an API that meets the needs of the various 'users' (be it SAMR, the auth subsystem, lanman.c etc) without using MS defined wire structures, and to which we can add a little more flexibility. For example, the auth subsystem allows the use of 'security=server', which I could not force through the NETLOGON interface. Similarly, I expect that there will be other cases where we will want information about a user that cannot be easily (or efficiently) extracted from SAMR calls. Finally, I don't think that smbpasswd etc should have to go so far out of their way (linking our rpc client and server code) in order to perform their operations. I prefer to take one step back, and construct an API that is influenced by, but not dictated by, the SAMR pipe. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: [PATCH] sam backend parameter
Simo Sorce wrote: > Plus I have some questions about the current sam interface: > > - what is all the context thing needed for? I don't like global variables, and this allows us to construct seperate contexts for operations like sam2sam, and testing, without fiddiling with global variables. > - what is the handle thing needed for ? Same as the SAM_ACCOUNT in pdb. > - what is access desired meant to do ? Authorization is a different > thing then storage, a backend is a storage! The SAM interface layer is the 'choke point'. If we do not wan't nasty races, then we must reterive things like the security descriptor with the data it applies to. This implies that the ACL checking code must resise either in the SAM backend, or the SAM interface. If we export it above this layer, we *will* get places where we don't check it properly. > - why do we insist to have a thing called unix accounts? It just does > not make sense to me. We need "real" users/groups mapping instead > (opposed to created on the fly by winbind based accounts). I'm not sure what you mean here - the current code doesn't even know about unix accounts. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: [PATCH] sam backend parameter
>No, the idea is that one SAM backend would know about only one domain, >but that we could have multiple domains, each with their own backend. >For smbd it doesn't make much sense, except that I was looking at >handling 'builtin' stuff by abstraction into a separate 'domain' this >way. (I favor putting special cases into modules, rather than in >interfaces). FWIW, this is what Active Directory does (cf. builtinDomain in the schema). -- Luke -- Luke Howard | PADL Software Pty Ltd | www.padl.com
Re: [PATCH] sam backend parameter
Gerald Carter wrote: > > On Wed, 2 Oct 2002 [EMAIL PROTECTED] wrote: > > > > The other cases for 'multiple domain' support involve the way these > > > users are reflected back into unix by winbindd, which might be running > > > on a system that has multiple, independent smbd instances on separate > > > IPs. > > OK. I just caught this. One winbnidd install serving multiple smbd > installations on the same host? This seems like complicating the > a corner case requirement. My concern is about the ongoing maintainence > and administration of the code. > > Code that is only understood by one person is unmaintainable code. > Nothing against you mind you. If i was the only one who understand > how our printer change notify code worked for example, I would argue > the same point. > > It could also be that the only one person understands it phenomena > it partly our fault as well for not digging in earlier. Water under > the bridge at this point. Well work on it better in the future :-) The only reason we have this code at all is becouse it *is* simple. Current problems with how to specify it in smb.conf aside, the relevent code is not long, nor complex. We would need almost as many lines of code if we were to kill it, becouse we need to verify these things anyway. (That a sensible 'domain' or 'domain sid' has been passed). Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: ACL inheritance mess with win2k clients...
Perhaps I should clear up the access pattern. On 2k->samba acl sets, If the tree looks like this: /a/b/c/d/e (where e is a file, the rest are dirs) a set on /a which says "reset child permissions..." generates set_secdescs like this: /a/b/c/d/e /a/b/c/d/e /a/b/c/d /a/b/c/d/e /a/b/c/d /a/b/c /a/b/c/d/e /a/b/c/d /a/b/c /a/b /a/b/c/d/e /a/b/c/d /a/b/c/ /a/b /a /a/b/c/d/e /a/b/c/d /a/b/c/ /a/b /a The same thing happens to NT, but the final group of set's have different ACLs... Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
Re: ACL inheritance mess with win2k clients...
>> Using a 2k client, that same checkbox is named "reset permissions on all >> child objects and enable propagation of inheritable permissions", and it >> causes the following behavior: for each file/dir in a tree, it propagates >> the current permissions from parent to the child (so far so good), but it >> does it from the deepest point up, so what we get is: >> >> /a/b/c/d/e gets /a/b/c/d's current permissions >> /a/b/c/d gets /a/b/c's current permissions >> /a/b/c gets /a/b's current permissions >> /a/b gets /a's current permissions >> /a gets set as you said. >> >> When 2k does this to NT, it all works ok. the 2k client is explicitly >> setting everything the way you want. Something is telling him to do it >> differently with us. I first suspected ACL revisions, but I did eliminate >> that pretty quickly (two lines of change). Any ideas here? > >So when a W2K client does this to a NT server, what pattern of ACL >set operations gets done ? The same acl gets applied to all, so the same set is done in this order: /a/b/c/d/e /a/b/c/d /a/b/c /a/b /a So they all end up with the same thing. It still even tries to set the auto-inherited bit. Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
Re: ACL inheritance mess with win2k clients...
On Tue, Oct 01, 2002 at 04:36:18PM -0400, Jim McDonough wrote: > Setting ACLs from an NT4 client, checking the box that says "reset > permission on child objects", everything seems to work fine. I'm using > current SAMBA_2_2. > > Using a 2k client, that same checkbox is named "reset permissions on all > child objects and enable propagation of inheritable permissions", and it > causes the following behavior: for each file/dir in a tree, it propagates > the current permissions from parent to the child (so far so good), but it > does it from the deepest point up, so what we get is: > > /a/b/c/d/e gets /a/b/c/d's current permissions > /a/b/c/d gets /a/b/c's current permissions > /a/b/c gets /a/b's current permissions > /a/b gets /a's current permissions > /a gets set as you said. > > When 2k does this to NT, it all works ok. the 2k client is explicitly > setting everything the way you want. Something is telling him to do it > differently with us. I first suspected ACL revisions, but I did eliminate > that pretty quickly (two lines of change). Any ideas here? So when a W2K client does this to a NT server, what pattern of ACL set operations gets done ? Jeremy.
Re: ACL inheritance mess with win2k clients...
On Wed, Oct 02, 2002 at 06:07:00PM -0400, ZINKEVICIUS,MATT (HP-Loveland,ex1) wrote: > I think he would win the quarter :-) Never setting those bits is exactly > what tells the client that we're using NT4 style inheritance. See my NT > security semantics patch which set these bits when appropriate. Ok, maybe I'm being dumb here... but I thought the problem is the client is treating us as though we were W2K, not NT ? So we don't want to set them... right ? Jeremy.
Re: [PATCH] sam backend parameter
yes a thing I'm not sure has ever been a good idea. to be able to have sam2sam that is really read a backend + store all info into another backend we may take several ways. We never need the 2 backend to be loaded at the same time to do the operation, we may easily read all the accounts chnage the backend and store them into the new one, or simply make custom code to load 2 different backends, and use theyr calls. It's easy to have 2 structures calle backend1 and backend2 that holds the functon pointers for 2 backends. Al the context things always seemed to me overcomplicated even for multiple backend code. Simo. On Wed, 2002-10-02 at 23:56, Jelmer Vernooij wrote: > > - what is all the context thing needed for? > Sometimes we need multiple contexts. For example, when doing sam2sam. > Please notice that passdb has this as well... > > Jelmer > > -- > Jelmer Vernooij <[EMAIL PROTECTED]> - http://nl.linux.org/~jelmer/ > Development And Underdevelopment: http://library.thinkquest.org/C0110231/ > Listening to > 23:55:29 up 11:49, 10 users, load average: 0.27, 0.39, 0.39 -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
RE: ACL inheritance mess with win2k clients...
I think he would win the quarter :-) Never setting those bits is exactly what tells the client that we're using NT4 style inheritance. See my NT security semantics patch which set these bits when appropriate. --Matt > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Wednesday, October 02, 2002 2:15 PM > To: Eric Lee Steadle > Cc: Jim McDonough; [EMAIL PROTECTED] > Subject: Re: ACL inheritance mess with win2k clients... > > > On Wed, Oct 02, 2002 at 04:05:45PM -0400, Eric Lee Steadle wrote: > > >Ok - so how does the W2K client "know" it's talking to a W2K or NT > > >server ? Any idea what criteria a W2K client uses to check ? > > > > > > Well, I'm pretty sure it (the client) checks for one or > more w2k specific > > flags: SE_DACL_AUTO_INHERITED, or perhaps > SE_DACL_PROTECTED. Jim said that the > > client sets the SE_DACL_AUTO_INHERITED flag, (which is not > honored by Samba, > > nor would it be by NT4) then it queries for those flags > again. I'd bet a > > quarter that it (the client) is trying to determine what > ACL inheritence > > mechanism is being used by the server. > > You'd lose that quarter Samba never sets any of these flags, so > the client cannot be using their presense to determine if we support > W2K or NT ACLs. > > Jeremy. >
Re: [PATCH] sam backend parameter
> - what is all the context thing needed for? Sometimes we need multiple contexts. For example, when doing sam2sam. Please notice that passdb has this as well... Jelmer -- Jelmer Vernooij <[EMAIL PROTECTED]> - http://nl.linux.org/~jelmer/ Development And Underdevelopment: http://library.thinkquest.org/C0110231/ Listening to 23:55:29 up 11:49, 10 users, load average: 0.27, 0.39, 0.39
Re: [PATCH] sam backend parameter
Multi domain DC is never going to happen in samba, it just doesn't make sense, as the protocols used (eg. SMB) will not be able to support such thing, so please let's stop to talk about multi-DC samba. Also, the winbindd argument is bogus. Winbind will not use at all the sam interface to look for user name->uid mapping, it should just ask the simgle domain present on the interfaces of the machine to resolve the names, exactly in the same way it currently do against NT domains, and then just call the SID mapping code do resolve the uid. The SID mapping code should be the only shared code beetween winbind and the account management system. We need to evolve the current winbind_idmap code to become the new SID Mapping System. LAst I find it really dummy to think at nuiltin as a separate domain. It isn't at all, and makes things bad. Every single backend module should contain the entire domain, every domain has "normal" SIDs and some special SID, we do not need to threat special entirely into the interface, we can easily handle them inside the backend. Ther's no problem to do so, except if someone want at all cost try to support multiple domain in sam interface, a thing many of us already said is not going to happen anyway. Buitin are intimately connected to the rest of the domain, having to heavily switch operations between two backends makes really little sense, and bultin accounts are also very few, you cannot add bultin accounts, and least but not last, builtin grops will contain users as members, what sense does it make to have builtin groups to contain SID of foreign domains (as it will be most probably shared beetwen domains) what security problmes does it pose to have all thi promiscuity? What happen when in one domain we want to change some builtin account proprty to something differnt than what other domains will like? I really think that even in a ipothetical multi-DC environment a separate "builtin" backend is a plain worng solution. Plus I have some questions about the current sam interface: - what is all the context thing needed for? - what is the handle thing needed for ? - what is access desired meant to do ? Authorization is a different thing then storage, a backend is a storage! - why do we insist to have a thing called unix accounts? It just does not make sense to me. We need "real" users/groups mapping instead (opposed to created on the fly by winbind based accounts). Simo. On Wed, 2002-10-02 at 16:47, Jelmer Vernooij wrote: > On Wed, Oct 02, 2002 at 09:19:47AM -0500, Gerald Carter wrote about 'Re: [PATCH] sam >backend parameter': > > On Tue, 1 Oct 2002, Eddie Lania wrote: > > > > Like I've said, I'm not a developer, but maybe the "multiple domain > > > support" parameter could be extended with the backend method? Like this: > > > > "multiple domain support = DOMA:backendA, DOMB:backendB, etc" > > Can someone please explain the purpose of supporting accounts from > > different domains in a single SAM ? Why would we ever want to do > > this? > Builtin or multi-domain DC afaik - Kai and Andrew know all the how's > and why's. > > > Jelmer > > -- > Jelmer Vernooij <[EMAIL PROTECTED]> > Pending (unfinished) patches >http://samba.org/~jelmer/diffs.php -- Simo Sorce - [EMAIL PROTECTED] Xsec s.r.l. via Durando 10 Ed. G - 20158 - Milano tel. +39 02 2399 7130 - fax: +39 02 700 442 399 signature.asc Description: This is a digitally signed message part
Re: smbclient bug in 2.2.5
On Wed, Oct 02, 2002 at 02:23:04PM -0700, Andrew Morgan wrote: > > Works here. Thanks for the quick response! > > Will this make it into the 2.2.6 release? Already did :-). Thanks, Jeremy.
Re: smbclient bug in 2.2.5
Works here. Thanks for the quick response!
Will this make it into the 2.2.6 release?
Andy
On Wed, 2 Oct 2002 [EMAIL PROTECTED] wrote:
> On Wed, Oct 02, 2002 at 09:26:08AM -0700, Andrew Morgan wrote:
> >
> > I think I've found a bug in the smbclient program in 2.2.5. Smbclient
> > hard-codes the name_type to 0x20 (File Server) for all netbios queries,
> > but calling 'smbclient -M machine' should use a name_type of 0x03
> > (Messenger) instead.
> >
> > When sending a message to a machine, it is not necessary for the machine
> > to be running file sharing. Our client machines have file sharing turned
> > off and do not register 0x20 with the WINS server. I'm not sure when this
> > behavior changed, but the smbclient program from samba 2.0.10 works
> > correctly.
>
> Try this patch - I'm going to commit to all branches...
>
> Jeremy.
>
> Index: client/client.c
> ===
> RCS file: /data/cvs/samba/source/client/client.c,v
> retrieving revision 1.148.2.30
> diff -u -r1.148.2.30 client.c
> --- client/client.c 27 Aug 2002 14:49:19 - 1.148.2.30
> +++ client/client.c 2 Oct 2002 20:46:31 -
> @@ -2422,8 +2422,9 @@
> }
>
> /
> -handle a message operation
> + Handle a message operation.
> /
> +
> static int do_message_op(void)
> {
> struct in_addr ip;
> @@ -2435,7 +2436,15 @@
> make_nmb_name(&called , desthost, name_type);
>
> zero_ip(&ip);
> - if (have_ip) ip = dest_ip;
> + if (have_ip)
> + ip = dest_ip;
> + else if (name_type != 0x20) {
> + /* We must do our own resolve name here as the nametype is #0x3, not
>#0x20. */
> + if (!resolve_name(desthost, &ip, name_type)) {
> + DEBUG(0,("Cannot resolve name %s#0x%x\n", desthost,
>name_type));
> + return 1;
> + }
> + }
>
> if (!(cli=cli_initialise(NULL)) || (cli_set_port(cli, port) == 0) ||
>!cli_connect(cli, desthost, &ip)) {
> DEBUG(0,("Connection to %s failed\n", desthost));
>
Re: Explaining the new SAM
On Wed, 2 Oct 2002, Andrew Bartlett wrote: > Gerald Carter wrote: > > > > On Wed, 2 Oct 2002, Andrew Bartlett wrote: > > > > > > This seems like a lot of duplication of code and can lead to > > > > "There's a bug in SAM1 but not SAM2". If the access checks > > > > will always be the same, why push them into the SAM module and > > > > force each write to cut-n-paste security descriptor code. > > > > > > Yes, I am worried about that a bit. The main issue is that I would like > > > a single read from LDAP - so we don't get a race there. But we could do > > > it 'after the fact', and get each module to pass up the security > > > descriptor to the SAM interface layer. > > > > Ahhhok I see now. But it still seems like a lot of duplicated > > code. > > I'm starting to agree that putting it in the interface is a 'good > thing'. If the backend wants to double-check, then that's fine, but the > intereface should be handed back a sec desc to check itself. (A SAM > that really wants to get around this can return an allow-all sec desc if > it must...). This does make it harder for module writers to 'stuff up'. > > > Taking another perspective, i'm still not convinced why a security > > descriptor on each SAM object is needed. What do we gain by it > > at the cost of added complexity? > > NT allows these to be set remotely on each SAM object. In particular > the 'user cannot change password' is implemented in terms of an NT ACL > on the user in the SAM. > > > > > So a SAM is a passdb with ACL's. What else? > > > > > > Groups and policies thown in, but it's not really meant to be that > > > > By policies you mean "rights" like "backup files" ? > > Also 'max password age' etc. > > > > massive. One step at a time and such things. Also a move to NTTIME in > > > the interfaces, and an attempt to cope with a wider scope of problems. > > > > What "wider scope of problems"? Without knowing what you are trying to > > address, it's pretty hard to comment. > > Mostly to cope with all the things that can be set over the SAMR pipe. > (most of which are above). I think we are also meddiling a little in > the LSA pipe too, which may or may not be a good thing... > > It may well make sense to store all the replication stuff in the same > backend, to avoid having to run muliple synronistation setups. (ie if > LDAP is doing all the SAM stuff, make it keep the LSA secrets too). I'm > still thinking on this stuff, but that's the kind of longer-term I'm > looking for. It's getting clear that you are reinventing something we already have. All your SAM api is simply the SAMR server pipe code. Why do you want to implement a new api as we already have one ? J.F.
Re: smbclient bug in 2.2.5
On Wed, Oct 02, 2002 at 09:26:08AM -0700, Andrew Morgan wrote:
>
> I think I've found a bug in the smbclient program in 2.2.5. Smbclient
> hard-codes the name_type to 0x20 (File Server) for all netbios queries,
> but calling 'smbclient -M machine' should use a name_type of 0x03
> (Messenger) instead.
>
> When sending a message to a machine, it is not necessary for the machine
> to be running file sharing. Our client machines have file sharing turned
> off and do not register 0x20 with the WINS server. I'm not sure when this
> behavior changed, but the smbclient program from samba 2.0.10 works
> correctly.
Try this patch - I'm going to commit to all branches...
Jeremy.
Index: client/client.c
===
RCS file: /data/cvs/samba/source/client/client.c,v
retrieving revision 1.148.2.30
diff -u -r1.148.2.30 client.c
--- client/client.c 27 Aug 2002 14:49:19 - 1.148.2.30
+++ client/client.c 2 Oct 2002 20:46:31 -
@@ -2422,8 +2422,9 @@
}
/
-handle a message operation
+ Handle a message operation.
/
+
static int do_message_op(void)
{
struct in_addr ip;
@@ -2435,7 +2436,15 @@
make_nmb_name(&called , desthost, name_type);
zero_ip(&ip);
- if (have_ip) ip = dest_ip;
+ if (have_ip)
+ ip = dest_ip;
+ else if (name_type != 0x20) {
+ /* We must do our own resolve name here as the nametype is #0x3, not
+#0x20. */
+ if (!resolve_name(desthost, &ip, name_type)) {
+ DEBUG(0,("Cannot resolve name %s#0x%x\n", desthost,
+name_type));
+ return 1;
+ }
+ }
if (!(cli=cli_initialise(NULL)) || (cli_set_port(cli, port) == 0) ||
!cli_connect(cli, desthost, &ip)) {
DEBUG(0,("Connection to %s failed\n", desthost));
Re: ACL inheritance mess with win2k clients...
On Wed, Oct 02, 2002 at 04:05:45PM -0400, Eric Lee Steadle wrote: > >Ok - so how does the W2K client "know" it's talking to a W2K or NT > >server ? Any idea what criteria a W2K client uses to check ? > > > Well, I'm pretty sure it (the client) checks for one or more w2k specific > flags: SE_DACL_AUTO_INHERITED, or perhaps SE_DACL_PROTECTED. Jim said that the > client sets the SE_DACL_AUTO_INHERITED flag, (which is not honored by Samba, > nor would it be by NT4) then it queries for those flags again. I'd bet a > quarter that it (the client) is trying to determine what ACL inheritence > mechanism is being used by the server. You'd lose that quarter Samba never sets any of these flags, so the client cannot be using their presense to determine if we support W2K or NT ACLs. Jeremy.
RE: ACL inheritance mess with win2k clients...
>Ok - so how does the W2K client "know" it's talking to a W2K or NT
>server ? Any idea what criteria a W2K client uses to check ?
Well, I'm pretty sure it (the client) checks for one or more w2k specific
flags: SE_DACL_AUTO_INHERITED, or perhaps SE_DACL_PROTECTED. Jim said that the
client sets the SE_DACL_AUTO_INHERITED flag, (which is not honored by Samba,
nor would it be by NT4) then it queries for those flags again. I'd bet a
quarter that it (the client) is trying to determine what ACL inheritence
mechanism is being used by the server.
Brown says (p. 227)
"If you want to determine whether a particular ACL is participating in a
Windows 2000 style automatic inheritence synchronization ccheme, look for the
following bits in the control word of the security descriptor by calling
GetSecurityDescriptorControl:
SE_DACL_AUTO_INHERITED
SE_SACL_AUTO_INHERITED
A security descriptor for securable objects looks like this:
typedef struct _SECURITY_DESCRIPTOR {
BYTE Revision;
BYTE Sbz1;
SECURITY_DESCRIPTOR_CONTROL Control;
PSID Owner;
PSID Group;
PACL Sacl;
PACL Dacl;
} SECURITY_DESCRIPTOR, *PISECURITY_DESCRIPTOR;
The SECURITY_DESCRIPTOR_CONTROL member is a bitfield (16 bits) whose
parameters qualify the meaning of the fields in the security descriptor.
One of these bits is SE_DACL_AUTO_INHERITED.
According to MSDN documentation for SECURITY_DESCRIPTOR_CONTROL:
"SE_DACL_AUTO_INHERITED (Windows 2000 or later): Indicates a security
descriptor in which the DACL is set up to support automatic propagation of
inheritable ACEs to existing child objects.
For Windows 2000 ACLs that support auto inheritance, this bit is always set.
It is used to distinguish these ACLs from Windows NT 4.0 ACLs that do not
support auto-inheritance. Protected servers can call the
ConvertToAutoInheritPrivateObjectSecurity function to convert a security
descriptor and set this flag.
This bit is not set in security descriptors for Windows NT versions 4.0 and
earlier, which do not support automatic propagation of inheritable ACEs."
So MS servers keep track of it in their security descriptor control structure,
which I imagine is stored in the file system security database on disk.
All evidence points to SE_DACL_AUTO_INHERITED.
So if it's not working when set appropriately, then I'd say there's another
problem. Maybe with the inheritence mechanism itself? Or mabye both
SE_DACL_AUTO_INHERITED AND SE_SACL_AUTO_INHERITED must be set?
ERX
>-Original Message-
>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
>Sent: Wednesday, October 02, 2002 3:23 PM
>To: Eric Lee Steadle
>Cc: Jim McDonough; [EMAIL PROTECTED]
>Subject: Re: ACL inheritance mess with win2k clients...
>
>
>On Wed, Oct 02, 2002 at 03:05:52PM -0400, Eric Lee Steadle wrote:
>> Yep. Exactly what I've observed and exactly as documented by MS.
>>
>> >He tries to set it to an NT server, also...but
>> >somehow he realizes that it doesn't get set and changes all the acls to
>> >match, rather than relying on inheritance.
>>
>> Because the client knows that NT4 servers don't do acl inheritence
>propogation
>> for him, but 2k servers do. This behavior is documented pretty
>well in Keith
>> Brown's book.
>
>Ok - so how does the W2K client "know" it's talking to a W2K or NT
>server ? Any idea what criteria a W2K client uses to check ?
>
>Jeremy.
RE: ACL inheritance mess with win2k clients...
>Because the client knows that NT4 servers don't do acl inheritence propogation >for him, but 2k servers do. This behavior is documented pretty well in Keith Yeah, I figured as much...but how do we make him realize WE don't do acl inheritance propogation? Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
Re: ACL inheritance mess with win2k clients...
On Wed, Oct 02, 2002 at 03:05:52PM -0400, Eric Lee Steadle wrote: > Yep. Exactly what I've observed and exactly as documented by MS. > > >He tries to set it to an NT server, also...but > >somehow he realizes that it doesn't get set and changes all the acls to > >match, rather than relying on inheritance. > > Because the client knows that NT4 servers don't do acl inheritence propogation > for him, but 2k servers do. This behavior is documented pretty well in Keith > Brown's book. Ok - so how does the W2K client "know" it's talking to a W2K or NT server ? Any idea what criteria a W2K client uses to check ? Jeremy.
RE: ACL inheritance mess with win2k clients...
>-OriginThis behavior is documented pretty >well in Keith >> Brown's book. > >Which one? Oops, sorry... "Programming Windows Security" Keith Brown Addison Wesley 2000 p. 211 starts the discussion of NT4 acl inheritence. p. 215 talks about w2k.
Repost: usrmgr fails to get local groups?
Hello, Usrmgr.exe (UserManager for domains for windows nt) is unable to start because it can't find the group (it says). I hope that this problem can be solved soon. Even while I shutted down Samba, deleted all tdb files and restarted Samba, it still doesn't work. Some technical information: Compiled from cvs on 1 October 2002 at 23:20h CET. RedHat 7.0 kernel, 2.2.19-7.0.16 openldap-2.0.21-0.7.1 nss_ldap-189-1.7 krb5-libs-1.2.2-14 krb5-devel-1.2.2-14 gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85) /etc/pam.d/samba and /etc/nsswitch.conf configured as required. Configure options used: --sbindir=/usr/local/samba/bin \ --with-logfilebase=/var/log/samba \ --with-krb5=/usr/kerberos \ --with-smbmount \ --with-pam \ --with-acl-support Output of smbgroupedit -vs NT group (SID) -> Unix group System Operators (S-1-5-32-549) -> Server Operators Replicator (S-1-5-21-3705070864-1991026996-600314423-1457) -> Replicator Account Operators (S-1-5-21-3705070864-1991026996-600314423-1449) -> Account Operators Replicators (S-1-5-32-552) -> Replicator Guests (S-1-5-32-546) -> Guests Power Users (S-1-5-32-547) -> Power Users Print Operators (S-1-5-32-550) -> Print Operators Administrators (S-1-5-32-544) -> Administrators Account Operators (S-1-5-32-548) -> Account Operators Domain Users (S-1-5-21-3705070864-1991026996-600314423-1403) -> Domain Users Domain Admins (S-1-5-21-3705070864-1991026996-600314423-1401) -> Domain Admins Server Operators (S-1-5-21-3705070864-1991026996-600314423-1451) -> Server Operators Users (S-1-5-21-3705070864-1991026996-600314423-1443) -> Users Domain Guests (S-1-5-21-3705070864-1991026996-600314423-1405) -> Domain Guests Administrators (S-1-5-21-3705070864-1991026996-600314423-1441) -> Administrators Print Operators (S-1-5-21-3705070864-1991026996-600314423-1453) -> Print Operators Guests (S-1-5-21-3705070864-1991026996-600314423-1445) -> Guests Backup Operators (S-1-5-32-551) -> Backup Operators Users (S-1-5-32-545) -> Users Backup Operators (S-1-5-21-3705070864-1991026996-600314423-1455) -> Backup Operators Domain Users (S-1-5-21-3705070864-1991026996-600314423-513) -> Domain Users Power Users (S-1-5-21-3705070864-1991026996-600314423-1447) -> Power Users Domain Admins (S-1-5-21-3705070864-1991026996-600314423-512) -> Domain Admins Domain Guests (S-1-5-21-3705070864-1991026996-600314423-514) -> Domain Guests Eddie. > Hello, > > I compiled samba from cvs this morning. > Now, using usrmgr.exe (svrtools for windows NT), it is unable to find the > local groups? > > Anyone noticed this yet? > > > Eddie.
RE: ACL inheritance mess with win2k clients...
On Wed, 2 Oct 2002, Eric Lee Steadle wrote: > Yep. Exactly what I've observed and exactly as documented by MS. > > >He tries to set it to an NT server, also...but > >somehow he realizes that it doesn't get set and changes all the acls to > >match, rather than relying on inheritance. > > Because the client knows that NT4 servers don't do acl inheritence propogation > for him, but 2k servers do. This behavior is documented pretty well in Keith > Brown's book. Which one? Regards - Richard Sharpe, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]
RE: ACL inheritance mess with win2k clients...
Yep. Exactly what I've observed and exactly as documented by MS. >He tries to set it to an NT server, also...but >somehow he realizes that it doesn't get set and changes all the acls to >match, rather than relying on inheritance. Because the client knows that NT4 servers don't do acl inheritence propogation for him, but 2k servers do. This behavior is documented pretty well in Keith Brown's book. ERX >-Original Message- >From: Jim McDonough [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, October 02, 2002 2:50 PM >To: [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >Subject: RE: ACL inheritance mess with win2k clients... > > > >>Maybe this one is set improperly? >> >>SE_DACL_AUTO_INHERITED >Well, the 2k client tries to set it, but we don't honor it, and when he >queries, it's not set. He tries to set it to an NT server, also...but >somehow he realizes that it doesn't get set and changes all the acls to >match, rather than relying on inheritance. > >Jim McDonough >IBM Linux Technology Center >Samba Team >6 Minuteman Drive >Scarborough, ME 04074 >USA > >[EMAIL PROTECTED] >[EMAIL PROTECTED] > >Phone: (207) 885-5565 >IBM tie-line: 776-9984 >
RE: ACL inheritance mess with win2k clients...
>Maybe this one is set improperly? > >SE_DACL_AUTO_INHERITED Well, the 2k client tries to set it, but we don't honor it, and when he queries, it's not set. He tries to set it to an NT server, also...but somehow he realizes that it doesn't get set and changes all the acls to match, rather than relying on inheritance. Jim McDonough IBM Linux Technology Center Samba Team 6 Minuteman Drive Scarborough, ME 04074 USA [EMAIL PROTECTED] [EMAIL PROTECTED] Phone: (207) 885-5565 IBM tie-line: 776-9984
RE: Compile warnings.
Generally these errors are not very interesting. However, patches are always welcome to make them go away. My experience is that it is a good idea to test any such patches on a couple of different platforms before submitting them, as these messages often are due to subtle incompatibilities between headers on different implementations (e.g, "const char *" vs. "char *"). Thanks PG -Original Message- From: Eddie Lania [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 02, 2002 4:10 AM To: [EMAIL PROTECTED] Subject: Compile warnings. Compiled from cvs on 2 October 2002 at 09:48h CET. RedHat 7.0 kernel, 2.2.19-7.0.16 openldap-2.0.21-0.7.1 nss_ldap-189-1.7 krb5-libs-1.2.2-14 krb5-devel-1.2.2-14 gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85) Configure options used: --sbindir=/usr/local/samba/bin \ --with-logfilebase=/var/log/samba \ --with-krb5=/usr/kerberos \ --with-smbmount \ --with-pam \ --with-acl-support Warnings: Compiling smbd/mangle_hash2.c smbd/mangle_hash2.c: In function `cache_insert': smbd/mangle_hash2.c:172: warning: assignment makes pointer from integer without a cast smbd/mangle_hash2.c: In function `is_mangled': smbd/mangle_hash2.c:263: warning: initialization makes pointer from integer without a cast Compiling libsmb/clispnego.c libsmb/clispnego.c: In function `spnego_gen_negTokenTarg': libsmb/clispnego.c:330: warning: passing arg 1 of `krb5_get_ticket' discards qualifiers from pointer target type Compiling passdb/secrets.c passdb/secrets.c: In function `secrets_fetch': passdb/secrets.c:61: warning: assignment discards qualifiers from pointer target type passdb/secrets.c: In function `secrets_store': passdb/secrets.c:77: warning: assignment discards qualifiers from pointer target type passdb/secrets.c:79: warning: assignment discards qualifiers from pointer target type passdb/secrets.c: In function `secrets_delete': passdb/secrets.c:93: warning: assignment discards qualifiers from pointer target type passdb/secrets.c: In function `secrets_lock_trust_account_password': passdb/secrets.c:218: warning: passing arg 2 of `tdb_lock_bystring' discards qualifiers from pointer target type passdb/secrets.c:220: warning: passing arg 2 of `tdb_unlock_bystring' discards qualifiers from pointer target type passdb/secrets.c: In function `secrets_get_trusted_domains': passdb/secrets.c:509: warning: assignment makes pointer from integer without a cast passdb/secrets.c: In function `secrets_named_mutex': passdb/secrets.c:610: warning: passing arg 1 of `tdb_set_lock_alarm' discards qualifiers from pointer target type Compiling lib/util_str.c lib/util_str.c: In function `str_list_make': lib/util_str.c:1160: warning: passing arg 3 of `next_token' discards qualifiers from pointer target type Compiling lib/util.c lib/util.c: In function `smb_xstrndup': lib/util.c:1832: warning: initialization makes pointer from integer without a cast Compiling lib/gencache.c lib/gencache.c: In function `gencache_get': lib/gencache.c:248: warning: initialization makes pointer from integer without a cast lib/gencache.c: In function `gencache_iterate': lib/gencache.c:303: warning: assignment makes pointer from integer without a cast Compiling libads/ldap.c libads/ldap.c: In function `ads_do_paged_search': libads/ldap.c:443: warning: passing arg 2 of `str_list_copy' from incompatible pointer type libads/ldap.c: In function `ads_do_search': libads/ldap.c:669: warning: passing arg 2 of `str_list_copy' from incompatible pointer type Compiling libads/ldap_printer.c libads/ldap_printer.c: In function `ads_mod_printer_entry': libads/ldap_printer.c:80: warning: passing arg 4 of `ads_mod_strlist' from incompatible pointer type libads/ldap_printer.c:96: warning: passing arg 4 of `ads_mod_strlist' from incompatible pointer type libads/ldap_printer.c:99: warning: passing arg 4 of `ads_mod_strlist' from incompatible pointer type Compiling libads/kerberos.c libads/kerberos.c: In function `kerberos_kinit_password': libads/kerberos.c:80: warning: passing arg 6 of `krb5_get_init_creds_password' discards qualifiers from pointer target type Compiling utils/net_ads.c utils/net_ads.c: In function `net_ads_printer_info': utils/net_ads.c:722: warning: passing arg 4 of `ads_find_printer_on_server' discards qualifiers from pointer target type utils/net_ads.c: In function `net_ads_printer_publish': utils/net_ads.c:774: warning: assignment discards qualifiers from pointer target type utils/net_ads.c: In function `net_ads_printer_remove': utils/net_ads.c:812: warning: assignment discards qualifiers from pointer target type Compiling utils/net_cache.c utils/net_cache.c: In function `parse_timeout': utils/net_cache.c:85: warning: assignment makes pointer from integer without a cast
Re: Explaining the new SAM
At 23:21 02.10.2002 +1000, Andrew Bartlett wrote: >Gerald Carter wrote: > > > > On Wed, 2 Oct 2002, Andrew Bartlett wrote: > > > > > > This seems like a lot of duplication of code and can lead to > > > > "There's a bug in SAM1 but not SAM2". If the access checks > > > > will always be the same, why push them into the SAM module and > > > > force each write to cut-n-paste security descriptor code. > > > > > > Yes, I am worried about that a bit. The main issue is that I would like > > > a single read from LDAP - so we don't get a race there. But we could do > > > it 'after the fact', and get each module to pass up the security > > > descriptor to the SAM interface layer. > > > > Ahhhok I see now. But it still seems like a lot of duplicated > > code. > >I'm starting to agree that putting it in the interface is a 'good >thing'. If the backend wants to double-check, then that's fine, but the >intereface should be handed back a sec desc to check itself. (A SAM >that really wants to get around this can return an allow-all sec desc if >it must...). This does make it harder for module writers to 'stuff up'. what's about a BOOL flag in the SAM_METHODS struct : BOOL access_check_intern; if False the interface should handle the sec_check. if True the backend will handle it. And double access check isn't a good way! (we want to handle large domains, and for this we have to be as fast as possible) > > Taking another perspective, i'm still not convinced why a security > > descriptor on each SAM object is needed. What do we gain by it > > at the cost of added complexity? > >NT allows these to be set remotely on each SAM object. In particular >the 'user cannot change password' is implemented in terms of an NT ACL >on the user in the SAM. We didn't have to store a SEC_DESC on each entry. We can use a default, but we have to be able to store it on each entry if the admin changes it explicit on the entry. > > > > So a SAM is a passdb with ACL's. What else? > > > > > > Groups and policies thown in, but it's not really meant to be that > > > > By policies you mean "rights" like "backup files" ? > >Also 'max password age' etc. > > > > massive. One step at a time and such things. Also a move to NTTIME in > > > the interfaces, and an attempt to cope with a wider scope of problems. > > > > What "wider scope of problems"? Without knowing what you are trying to > > address, it's pretty hard to comment. > >Mostly to cope with all the things that can be set over the SAMR pipe. >(most of which are above). I think we are also meddiling a little in >the LSA pipe too, which may or may not be a good thing... > >It may well make sense to store all the replication stuff in the same >backend, to avoid having to run muliple synronistation setups. (ie if >LDAP is doing all the SAM stuff, make it keep the LSA secrets too). I'm >still thinking on this stuff, but that's the kind of longer-term I'm >looking for. that would be fine:-) >Andrew Bartlett > >-- >Andrew Bartlett [EMAIL PROTECTED] >Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] >Student Network Administrator, Hawker College [EMAIL PROTECTED] >http://samba.org http://build.samba.org http://hawkerc.net metze - Stefan "metze" Metzmacher <[EMAIL PROTECTED]>
Re: Recent Upgrade to Fix SNAP Server Problem
On Thu, Oct 03, 2002 at 01:05:00AM +1000, Andrew Bartlett wrote: > Irving Carrion wrote: > > > > Greetings! > > > > We just recently upgraded from Samba 2.2.3a to 2.999+3.0cvs20 and are > > having a few problems. The "domain admin group" that used to work in > > the previous version no longer does. According to the docs > > smb.conf.5.html the command is still there and still active. Obviously > > I have missed something... can anyone relay some info my way. > > You are trusting our documentation...? To comment on this Yes, you *should* trust our documentation (I don't want Andrew to make people lose confidence in this). We put a lot of work into making the docs accurate - but only for *production* releases. That currently means we're finishing the docs for 2.2.6. In fact, missing docs are considered a show-stopper for a production release and we won't ship without them. Just to clear that up. Jeremy.
Re: [PATCH] sam backend parameter
On Wed, 2 Oct 2002 [EMAIL PROTECTED] wrote: > > The other cases for 'multiple domain' support involve the way these > > users are reflected back into unix by winbindd, which might be running > > on a system that has multiple, independent smbd instances on separate > > IPs. OK. I just caught this. One winbnidd install serving multiple smbd installations on the same host? This seems like complicating the a corner case requirement. My concern is about the ongoing maintainence and administration of the code. Code that is only understood by one person is unmaintainable code. Nothing against you mind you. If i was the only one who understand how our printer change notify code worked for example, I would argue the same point. It could also be that the only one person understands it phenomena it partly our fault as well for not digging in earlier. Water under the bridge at this point. Well work on it better in the future :-) cheers, jerry - Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org --http://www.plainjoe.org "SAMS Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
RE: Recent Upgrade to Fix SNAP Server Problem
Does anyone know what the below log means: [2002/10/02 12:44:37, 0] rpc_server/srv_util.c:get_domain_user_groups(342) get_domain_user_groups: primary gid of user [root] is not a Domain group ! get_domain_user_groups: You should fix it, NT doesn't like that Our users are unable to login now. Windows error says "Make sure your username and domain are correct" It is CORRECT. Any help highly appreciated. Thanks! IRV -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Andrew Bartlett Sent: Wednesday, October 02, 2002 11:05 AM To: Irving Carrion Cc: [EMAIL PROTECTED] Subject: Re: Recent Upgrade to Fix SNAP Server Problem Irving Carrion wrote: > > Greetings! > > We just recently upgraded from Samba 2.2.3a to 2.999+3.0cvs20 and are > having a few problems. The "domain admin group" that used to work in > the previous version no longer does. According to the docs > smb.conf.5.html the command is still there and still active. Obviously > I have missed something... can anyone relay some info my way. You are trusting our documentation...? > Also testparm has reported that I am using "wins support" and "wins > server" commands in the smb.conf file, but I am NOT. All I have is " > wins support = Yes". Known issue > Any info on the postscript error below would help but not critical at > this point. > > I'm running testparm on my smb.conf and I get the following errors: > > ///ERRORS BEGIN > Unknown parameter encountered: "domain admin group" > Ignoring unknown parameter "domain admin group" See smbgroupedit. It handles this stuff for now. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: [PATCH] sam backend parameter
On Thu, Oct 03, 2002 at 12:30:30AM +1000, Andrew Bartlett wrote: > Gerald Carter wrote: > > > > On Tue, 1 Oct 2002, Eddie Lania wrote: > > > > > Like I've said, I'm not a developer, but maybe the "multiple domain > > > support" parameter could be extended with the backend method? Like this: > > > > > > "multiple domain support = DOMA:backendA, DOMB:backendB, etc" > > > > Can someone please explain the purpose of supporting accounts from > > different domains in a single SAM ? Why would we ever want to do > > this? > > No, the idea is that one SAM backend would know about only one domain, > but that we could have multiple domains, each with their own backend. > For smbd it doesn't make much sense, except that I was looking at > handling 'builtin' stuff by abstraction into a separate 'domain' this > way. (I favor putting special cases into modules, rather than in > interfaces). > > The other cases for 'multiple domain' support involve the way these > users are reflected back into unix by winbindd, which might be running > on a system that has multiple, independent smbd instances on separate > IPs. Use vmware or virtual hosts for this. It's not something that Samba needs to be architectured around. > In any case, the syntax will need to get much clearer if this is to stay > around for long. (idra seems determined to kill it). Me too. This is too ugly to live. I also don't agree that BUILTIN should be handled as a separate domain. The multiple domain stuff really has to go, as Gerry says, why would anyone want to do that ? Jeremy.
smbclient bug in 2.2.5
I think I've found a bug in the smbclient program in 2.2.5. Smbclient hard-codes the name_type to 0x20 (File Server) for all netbios queries, but calling 'smbclient -M machine' should use a name_type of 0x03 (Messenger) instead. When sending a message to a machine, it is not necessary for the machine to be running file sharing. Our client machines have file sharing turned off and do not register 0x20 with the WINS server. I'm not sure when this behavior changed, but the smbclient program from samba 2.0.10 works correctly. Thanks, Andy
Samba 3.0 Alpha 21 cvs + LDAP
I can't get smbd to bind with the LDAP server to authenticate. Configured using the following: ./configure --prefix=/usr --localstatedir=/var --with-configdir=/etc/samba --with-fhs --with-swatdir=/usr/share/swat --enable-cups --with-pam --with-pam_smbpass --with-ldapsam --with-syslog --with-acl-support testparm show the following: testparm Load smb config files from /etc/samba/smb.conf Processing section "[homes]" Processing section "[printers]" Processing section "[home]" Loaded services file OK. Press enter to see a dump of your service definitions # Global parameters [global] workgroup = AVLSI netbios name = DEVEL netbios aliases = Devel obey pam restrictions = Yes smb passwd file = passdb backend = ldapsam, ldap://ldap.example.com pam password change = Yes passwd program = /usr/sbin/ldappasswd unix password sync = Yes lanman auth = No log level = 3 syslog = 3 log file = /var/log/samba name resolve order = dns wins bcast time server = Yes logon path = \\home\home\user\%U\WINDOWS logon drive = U: logon home = \\home\home\user\%U domain logons = Yes domain master = True dns proxy = No wins support = Yes ldap suffix = dc=example,dc=com ldap machine suffix = ou=System,dc=example,dc=com ldap user suffix = ou=People,dc=example,dc=com ldap admin dn = cn=Manager,dc=example,dc=com ldap ssl = start tls ldap passwd sync = Yes oplocks = No level2 oplocks = No [homes] comment = Home Directories read only = No browseable = No [printers] comment = All Printers path = /var/spool/samba printable = Yes browseable = No [home] comment = Home Directories path = /home/ guest ok = Yes hosts allow = 10.0.0.0/255.255.0.0 I've run smbpasswd -w password which works and then tried smbpasswd root with the following message: smbpasswd root New SMB password: Retype new SMB password: Loading ldap://ldap.example.com failed! Failed to find entry for user root. Failed to modify password entry for user root also setting the logging to 0 or 1 or 3 seems to make no difference. I must be missing some little detail here because others appear to be able to set this up. Please help. Thank you. Dennis
Re: Recent Upgrade to Fix SNAP Server Problem
Irving Carrion wrote: > > Greetings! > > We just recently upgraded from Samba 2.2.3a to 2.999+3.0cvs20 and are > having a few problems. The "domain admin group" that used to work in > the previous version no longer does. According to the docs > smb.conf.5.html the command is still there and still active. Obviously > I have missed something... can anyone relay some info my way. You are trusting our documentation...? > Also testparm has reported that I am using "wins support" and "wins > server" commands in the smb.conf file, but I am NOT. All I have is " > wins support = Yes". Known issue > Any info on the postscript error below would help but not critical at > this point. > > I'm running testparm on my smb.conf and I get the following errors: > > ///ERRORS BEGIN > Unknown parameter encountered: "domain admin group" > Ignoring unknown parameter "domain admin group" See smbgroupedit. It handles this stuff for now. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Recent Upgrade to Fix SNAP Server Problem
Greetings! We just recently upgraded from Samba 2.2.3a to 2.999+3.0cvs20 and are having a few problems. The "domain admin group" that used to work in the previous version no longer does. According to the docs smb.conf.5.html the command is still there and still active. Obviously I have missed something... can anyone relay some info my way. Also testparm has reported that I am using "wins support" and "wins server" commands in the smb.conf file, but I am NOT. All I have is " wins support = Yes". Any info on the postscript error below would help but not critical at this point. I'm running testparm on my smb.conf and I get the following errors: ///ERRORS BEGIN Unknown parameter encountered: "domain admin group" Ignoring unknown parameter "domain admin group" WARNING: The "postscript" option is deprecated ERROR: both 'wins support = true' and 'wins server = ' cannot be set in the smb.conf file. nmbd will abort with this setting. ///ERRORS END Any help would be Gratefully appreciated!!! IRV
Re: [PATCH] sam backend parameter
On Wed, Oct 02, 2002 at 09:19:47AM -0500, Gerald Carter wrote about 'Re: [PATCH] sam backend parameter': > On Tue, 1 Oct 2002, Eddie Lania wrote: > > Like I've said, I'm not a developer, but maybe the "multiple domain > > support" parameter could be extended with the backend method? Like this: > > "multiple domain support = DOMA:backendA, DOMB:backendB, etc" > Can someone please explain the purpose of supporting accounts from > different domains in a single SAM ? Why would we ever want to do > this? Builtin or multi-domain DC afaik - Kai and Andrew know all the how's and why's. Jelmer -- Jelmer Vernooij <[EMAIL PROTECTED]> Pending (unfinished) patches http://samba.org/~jelmer/diffs.php
Re: [PATCH] sam backend parameter
Gerald Carter wrote: > > On Tue, 1 Oct 2002, Eddie Lania wrote: > > > Like I've said, I'm not a developer, but maybe the "multiple domain > > support" parameter could be extended with the backend method? Like this: > > > > "multiple domain support = DOMA:backendA, DOMB:backendB, etc" > > Can someone please explain the purpose of supporting accounts from > different domains in a single SAM ? Why would we ever want to do > this? No, the idea is that one SAM backend would know about only one domain, but that we could have multiple domains, each with their own backend. For smbd it doesn't make much sense, except that I was looking at handling 'builtin' stuff by abstraction into a separate 'domain' this way. (I favor putting special cases into modules, rather than in interfaces). The other cases for 'multiple domain' support involve the way these users are reflected back into unix by winbindd, which might be running on a system that has multiple, independent smbd instances on separate IPs. In any case, the syntax will need to get much clearer if this is to stay around for long. (idra seems determined to kill it). Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: register_message_flags: tdb_fetch failed
On Tue, 1 Oct 2002, Eddie Lania wrote: > Does somebody knows what is causing this problem? > > [2002/10/01 09:32:28, 1, effective(500, 500), real(0, 0)] > smbd/ipc.c:api_fd_reply(284) > api_fd_reply: INVALID PIPE HANDLE: 76e3 > [2002/10/01 09:32:30, 1, effective(500, 500), real(0, 0)] > smbd/service.c:make_connection_snum(681) > 192.168.168.35 (192.168.168.35) connect to service eddie initially as user > eddie (uid=500, gid=500) (pid 30099) > [2002/10/01 09:32:44, 1, effective(0, 0), real(0, 0)] > smbd/service.c:close_cnum(852) > 192.168.168.35 (192.168.168.35) closed connection to service eddie > [2002/10/01 09:39:29, 0, effective(0, 0), real(0, 0)] > lib/util_sock.c:read_socket_data(418) > read_socket_data: recv failure for 4. Error = Connection reset by peer Have you tried removing the volatile TDB's and erstarting Samba? Just a guess cheers, jerry - Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org --http://www.plainjoe.org "SAMS Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
Re: [PATCH] sam backend parameter
On Tue, 1 Oct 2002, Eddie Lania wrote: > Like I've said, I'm not a developer, but maybe the "multiple domain > support" parameter could be extended with the backend method? Like this: > > "multiple domain support = DOMA:backendA, DOMB:backendB, etc" Can someone please explain the purpose of supporting accounts from different domains in a single SAM ? Why would we ever want to do this? cheers, jerry - Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org --http://www.plainjoe.org "SAMS Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
Re: Explaining the new SAM
Gerald Carter wrote: > > On Wed, 2 Oct 2002, Andrew Bartlett wrote: > > > > This seems like a lot of duplication of code and can lead to > > > "There's a bug in SAM1 but not SAM2". If the access checks > > > will always be the same, why push them into the SAM module and > > > force each write to cut-n-paste security descriptor code. > > > > Yes, I am worried about that a bit. The main issue is that I would like > > a single read from LDAP - so we don't get a race there. But we could do > > it 'after the fact', and get each module to pass up the security > > descriptor to the SAM interface layer. > > Ahhhok I see now. But it still seems like a lot of duplicated > code. I'm starting to agree that putting it in the interface is a 'good thing'. If the backend wants to double-check, then that's fine, but the intereface should be handed back a sec desc to check itself. (A SAM that really wants to get around this can return an allow-all sec desc if it must...). This does make it harder for module writers to 'stuff up'. > Taking another perspective, i'm still not convinced why a security > descriptor on each SAM object is needed. What do we gain by it > at the cost of added complexity? NT allows these to be set remotely on each SAM object. In particular the 'user cannot change password' is implemented in terms of an NT ACL on the user in the SAM. > > > So a SAM is a passdb with ACL's. What else? > > > > Groups and policies thown in, but it's not really meant to be that > > By policies you mean "rights" like "backup files" ? Also 'max password age' etc. > > massive. One step at a time and such things. Also a move to NTTIME in > > the interfaces, and an attempt to cope with a wider scope of problems. > > What "wider scope of problems"? Without knowing what you are trying to > address, it's pretty hard to comment. Mostly to cope with all the things that can be set over the SAMR pipe. (most of which are above). I think we are also meddiling a little in the LSA pipe too, which may or may not be a good thing... It may well make sense to store all the replication stuff in the same backend, to avoid having to run muliple synronistation setups. (ie if LDAP is doing all the SAM stuff, make it keep the LSA secrets too). I'm still thinking on this stuff, but that's the kind of longer-term I'm looking for. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Re: DatabaseFS VFS module
On Tue, 1 Oct 2002, Eric Lorimer wrote: > I don't have a problem if someone wants to include this in > examples/VFS. I'll try to keep the web site updated as often > as possible, though. Eric, I would rather keep it at your site for the simple reason of maintaince. I did however place a copy of yoru annonucement mail in the README.OtherModules file. This way, you don't have to wait on us to integrate patches you send. :-) cheers, jerry - Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org --http://www.plainjoe.org "SAMS Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
Re: Explaining the new SAM
On Wed, 2 Oct 2002, Andrew Bartlett wrote: > > This seems like a lot of duplication of code and can lead to > > "There's a bug in SAM1 but not SAM2". If the access checks > > will always be the same, why push them into the SAM module and > > force each write to cut-n-paste security descriptor code. > > Yes, I am worried about that a bit. The main issue is that I would like > a single read from LDAP - so we don't get a race there. But we could do > it 'after the fact', and get each module to pass up the security > descriptor to the SAM interface layer. Ahhhok I see now. But it still seems like a lot of duplicated code. Taking another perspective, i'm still not convinced why a security descriptor on each SAM object is needed. What do we gain by it at the cost of added complexity? > > So a SAM is a passdb with ACL's. What else? > > Groups and policies thown in, but it's not really meant to be that By policies you mean "rights" like "backup files" ? > massive. One step at a time and such things. Also a move to NTTIME in > the interfaces, and an attempt to cope with a wider scope of problems. What "wider scope of problems"? Without knowing what you are trying to address, it's pretty hard to comment. > Mostly it's a rework so we could move further forward then passdb could > reasonably be streached. It sounds big, but it really isn't... cheers, jerry - Hewlett-Packard http://www.hp.com SAMBA Team http://www.samba.org --http://www.plainjoe.org "SAMS Teach Yourself Samba in 24 Hours" 2ed. ISBN 0-672-32269-2 --"I never saved anything for the swim back." Ethan Hawk in Gattaca--
usrmgr fails to get local groups?
Hello, I compiled samba from cvs this morning. Now, using usrmgr.exe (svrtools for windows NT), it is unable to find the local groups? Anyone noticed this yet? Eddie.
Re: Samba 3.0 alpha and LDAP: some questions
PINTO ELIA wrote: > > Hi all > > We are migrating from an AS/U(Advanced Server for Unix)/NT environment to > Samba/NT, using the Samba 3.0 alpha19. > We have implemented a domain with Samba acting as both PDC and BDC. Also we > use OpenLDAP as Samba backend in multimaster replication to realize the > sam syncronization between PDC and BDC. At the moment not all our > requirement are satisfied. We'd like to have your help to overcome the > obstacles. Following are the questions raised during our implementation: > > 1) Samba schema does not include the Domain groups and the > domain SID. Is it scheduled to include these in the Samba schema? I think > that is useful (no local > Secrets.tdb and group_mapping.tdb to replicate via rsync) We are activly looking at these issues, and the best way to solve them in both the long and short term. > 2) About BDC, could I update the user accounts when the PDC is > down? Is the BDC read-only like NT for the SAM? Yes, the BDC is considerd read-only. If you really have a mulimaster replication scheme, then you could 'flip' the BDC up to a PDC for that period, but windows clients won't attempt to send updates to a BDC. pdbedit/smbpasswd etc don't actually know about this, so would attempt to update regardless. > 3) We have dumped the Sam database from the AS/U server to > fully migrate our environment to Samba. We've seen that some machine > accounts and interdomain trust account have the lanman password length = 0, > lm password null and ntpasswd not null. This is correct. Samba only sets both for historical reasons. It sets them to the same value too... > How the Samba would interpret that behaviors? That means we > should put "NO PASSWORDxxx...", or "disabled" for those accounts? I have > also found that after removing lmPassword from the SAMBA LDAP interdomain > trust account (with ldapmodify ) the trust seems to work but is this the > right thing to do ? In Samba 3.0, this should be fine. I put a bit of work into ensuring that 'magic' tests on the value on the LM password no longer apply. > 4) What does mean the acctFlag for "MNS logon account" ? No idea... > We hope you could kindly give us some suggestion. At the end of our project > we'll like to public our experiences if could be contribute to the Samba > community. I look forward to hearing how you go. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
Samba 3.0a20+LDAP-backend group-builit and mapping questions
I'm been playing with the groups and LDAP (passdb backend) and found two problems: 1. When -as local admin in a XP domain member ws-, from the administrative tools (control pannel) I select "add a group" an ldap search is performed, like: > ldapsam_search_one_user: searching > for:[(&(uid=Administrators)(objectclass=sambaAccount))] I have the groups defined in samba-pdc and several maps also: > bin/smbgroupedit -l | grep -A 1 Admin > Administrators > SID : S-1-5-32-544 > -- > Domain Admins > SID : S-1-5-21-298858960-1863792627-3661451959-512 > - and the groups don't be found at all (nor builtin nor defined). Of course, if I provide an user present in the ldap base, is added perfectly. This issue is only with (domain, non-local) groups. 2. After intend to add a new group in XP from the domain, all the database are searched: > base="o=smb,dc=unav,dc=es" scope=2 filter="(&(uid=*)(objectClass=sambaAccount))" > ... and enumerated: > [2002/10/03 00:27:05, 2] passdb/pdb_ldap.c:ldapsam_setsampwent(1218) > ldapsam_setsampwent: 27303 entries in the base! (BTW: I selected "Group" no "Group and users" in the object class to search from XP). Is this a know issue? if so, Some link? Note: the PDC has pam and nsswitch for unix accounting. Thanks, Ignacio -- Ignacio Coupeau, Ph.D. e-mail: [EMAIL PROTECTED] CTI, Director fax:948 425619 University of Navarra voice: 948 425600 Pamplona, SPAINhttp://www.unav.es/cti/
Samba 3.0 alpha and LDAP: some questions
Hi all We are migrating from an AS/U(Advanced Server for Unix)/NT environment to Samba/NT, using the Samba 3.0 alpha19. We have implemented a domain with Samba acting as both PDC and BDC. Also we use OpenLDAP as Samba backend in multimaster replication to realize the sam syncronization between PDC and BDC. At the moment not all our requirement are satisfied. We'd like to have your help to overcome the obstacles. Following are the questions raised during our implementation: 1) Samba schema does not include the Domain groups and the domain SID. Is it scheduled to include these in the Samba schema? I think that is useful (no local Secrets.tdb and group_mapping.tdb to replicate via rsync) 2) About BDC, could I update the user accounts when the PDC is down? Is the BDC read-only like NT for the SAM? 3) We have dumped the Sam database from the AS/U server to fully migrate our environment to Samba. We've seen that some machine accounts and interdomain trust account have the lanman password length = 0, lm password null and ntpasswd not null. How the Samba would interpret that behaviors? That means we should put "NO PASSWORDxxx...", or "disabled" for those accounts? I have also found that after removing lmPassword from the SAMBA LDAP interdomain trust account (with ldapmodify ) the trust seems to work but is this the right thing to do ? 4) What does mean the acctFlag for "MNS logon account" ? We hope you could kindly give us some suggestion. At the end of our project we'll like to public our experiences if could be contribute to the Samba community.
Testing and the 'new SAM'
Some more jottings on bits of the 'new SAM' stuff. Testing === Testing is vital in any piece of software, and Samba is certainly no exception. In designing this new subsystem, we have taken care to ensure it is easily tested, independent of outside protocols. To this end, Jelmer has constructed 'samtest'. This utility (see torture/samtest.c) is structured like rpcclient, but instead operates on the SAM subsystem. It creates a 'custom' SAM context, that may be distinct from the default values used by the rest of the system, and can load a separate configuration file. A small number of commands are currently implemented, but these have already proved vital in testing. I expect SAM module authors will find it particularly valuable. Example useage: bin/samtest > context ads:ldap://192.168.1.96 (this loads a new context, using the new ADS module. The paramater is the 'location' of the ldap server) > lookup_name DOMAIN abartlet (returns a sid). > quit Because the 'new SAM' is NT ACL based, there will be a command to specify an arbitrary NT ACL, but for now it uses 'system' by default. sam_ads === This is the first of the SAM modules to be committed to the tree - mainly because I needed to coordinate work with metze (who authored most of it). This module aims to use Samba's libads code to provide an Active Directory LDAP client, suitable for use on a mixed-mode DC. While it is currently being tested against Win2k servers (with a password in the smb.conf file) it is expected to eventually use a (possibly modified) OpenLDAP server. We hope that this will assist in the construction of an Samba AD DC. We also intend to construct a Samba 2.2/3.0 compatible ldap module, again using libads code. Andrew Bartlett -- Andrew Bartlett [EMAIL PROTECTED] Manager, Authentication Subsystems, Samba Team [EMAIL PROTECTED] Student Network Administrator, Hawker College [EMAIL PROTECTED] http://samba.org http://build.samba.org http://hawkerc.net
fsp->modified - What's it for ?
I am using samba-2.2.1a I was wondering what is the usage of the field fsp->modified. I saw it is changed to True when I write to a file, but does not change when I truncate a file. Moreover - It is never checked for its content. Thanks, Nir
Compile warnings.
Compiled from cvs on 2 October 2002 at 09:48h CET. RedHat 7.0 kernel, 2.2.19-7.0.16 openldap-2.0.21-0.7.1 nss_ldap-189-1.7 krb5-libs-1.2.2-14 krb5-devel-1.2.2-14 gcc version 2.96 2731 (Red Hat Linux 7.1 2.96-85) Configure options used: --sbindir=/usr/local/samba/bin \ --with-logfilebase=/var/log/samba \ --with-krb5=/usr/kerberos \ --with-smbmount \ --with-pam \ --with-acl-support Warnings: Compiling smbd/mangle_hash2.c smbd/mangle_hash2.c: In function `cache_insert': smbd/mangle_hash2.c:172: warning: assignment makes pointer from integer without a cast smbd/mangle_hash2.c: In function `is_mangled': smbd/mangle_hash2.c:263: warning: initialization makes pointer from integer without a cast Compiling libsmb/clispnego.c libsmb/clispnego.c: In function `spnego_gen_negTokenTarg': libsmb/clispnego.c:330: warning: passing arg 1 of `krb5_get_ticket' discards qualifiers from pointer target type Compiling passdb/secrets.c passdb/secrets.c: In function `secrets_fetch': passdb/secrets.c:61: warning: assignment discards qualifiers from pointer target type passdb/secrets.c: In function `secrets_store': passdb/secrets.c:77: warning: assignment discards qualifiers from pointer target type passdb/secrets.c:79: warning: assignment discards qualifiers from pointer target type passdb/secrets.c: In function `secrets_delete': passdb/secrets.c:93: warning: assignment discards qualifiers from pointer target type passdb/secrets.c: In function `secrets_lock_trust_account_password': passdb/secrets.c:218: warning: passing arg 2 of `tdb_lock_bystring' discards qualifiers from pointer target type passdb/secrets.c:220: warning: passing arg 2 of `tdb_unlock_bystring' discards qualifiers from pointer target type passdb/secrets.c: In function `secrets_get_trusted_domains': passdb/secrets.c:509: warning: assignment makes pointer from integer without a cast passdb/secrets.c: In function `secrets_named_mutex': passdb/secrets.c:610: warning: passing arg 1 of `tdb_set_lock_alarm' discards qualifiers from pointer target type Compiling lib/util_str.c lib/util_str.c: In function `str_list_make': lib/util_str.c:1160: warning: passing arg 3 of `next_token' discards qualifiers from pointer target type Compiling lib/util.c lib/util.c: In function `smb_xstrndup': lib/util.c:1832: warning: initialization makes pointer from integer without a cast Compiling lib/gencache.c lib/gencache.c: In function `gencache_get': lib/gencache.c:248: warning: initialization makes pointer from integer without a cast lib/gencache.c: In function `gencache_iterate': lib/gencache.c:303: warning: assignment makes pointer from integer without a cast Compiling libads/ldap.c libads/ldap.c: In function `ads_do_paged_search': libads/ldap.c:443: warning: passing arg 2 of `str_list_copy' from incompatible pointer type libads/ldap.c: In function `ads_do_search': libads/ldap.c:669: warning: passing arg 2 of `str_list_copy' from incompatible pointer type Compiling libads/ldap_printer.c libads/ldap_printer.c: In function `ads_mod_printer_entry': libads/ldap_printer.c:80: warning: passing arg 4 of `ads_mod_strlist' from incompatible pointer type libads/ldap_printer.c:96: warning: passing arg 4 of `ads_mod_strlist' from incompatible pointer type libads/ldap_printer.c:99: warning: passing arg 4 of `ads_mod_strlist' from incompatible pointer type Compiling libads/kerberos.c libads/kerberos.c: In function `kerberos_kinit_password': libads/kerberos.c:80: warning: passing arg 6 of `krb5_get_init_creds_password' discards qualifiers from pointer target type Compiling utils/net_ads.c utils/net_ads.c: In function `net_ads_printer_info': utils/net_ads.c:722: warning: passing arg 4 of `ads_find_printer_on_server' discards qualifiers from pointer target type utils/net_ads.c: In function `net_ads_printer_publish': utils/net_ads.c:774: warning: assignment discards qualifiers from pointer target type utils/net_ads.c: In function `net_ads_printer_remove': utils/net_ads.c:812: warning: assignment discards qualifiers from pointer target type Compiling utils/net_cache.c utils/net_cache.c: In function `parse_timeout': utils/net_cache.c:85: warning: assignment makes pointer from integer without a cast
Temporary admin user
Hello, today few people of our IT staff are "admin users" in smb.conf. This is a dangerous situation, on the other side, they must be able to do things normal users can not. Because we use win98 on the clients it is not possible to switch user at runtime like its possible to do with Xp. What about the following proposal: - add a attribute to the usernames listed in "admin users". The users with this attribute are not admin by default, but are candidates - add a message type to smbcontrol to enable or disable the admin mode. Bye Andreas Dr. Andreas Moroder Sanitätsbetrieb Brixen - Azienda Sanitaria di Bressanone www.sb-brixen.it- www.as-bressanone.it
