Re: Commit my stuff to 3.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Yes, we need a simple solution, but I'm not sure there is one... Seeing all these Problems I am now not sure if removing all the dependencies on algorithmic mapping is a good idea. I'm currently looking at the code from a different perspective: All this mess came up for the vampire stuff. So, why not treat these RIDs as the exception, and really go for the algorithmic mapping as the rule. I know, I have argued very strongly against that, but it might only have been because I did not see all the consequences. The code probably would have to be cleaned up, but it might simplify a lot. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9qmykZeeQha3jd9gRAhsEAJ9qTOJb8hXCeLU5ETZr7ECHSXV2yACfVUbg 7jYK7Dp+NEsxeBCnX+G7Anc= =1hTz -END PGP SIGNATURE-
Re: Commit my stuff to 3.0?
On Mon, 2002-10-14 at 09:05, [EMAIL PROTECTED] wrote: Yes, we need a simple solution, but I'm not sure there is one... Seeing all these Problems I am now not sure if removing all the dependencies on algorithmic mapping is a good idea. I'm currently looking at the code from a different perspective: All this mess came up for the vampire stuff. So, why not treat these RIDs as the exception, and really go for the algorithmic mapping as the rule. I know, I have argued very strongly against that, but it might only have been because I did not see all the consequences. The code probably would have to be cleaned up, but it might simplify a lot. No, algorithmic mapping is only a source of problems. It is easy to implement but does not scale at all. There are no many parts in the code the assume algorithmic mapping and an idmap is all we need. Btw, this issue existed for months before the vampire (eg. cifs 2001 at least), vampire is only the last one. Simo. -- 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: Commit my stuff to 3.0?
On Sun, 13 Oct 2002, Andrew Bartlett wrote: [EMAIL PROTECTED] wrote: My solution for this is mapping users not in the 'rich' pdb backend to S-1-5-33-uid (no typo!). This is the newly created 'local unix auth'. lookupsid should return 'not mapped', as NT4 would after that look up 'local unix auth'#1c... W2k shows the SID in plain text, NT4 shows 'local unix auth\account unknown' This could have interesting security implications - becouse each fileserver will be serving rids in the same RID space, and becouse of how NT copies ACLs with a file. When you copy this file back, it's now got permissions in 'unexpected' groups. Under NT these groups would be full SIDs, so be restricted as such - but under this they would map back to gids, which have a different meaning. That is a very good point and a major objection to the S-1-5-33-uid idea. let me explain: if you copy a file with its ACL (like w2k does) between 2 samba pdc servers, and that ACL contains a S-1-5-33-uid, you end up giving access to an unknown user. S-1-5-33-uid can map to a user on domain1 and map to another user on domain2 so I propose to map the users to the normal domain SID (S-1-5-21-x-y-z) and create their accounts with the ACCOUNT_DISABLED flag. J.F.
Re: Commit my stuff to 3.0?
On Mon, Oct 14, 2002 at 10:09:36AM +0200, Jean Francois Micouleau wrote: so I propose to map the users to the normal domain SID (S-1-5-21-x-y-z) and create their accounts with the ACCOUNT_DISABLED flag. I hesitated to do that, but I also like this idea. I already implemented it for groups, so why not for users as well. Work to do :-) Volker msg03683/pgp0.pgp Description: PGP signature
Re: Commit my stuff to 3.0?
On Mon, 2002-10-14 at 11:54, Volker Lendecke wrote: On Mon, Oct 14, 2002 at 10:09:36AM +0200, Jean Francois Micouleau wrote: so I propose to map the users to the normal domain SID (S-1-5-21-x-y-z) and create their accounts with the ACCOUNT_DISABLED flag. I hesitated to do that, but I also like this idea. I already implemented it for groups, so why not for users as well. Work to do :-) that's the way to go. simo. -- 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: Commit my stuff to 3.0?
On Sun, 2002-10-13 at 15:43, Andrew Bartlett wrote: Well, we operate in 2 fundementally different modes: Winbind based users are fixed in SID, and we set the UID/GID. Unix based users are fixed in uid/gid and we allocate the SID. I think this is what metze was meaning. but it is the wrong approach imho, we should really push for winbind, however when for any reason winbind is not available, we should still use idmap to solve sids-uids only the admin will be forced to do the mapping by hand with a tool like smbgroupmapping that currently we use for groups. I really think that until the admin does not map the suers, the unmapped uids shuld simply not be mapped, and an error sent into the log (we may also think of an automatic mapping for NAS products, and lazy admins ;) Simo. -- 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: Commit my stuff to 3.0?
Simo Sorce wrote: On Sun, 2002-10-13 at 15:40, Andrew Bartlett wrote: Yep, that sounds worthwhile. We could even just make it a timeout - and finally put gencache to use :-). (mimir's generalised tdb cache). We do **not** need timeouts! remember that sid-uid mapping is written in stone, once you have done it it cannot be changed _ever_. Well I've got a funny feeling sombody will change these - and I can think it would be a really nasty thing to track down for the admin. Re-polling the server doesn't cost us much, but this is a minor matter. But to use ldap as a central storage you have to solve how to handle foreign or builtin/special SIDs! Well, I was only looking at mapping our own domain - I was thinking the rest should happend via winbind. However, it does make more sense that this is all handled in one place. I think we can deal with this. if you want it to be fast, better it stay in one place. Fine by me. -- 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: Commit my stuff to 3.0?
I really think that until the admin does not map the suers, the unmapped uids shuld simply not be mapped, and an error sent into the log that's fine. ( that was the reason I wanted to seperate the storages of the local domain stuff and the winbind domains, but it's not needed then) (we may also think of an automatic mapping for NAS products, and lazy admins ;) sounds good! maybe a switch to allow the 'add on not found' or not. It would also be nice to have SID's or uid/gid's that are explicit not mapped. maybe S-1-5-21-6456456457-75467575678567-6745754674567-677567 - (-1) uid 567567 - S-0-0 (NULL SID) to avoid question to the central idmap for unmapped id's.(for computer accounts,...) metze - Stefan metze Metzmacher [EMAIL PROTECTED]
Re: Commit my stuff to 3.0?
At 15:57 13.10.2002 +0200, Simo Sorce wrote: But to use ldap as a central storage you have to solve how to handle foreign or builtin/special SIDs! yes the builtin SID's should only be shared between DC's. maybe we shouldn't do lookup's on the central idmap that contain builtin SID's and write unmapped in our local idmap( if domain logons = no). 1.so if we lookup BUILTIN SID S-1-5-32-545 and didn't find it in the local idmap: we should write it to our local idmap and mark it as unmapped. it will later possible for the admin to manual map it via a tool like smbgroupedit. 2. if we lookup a uid 5676 and didn't find it in our local idmap, we look it up in trhe central idmap. if it is mapped to a builtin sid, we should write it to our local idmap with unmapped. it will later possible for the admin to manual map it via a tool like smbgroupedit. 3. if we have domain logons = yes, we should skip the 1. and 2. Well, I was only looking at mapping our own domain - I was thinking the rest should happend via winbind. However, it does make more sense that this is all handled in one place. I think we can deal with this. if you want it to be fast, better it stay in one place. Simo. metze - Stefan metze Metzmacher [EMAIL PROTECTED]
Re: Commit my stuff to 3.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I know why 'only algorithmic' mapping is a pain - we can't do migration from NT, but why is adding algorithmic RIDs a problem here? (Other than asthetics) I do not really like the idea of mixing two approaches. Ok, you can make reasonably sure that both do not clash with a high enough algorithmic rid base. Hmm. From a functionality point of view, it is mainly asthetic. And fearing that we might miss corner cases. Not giving anything back from pdb_getsampwnam when the user is not in SAM is much more obvious than a user magically popping up. But yes, this is one of the ugliest parts of the unixsam approach. It also has implications for the 'add computer to domain' priviage. Basicly, we have to decided if unix users not in a SAM backend are in the domain. I would vote for 'NO'. The problem is that we currently allocate them a SID as if they are members of the domain. And we need to be able to preserve that allocation, even if we add them to smbpasswd - sombody could have aimed an NT backup tool at us, and we gave the OLD SID as a the owner, and when we 'restore' it's 'gone'. I would not see this as a problem. The same happens if you delete a user between backup and restore. Messing with the user database kills backups even under unix most of the time. Or we have a domain user, who owns files on a workstation. This user's smbpasswd record is deleted - should we no longer map that SID to the users unix name? (Quite possibly the answer is yes). Should users not in smbpasswd be mapped uid-sid-name at all? Currently we do, and some NAS products use this behaviour. My solution for this is mapping users not in the 'rich' pdb backend to S-1-5-33-uid (no typo!). This is the newly created 'local unix auth'. lookupsid should return 'not mapped', as NT4 would after that look up 'local unix auth'#1c... W2k shows the SID in plain text, NT4 shows 'local unix auth\account unknown' We have many of these problems already, but they get worse when allocated RIDs are the norm, rather then the exception. Perhaps we should move SID-uid and uid-SID stuff into a seperate module? This was somthing we were looking at for the 'new SAM', but maybe we need it sooner. (It is not dependent on the rest of the work). I remember the word SURS ;-) I think this would not help. We will never be perfect NT, we will always have rough edges. But at least if the behaviour is known and documented, I would be happy. I need to *explain* that stuff to people sitting in courses. For this simplicity is really important. I think this is one of the 'not like NT, but what admin expects' things - and I agree. Possible make groups 100 'aliases' by default, but that's minor. Ok, thanks. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9qSSdZeeQha3jd9gRAkK8AJwJAmUZEeOo1k4u9jvQJMtLXovWsQCfVA9u 0G+zQs04cxXKep1s086xxxU= =D7mS -END PGP SIGNATURE-
Re: Commit my stuff to 3.0?
[EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I know why 'only algorithmic' mapping is a pain - we can't do migration from NT, but why is adding algorithmic RIDs a problem here? (Other than asthetics) I do not really like the idea of mixing two approaches. Ok, you can make reasonably sure that both do not clash with a high enough algorithmic rid base. Hmm. From a functionality point of view, it is mainly asthetic. And fearing that we might miss corner cases. Not giving anything back from pdb_getsampwnam when the user is not in SAM is much more obvious than a user magically popping up. But yes, this is one of the ugliest parts of the unixsam approach. It also has implications for the 'add computer to domain' priviage. Basicly, we have to decided if unix users not in a SAM backend are in the domain. I would vote for 'NO'. My problem with this is the behaviour change - suddenly these things that did work won't, and the need for a uid-SID for more than just smbpasswd users. For example, to construct a meaninful NT_TOKEN, we really need a uid-sid mapping for: force user force group guest account any secruity=share user And I think we should always have an account mapping onto the 500 and 501, administrator and guest. The problem is that we currently allocate them a SID as if they are members of the domain. And we need to be able to preserve that allocation, even if we add them to smbpasswd - sombody could have aimed an NT backup tool at us, and we gave the OLD SID as a the owner, and when we 'restore' it's 'gone'. I would not see this as a problem. The same happens if you delete a user between backup and restore. Messing with the user database kills backups even under unix most of the time. My worry is NAS stuff, and fileservers. When an admin adds a password, I'm not sure that they expect a change in SID... Or we have a domain user, who owns files on a workstation. This user's smbpasswd record is deleted - should we no longer map that SID to the users unix name? (Quite possibly the answer is yes). Should users not in smbpasswd be mapped uid-sid-name at all? Currently we do, and some NAS products use this behaviour. My solution for this is mapping users not in the 'rich' pdb backend to S-1-5-33-uid (no typo!). This is the newly created 'local unix auth'. lookupsid should return 'not mapped', as NT4 would after that look up 'local unix auth'#1c... W2k shows the SID in plain text, NT4 shows 'local unix auth\account unknown' This could have interesting security implications - becouse each fileserver will be serving rids in the same RID space, and becouse of how NT copies ACLs with a file. When you copy this file back, it's now got permissions in 'unexpected' groups. Under NT these groups would be full SIDs, so be restricted as such - but under this they would map back to gids, which have a different meaning. We have many of these problems already, but they get worse when allocated RIDs are the norm, rather then the exception. Perhaps we should move SID-uid and uid-SID stuff into a seperate module? This was somthing we were looking at for the 'new SAM', but maybe we need it sooner. (It is not dependent on the rest of the work). I remember the word SURS ;-) I think this would not help. We will never be perfect NT, we will always have rough edges. But at least if the behaviour is known and documented, I would be happy. I need to *explain* that stuff to people sitting in courses. For this simplicity is really important. Yes, we need a simple solution, but I'm not sure there is one... 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: Commit my stuff to 3.0?
We have many of these problems already, but they get worse when allocated RIDs are the norm, rather then the exception. Perhaps we should move SID-uid and uid-SID stuff into a seperate module? This was somthing we were looking at for the 'new SAM', but maybe we need it sooner. (It is not dependent on the rest of the work). I remember the word SURS ;-) I think this would not help. We will never be perfect NT, we will always have rough edges. But at least if the behaviour is known and documented, I would be happy. I need to *explain* that stuff to people sitting in courses. For this simplicity is really important. Yes, we need a simple solution, but I'm not sure there is one... Isn't idmap the right place to go? -- 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: Commit my stuff to 3.0?
Simo Sorce wrote: We have many of these problems already, but they get worse when allocated RIDs are the norm, rather then the exception. Perhaps we should move SID-uid and uid-SID stuff into a seperate module? This was somthing we were looking at for the 'new SAM', but maybe we need it sooner. (It is not dependent on the rest of the work). I remember the word SURS ;-) I think this would not help. We will never be perfect NT, we will always have rough edges. But at least if the behaviour is known and documented, I would be happy. I need to *explain* that stuff to people sitting in courses. For this simplicity is really important. Yes, we need a simple solution, but I'm not sure there is one... Isn't idmap the right place to go? I think so. And I think we can construct one that makes sense for admins. For example, we could contstruct an LDAP based one that uses the uidNumber on the user's LDAP record. We might end up doing this via the passdb interface (despite the fact I was really hoping to move unix stuff out of there) becouse I found the performance issues surrounding the current stuff to be problematic. :-( Whatever we do, uid-sid and sid-uid needs to be a single lookup. idra: you proposed (and even added) these to the passdb API a little while back. Do you think that's still a viable solution? If we implement the 'ldap trust uids' thing (stops Get_Pwnam() inside ldap) then this would certainly scale much better than existing 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
Re: Commit my stuff to 3.0?
I think idmap is the right place. we should move it from nsswitch to an own directory and make it plugable. (See Roadmap of 3_0: it is needed) And let it map sid - u/gids and u/gids - sid. Maybe let it hold two contexts: 1. for all trusted domains (and our domain if we are a member server) uses winbind uid = winbind gid = to export mapping to unix (nss_winbind) and samba 2. for our local sam (witch is also the domain sam if we are a DC) uses idmap uid = idmap gid = to export mappings to samba (and maybe later also to unix via winbind) metze - Stefan metze Metzmacher [EMAIL PROTECTED]
Re: Commit my stuff to 3.0?
On Sun, 2002-10-13 at 15:13, Stefan (metze) Metzmacher wrote: I think idmap is the right place. we should move it from nsswitch to an own directory and make it plugable. (See Roadmap of 3_0: it is needed) I'm not sure we need it to be pluggable, please explain the benefits. And let it map sid - u/gids and u/gids - sid. Maybe let it hold two contexts: why?? 1. for all trusted domains (and our domain if we are a member server) uses winbind uid = winbind gid = to export mapping to unix (nss_winbind) and samba 2. for our local sam (witch is also the domain sam if we are a DC) uses idmap uid = idmap gid = to export mappings to samba (and maybe later also to unix via winbind) Makes no sense, we need only a single idmap that handles all sid-[u,g]id [u,g]id-sid, splitting it into pieces is the most wrong thing we may do. Simo. -- 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: Commit my stuff to 3.0?
Simo Sorce wrote: On Sun, 2002-10-13 at 14:58, Andrew Bartlett wrote: Simo Sorce wrote: Isn't idmap the right place to go? I think so. And I think we can construct one that makes sense for admins. For example, we could contstruct an LDAP based one that uses the uidNumber on the user's LDAP record. I would only ask you to take in account we must have a generalized way to do it that does not rely on ldap, but can use different methods. Yep. I just know the LDAP requirements fairly well, but they are just an example. We might end up doing this via the passdb interface (despite the fact I was really hoping to move unix stuff out of there) becouse I found the performance issues surrounding the current stuff to be problematic. :-( can you explain, this phrasing is criptic to me. We have performance issues with the current way we do this. One way to solve this is to push all of this back into the pdb module, as it can perform optomisations. Whatever we do, uid-sid and sid-uid needs to be a single lookup. you mean we have to be sure we do a single query to idmap? or something else? As you mention below, these call happen a lot - the idmap should implement this in as efficient way as possible. idra: you proposed (and even added) these to the passdb API a little while back. Do you think that's still a viable solution? If we implement the 'ldap trust uids' thing (stops Get_Pwnam() inside ldap) then this would certainly scale much better than existing code. Well as I said before we should make a generalized api, and not to be forced to use ldap. Yesp. About trusting the storage I see no problems, in the case of ldap you may use it as idmap storage and implicitly trust it. But user account lookup is a minor issue imho, I do not mind if 2 calls are made (one to retrieve the account and one to retrieve the mapping), if you can optimize, then better for you. What we stress idmap with is really file system acces check and ACL handling, so it need to be *fast* (and I'm not sure ldap is the right place for that in this regard). Yes, I've noticed this. 'hide unreadable' is unusable on an ldap backend at the moment :-(. I would like to use an internal tdb to do that, the fact that the api currently have the uid-sid dis-uid call is because at time we had alghorithmic rid mapping and in the move towards free sid mapping it was an easy place to do so (and make you easy to optimize things with ldap). However in case of ldap, I would like to see a different approach for speed, I woul like to see a way to use the tdb to read mappings, and a slow path in case we set a new mapping and have ldap, in this case we may set the map in ldap, and then cache it again in tdb to handle retrievals, so that only writes are slow. Yep, that sounds worthwhile. We could even just make it a timeout - and finally put gencache to use :-). (mimir's generalised tdb cache). But to use ldap as a central storage you have to solve how to handle foreign or builtin/special SIDs! Well, I was only looking at mapping our own domain - I was thinking the rest should happend via winbind. However, it does make more sense that this is all handled in one place. I think we can deal with this. 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: Commit my stuff to 3.0?
On Sun, 2002-10-13 at 14:58, Andrew Bartlett wrote: Simo Sorce wrote: Isn't idmap the right place to go? I think so. And I think we can construct one that makes sense for admins. For example, we could contstruct an LDAP based one that uses the uidNumber on the user's LDAP record. I would only ask you to take in account we must have a generalized way to do it that does not rely on ldap, but can use different methods. We might end up doing this via the passdb interface (despite the fact I was really hoping to move unix stuff out of there) becouse I found the performance issues surrounding the current stuff to be problematic. :-( can you explain, this phrasing is criptic to me. Whatever we do, uid-sid and sid-uid needs to be a single lookup. you mean we have to be sure we do a single query to idmap? or something else? idra: you proposed (and even added) these to the passdb API a little while back. Do you think that's still a viable solution? If we implement the 'ldap trust uids' thing (stops Get_Pwnam() inside ldap) then this would certainly scale much better than existing code. Well as I said before we should make a generalized api, and not to be forced to use ldap. About trusting the storage I see no problems, in the case of ldap you may use it as idmap storage and implicitly trust it. But user account lookup is a minor issue imho, I do not mind if 2 calls are made (one to retrieve the account and one to retrieve the mapping), if you can optimize, then better for you. What we stress idmap with is really file system acces check and ACL handling, so it need to be *fast* (and I'm not sure ldap is the right place for that in this regard). I would like to use an internal tdb to do that, the fact that the api currently have the uid-sid dis-uid call is because at time we had alghorithmic rid mapping and in the move towards free sid mapping it was an easy place to do so (and make you easy to optimize things with ldap). However in case of ldap, I would like to see a different approach for speed, I woul like to see a way to use the tdb to read mappings, and a slow path in case we set a new mapping and have ldap, in this case we may set the map in ldap, and then cache it again in tdb to handle retrievals, so that only writes are slow. But to use ldap as a central storage you have to solve how to handle foreign or builtin/special SIDs! Simo. -- 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: Commit my stuff to 3.0?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Discussion moved to samba-technical. Instead of just doing a pdb_getsampwnam() on the name from pass struct, I would prefer that we instead change the callers. Most of the callers can be changed to do the pdb_getsampwnam() instead of Get_Pwnam(), now that we have unixsam giving us access to all users. (This is why we didn't do this before). To be honest I would like to get rid of the necessity of unixsam for encrypted passwords. One case where this breaks: You want a workstation to join your domain. You do not want to use 'add user script', so you add the wks account to /etc/passwd. _api_samr_create_user says user exists, and after that set_userinfo creates the account in passdb. And boom, you again have algorithmic mapping in your rich passdb backend. I am not sure if metze's new passdb code covers this case, but there are so many cases like this where pdb_getsampwnam succeeding just from unixsam is not transparent enough for the caller. Given that we need passdb and groups in 3.0, I woud support merging it in there. In particualar this should simplify greatly the 'name - sid' and 'sid - name' code. (Add calls for these to the interface). If I started to rewrite the group mapping API, I would like to remove the enumgroups call. This is just too ugly for large numbers of groups. And people *will* use lots of groups, especially as we do not have support for nested groups. And when automagically creating group mappings, I would like to create them as domain groups and not as aliases. I think this is what users would expect. It also removes the annoying messages that NT does not like aliases as a user's primary group. Volker -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Key-ID ADE377D8, Fingerprint available: phone +49 551 370 iD8DBQE9qE5PZeeQha3jd9gRAgYtAJ9WxUJ3Wzc9IVasZvuQi1vFl413qACcCAhy O+0OO6J8WTqpOxHR0F+oXm8= =+CCE -END PGP SIGNATURE-
Re: Commit my stuff to 3.0?
[EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi! Discussion moved to samba-technical. Instead of just doing a pdb_getsampwnam() on the name from pass struct, I would prefer that we instead change the callers. Most of the callers can be changed to do the pdb_getsampwnam() instead of Get_Pwnam(), now that we have unixsam giving us access to all users. (This is why we didn't do this before). To be honest I would like to get rid of the necessity of unixsam for encrypted passwords. One case where this breaks: You want a workstation to join your domain. You do not want to use 'add user script', so you add the wks account to /etc/passwd. _api_samr_create_user says user exists, and after that set_userinfo creates the account in passdb. And boom, you again have algorithmic mapping in your rich passdb backend. I know why 'only algorithmic' mapping is a pain - we can't do migration from NT, but why is adding algorithmic RIDs a problem here? (Other than asthetics) But yes, this is one of the ugliest parts of the unixsam approach. It also has implications for the 'add computer to domain' priviage. Basicly, we have to decided if unix users not in a SAM backend are in the domain. The problem is that we currently allocate them a SID as if they are members of the domain. And we need to be able to preserve that allocation, even if we add them to smbpasswd - sombody could have aimed an NT backup tool at us, and we gave the OLD SID as a the owner, and when we 'restore' it's 'gone'. Or we have a domain user, who owns files on a workstation. This user's smbpasswd record is deleted - should we no longer map that SID to the users unix name? (Quite possibly the answer is yes). Should users not in smbpasswd be mapped uid-sid-name at all? Currently we do, and some NAS products use this behaviour. Also we have things like users in NIS. Should the mapping change depending on if the NIS server is up or down? (This may be smbpasswd with unix users in NIS, or even our SAM in currently unreachable LDAP). We have many of these problems already, but they get worse when allocated RIDs are the norm, rather then the exception. Perhaps we should move SID-uid and uid-SID stuff into a seperate module? This was somthing we were looking at for the 'new SAM', but maybe we need it sooner. (It is not dependent on the rest of the work). Anyway, I'm not saying I have answers to these - but we need to make sure we can address or dismis these issues. I am not sure if metze's new passdb code covers this case, but there are so many cases like this where pdb_getsampwnam succeeding just from unixsam is not transparent enough for the caller. No, metze's code just dealt with changing values within a record. Given that we need passdb and groups in 3.0, I woud support merging it in there. In particualar this should simplify greatly the 'name - sid' and 'sid - name' code. (Add calls for these to the interface). If I started to rewrite the group mapping API, I would like to remove the enumgroups call. This is just too ugly for large numbers of groups. And people *will* use lots of groups, especially as we do not have support for nested groups. This been certainly needs work. BTW, there is a getgrouplist() call, which returns, without great expense, the list of groups a user is in. For the get_domain_user_groups(p-mem_ctx, num_gids, gids, server_info-sam_account); call in srv_netlogon_nt.c we can actually use the information in the 'server_info' struct. We have it all there already. And when automagically creating group mappings, I would like to create them as domain groups and not as aliases. I think this is what users would expect. It also removes the annoying messages that NT does not like aliases as a user's primary group. I think this is one of the 'not like NT, but what admin expects' things - and I agree. Possible make groups 100 'aliases' by default, but that's minor. 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
