Re: [Samba] primary GID based access for user in 16 supplementary groups
developers are extremely good about monitoring this forum for issues, but there tends to be so much traffic in here (asked by users and can be answered by other users) that more complex technical questions can occasionally get overlooked. Hope that helps, and good luck! Cheers, Tris. -Original Message- From: Burgess, Adam [mailto:adam.burg...@hp.com] Sent: 06 September 2013 09:27 To: Tris Mabbs; samba@lists.samba.org Subject: RE: [Samba] primary GID based access for user in 16 supplementary groups Thanks Tris. We have not seen any issue with primary group not matching file/directory group owner - but I will look out for this in future. We are using NFSv4 but as I understood it this still uses AUTH_SYS authentication method by default and this is what prevents us moving to 16 groups. We do have such memberships and struggle enough already without trying to reduce this to 15 in order to work around this particular issue. Essentially our problem generally revolves around ACLs that gives access to objects for a given group that happens to be the primary group of many accounts because there are so many accounts that must belong to it, (we are also not prepared to attempt splitting the group into multiple ones and allocating the users between them as this makes for even more management headaches doing this allocation and then having to add all of these groups to the objects ACLs). Our IDMAP backend works well - that much I am confident of. The backend is itself the Quest ID Mapper that uses Quest Authentication Services integration to AD - we are not actually using UNIX attributes directly on the AD objects but that is another story. Suffice to say that SID-UID and SID-GID mappings in both directions all seems to work correctly for all AD user/group accounts that are setup be shall we say UNIX enabled. In our UNIX environment AD is the backend for NSS (name services switch) - ie we have single identity management directory between Windows and UNIX environments (thus we can't just remove some AD memberships to suit Samba based access). There is a another problem with the Samba IDMAP operations which is not an issue of the backend but of the caching method and general SID-to-UNIX-ID lookup method. I have posted about that separately. Independent of that issue we need to know how Samba is designed to work in the case described before we can say whether Windows 7 client of Windows XP is working correctly, and then look for potential workarounds/fixes. I myself would like to see a config switch to choose between implicit UNIX PGID membership and not. SMBD should also be able to programmatically not add in an actual supplementary group membership from the UNIX security token if this is the primary GID of the account (this prevent the issue of blowing any limit). Adam -Original Message- ... -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] primary GID based access for user in 16 supplementary groups
- it is completely unified. That is all except for the UNIX PGID!!! Heh! Regarding posting my questions in the technical group I thought this was not allowed for non-samba developers, otherwise both of my current queries would already have been sent there. You have to request membership; as I understand it, if you're seen to be asking questions which need to be in the technical group then that will be granted. Or at least that's how I understand it, and that's how it's worked for me (I've got a couple of conversations going on at the moment, with some extremely helpful Samba developers, regarding decoding Kerberos PACs in particular ...). Request membership and see what happens :-) Adam Tris. -Original Message- From: Tris Mabbs [mailto:tm-samba201...@firstgrade.co.uk] Sent: 06 September 2013 10:15 To: Burgess, Adam Cc: samba@lists.samba.org Subject: RE: [Samba] primary GID based access for user in 16 supplementary groups Hiya Adam, We have not seen any issue with primary group not matching file/directory group owner - but I will look out for this in future. Yes, it was a bit of an obscure one to track down, and I'm still not convinced I've got to the bottom of it - we have a working solution now and that's where I had to stop poking around. Thought I'd mention it though in case it applied in your case. We are using NFSv4 but as I understood it this still uses AUTH_SYS authentication method by default and this is what prevents us moving to 16 groups. ... Well yes, and no. Using AUTH_SYS will trip the 16 group limit problem, yes. That's part of the definition for NFS defined in RFCsomething I can't remember - that's where the 16 group limit comes from and it's not tuneable. Were you to be using Linux, there's a magic hack which gets around this, by ignoring the group list supplied by NFS and looking up the membership for itself. Haven't played with it myself, but I believe (anecdotally) that it works well. However that's absolutely no use whatsoever to you in a Solaris environment! Where NFSv4 *does* score over the earlier versions is that you have *other* authentication methods available - you don't have to use AUTH_SYS. In particular, as you're integrating all this with AD for unified identity management, there are going to be Kerberos tickets floating around the place and you could potentially use AUTH_KRB5 instead. Bingo - problem gone. OK, so nothing in computing is ever quite that simple, but get AUTH_KRB5 working and Bingo - problem gone. So that might be a solution for you to this problem, and potentially simplify your account management as well. Essentially our problem generally revolves around ACLs that gives access to objects for a given group ... Eurgh - stop right there. ACLs - work of The Devil! :-) Potentially ACLs are going to cause you major headaches on NFS mounts anyway - The wonderful thing about standards is that there's so many to choose from; NFS ACLs are supposed to be able to be mapped to and fro versus the underlying filesystem (whatever ACL mechanism that's using); personally I've never had ACLs work correctly on NFS shares of pretty much any underlying filesystem, and also be mapped correctly on the client end. I've also not seen ACLs work consistently and reliably with Samba (and I believe there were a couple of recent threads on that exact subject in the support fora, but don't quote me on that ...). Now, since you're accessing this using Samba, and Samba works out group membership based on the AD groups and uses that primarily to control access, effectively merged with the local filesystem permissions (as I understand it - I'm not a Samba guru and could be wrong ...), you might have more luck achieving the equivalent of group-based ACLs by nested group membership in the AD groups. As you're using Quest, I don't know how well that would work - I'm afraid I've heard of Quest but never used it (just Samba/native OS support for AD integration, oh and Centrify ...). However I don't see why it *wouldn't* work. So where you use setfacl (Set F*ck-All, as I tend to think of it ... Pardon the language - really NOT a fan of ACLs, so many issues ...) to permit group write to a directory, and one of the groups happens to be users' primary GID; instead define an AD group ((Unix) Access '' resource, or some similarly descriptive name) with however Quest assigns a GID to that group, then set the group ownership on the objects to the GID of that group, then include in that group all the other groups to which you're currently granting access via ACLs. E.g.: /someshare/controlled_resource: ACLs: Grant R/W access to groups: users1 users2 ... Instead: Create AD group (Unix) Access 'controlled_resource', Assign (say) GID 1 to that group, chgrp 1 /someshare
Re: [Samba] primary GID based access for user in 16 supplementary groups
Hiya Adam, We too have had no end of problems with this sort of issue using Samba on Solaris (11 in our case) running against AD and using (predominantly) Windows 7 clients. Someone with more knowledge of the Samba internals can probably answer your questions about what is the correct behaviour, and why this is happening. However if you're like me, it's more urgent actually to have something working than to know the precise details of implementation of some rather nasty protocols ... So - my $0.02, in case it's of any use. 1. For whatever reason, Samba does not play nicely when the GID of an object does not match the account's primary GID. One easy way (we've found anyway - YMMV) to demonstrate this is to locate any $RECYCLE.BIN directory for a user, change the GID to that of another group of which the user is a member, then open the desktop Recycle Bin - you'll get a whinge about The recycle bin on \\server\path\to\$RECYCLE.BIN is corrupted. Do you want to empty the Recycle Bin for this drive? (or words to that effect). 2. Things work much more smoothly when the AD group membership for the user includes the primary GID (and that's set as the primary group name in the Unix attributes for the account). It's not a cure for all ills, but it did clear up a number of similar problems we had. 3. That, as you pointed out, may well break the Solaris internal limit of 16 groups. However, is that really a problem for you? More than 16 will break NFSv3, but if you're not using NFSv3 then the worst that will happen is you'll get whinged at at boot time and that's it. Depending on your version of Solaris, there is an internal hard-coded kernel limit; as of OpenSolaris snv_129 it was increased from 32 (the limit you may well have) to 1024, but if you're not over the limit (without including the primary GID) at 16 then 32 will easily be sufficient for you anyway. We run with set ngroups_max = 1024 in our /etc/system (not that we need that many, but ...) and things generally troll along smoothly as a result. Oh, depending (again) on which version you're running - if you've patched your Solaris systems to a stage where they use Grub, don't forget the obligatory bootadm update-archive, but I'm sure you know that already :-). 4. You've not gone into details of when (or even if) you might need to use different GIDs on directories (or files, for that matter), though you did point out that anything created will be created with the primary GID anyway. Again, I'm sure you're aware of this, but you might find setting the SGID bit on folders to be useful to force different group ownership of anything created in that directory. If, that is, you need to be able to create new filesystem objects with a group ownership of anything other than the primary GID ... 5. Are you *absolutely* sure that your idmap back-ends are doing what you thought? It may be worthwhile running wbinfo -U UID and checking the SID for that UID against AD (whoami /all |more in a CMD window is very useful in this context ...); then wbinfo -S SID and confirming that it comes back to the correct UID. We've also had some very odd behaviour where it looks as though everything is correct, but the UID is actually being mapped to a transient SID from an allocating back-end. It maps to and fro correctly, and Samba seems able (in our case) correctly to identify the user (presumably from the Kerberos tickets) when a connection is established, and so the correct UID is extracted from AD. However since that UID then maps to a transient SID when looked up (rather than the real SID which it should match), you will get all sorts of bizarre permissions behaviour. Same UID, different SID, never the 'twain shall meet ... Hopefully at least some of that may prove useful! Cheers, Tris Mabbs. -Original Message- From: Burgess, Adam [mailto:adam.burg...@hp.com] Sent: 05 September 2013 17:02 To: samba@lists.samba.org Subject: [Samba] primary GID based access for user in 16 supplementary groups We observe a difference between a Windows 7 client and Windows 2003/XP client when accessing directories that should be accessible via the UNIX accounts primary group GID. Windows client refuses access. Ignoring for now why the two different client behaviours (either some subtle difference in the requests or the way the Samba reply is dealt with) the question is what should be the correct behaviour? We are running Samba 3.6.6 on Solaris with 16 limit on supplementary group, using ADS security, Kerberos PAC based group membership resolution via winbindd IDMAP lookup to simple LDAP backend. The SIDs in the PAC which resolve to valid GIDs are just the supplementary groups that would be expected for the UNIX name services resolution for the user account. The primary GID does resolve to a valid AD group SID too but this group does not contain the AD user account as a member and so is not present in the Kerberos PAC of course. In this case the smbd establishes
Re: [Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort.
Hiya Andrew, Many thanks for the typically helpful and comprehensive reply :-) I think that's probably the right track :-) The code here is triggered when poll() indicates that the socket is readable. This socket should only be readable when a new connection is being made, and accept() should succeed. ... So, my only conclusion is that your box momentarily does not have the resources to accept the connection, and because there isn't the sleep() in the source3 code, it prints this in a loop until the resources become available. Absolutely, and on any normal Unix implementation I'd agree entirely. That sort of poll()/accept()/... code is perfectly normal and exactly what you'd expect - I've written plenty of very similar code myself over the years ... However this is Solaris :-( Caught in the act: ... 16327: pollsys(0x0809B4D0, 8, 0xFEFFDF18, 0x) = 1 16327: fd=39 ev=POLLIN|POLLHUP rev=0 16327: fd=38 ev=POLLIN|POLLHUP rev=0 16327: fd=34 ev=POLLIN|POLLHUP rev=0 16327: fd=36 ev=POLLIN|POLLHUP rev=0 16327: fd=37 ev=POLLIN|POLLHUP rev=POLLIN 16327: fd=35 ev=POLLIN|POLLHUP rev=0 16327: fd=33 ev=POLLIN|POLLHUP rev=0 16327: fd=6 ev=POLLIN|POLLHUP rev=0 16327: timeout: 59.99900 sec 16327: accept(37, 0xFEFFDDCC, 0xFEFFDDB8, SOV_DEFAULT) = 41 16327: AF_INET name = X.X.X.X port = 28986 16327: forkx(0)= 26942 16327: lwp_sigmask(SIG_SETMASK, 0x00011080, 0x, 0x, 0x) = 0xFFBFFEFF [0x] 16327: close(41) = 0 16327: pollsys(0x0809B4D0, 8, 0xFEFFDF18, 0x) = 1 16327: fd=39 ev=POLLIN|POLLHUP rev=0 16327: fd=38 ev=POLLIN|POLLHUP rev=0 16327: fd=34 ev=POLLIN|POLLHUP rev=0 16327: fd=36 ev=POLLIN|POLLHUP rev=0 16327: fd=35 ev=POLLIN|POLLHUP rev=POLLIN 16327: fd=33 ev=POLLIN|POLLHUP rev=0 16327: fd=6 ev=POLLIN|POLLHUP rev=0 16327: fd=37 ev=POLLIN|POLLHUP rev=0 16327: timeout: 44.69600 sec 16327: accept(35, 0xFEFFDDCC, 0xFEFFDDB8, SOV_DEFAULT) Err#130 ECONNABORTED ... So there's nothing odd about the poll(). Typically Solaris will flag POLLERR in revents if it's out of resources, and POLLHUP if the remote end closed the connection before it was fully established (remote NAKed, or ignored, the connection SYN; terminally low on resources at t'other end of the socket; ...). Neither is happening here which would suggest things are proceeding as normal for the connection establishment. The server darn' well shouldn't be out of any resources either. In terms of physical resources, at the point that occurred the CPUs were at 99.9% idle, there was 15Gb of free RAM (so not out of kernel memory then ...) and only a total of about 400 sockets (TCP, Unix, ...) in use across the entire system, as reported by netstat -na | wc -l - well below peak levels seen on this system. So it's going to be that hypothetical Solaris specific SO_DONT_RANDOMLY_ABORT_CONNECTIONS socket() option, isn't it :-) So could I request please, that in the source3 code, either: a. The same sleep() is added as in the source4 code; -and/or- b. If errno == ECONNABORTED then only log the error if the debug level is (substantially?) higher than zero. I think it's probably safe to assume that ECONNABORTED is generally ignoreable; for whatever reason, Solaris seems to return this at the drop of a metaphorical hat (and ignoring it on other OS' isn't going to be a problem either). Maybe the same with EAGAIN (and possibly EWOULDBLOCK), as other Ignore this unless the user REALLY wants a lot of debug output type errors? This would also seem to be common practice - a quick Google for accept() ignore ECONNABORTED comes back with a lot of results, mainly showing other open source code having been modified specifically to ignore ECONNABORTED. Cheers! Tris. -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: 29 August 2013 00:41 To: Tris Mabbs Cc: samba@lists.samba.org; samba-techni...@samba.org Subject: Re: [Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort. On Sun, 2013-08-25 at 18:50 +0100, Tris Mabbs wrote: Probably should have posted this to samba-technical in the first place, so re-posting in case anyone has any useful ideas . From: Tris Mabbs Sent: 12 August 2013 23:08 To: 'samba@lists.samba.org' Subject: Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort. Good day oh technical ones . I was running Samba 4 (client only, not using it as a DC so effectively running Samba 3 code from the Samba 4 tree) and, other than a little Gotcha! regarding decoding Kerberos PACs, it was all
Re: [Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort.
Hiya Jeremy, So your problem is the debug statement being triggered repeatedly ? Yup. Adding a sleep is (IMHO) the wrong thing to do. It has the advantage of pretty much guaranteeing the problem will go away; it has the disadvantage of blocking the thread/process. However it is what the Samba4 client code does (so a similar change to the Samba3 would be consistent; of course, so would a different change to both codebases ...). Once the accept() has failed the 'POLLIN' event should not be triggered repeatedly on the polled socket. Your truss trace doesn't show enough. Does a subsequent pollsys() keep returning fd=35 ev=POLLIN|POLLHUP rev=POLLIN after the: accept(35, 0xFEFFDDCC, 0xFEFFDDB8, SOV_DEFAULT) Err#130 ECONNABORTED Now that's a very interesting question ... OK, a quick dig around later and we get (abridged): pollsys(0x080849F0, 8, 0xFEFFDF58, 0x) = 1 fd=36 ev=POLLIN|POLLHUP rev=0 fd=35 ev=POLLIN|POLLHUP rev=0 fd=34 ev=POLLIN|POLLHUP rev=0 fd=31 ev=POLLIN|POLLHUP rev=0 fd=33 ev=POLLIN|POLLHUP rev=0 fd=32 ev=POLLIN|POLLHUP rev=POLLIN fd=6 ev=POLLIN|POLLHUP rev=0 fd=30 ev=POLLIN|POLLHUP rev=0 timeout: 32.54700 sec accept(32, 0xFEFFDE0C, 0xFEFFDDF8, SOV_DEFAULT) Err#130 ECONNABORTED ... write(8, a c c e p t : S o.., 43) = 43 pollsys(0x080849F0, 8, 0xFEFFDF58, 0x) = 1 fd=36 ev=POLLIN|POLLHUP rev=0 fd=35 ev=POLLIN|POLLHUP rev=0 fd=34 ev=POLLIN|POLLHUP rev=0 fd=31 ev=POLLIN|POLLHUP rev=POLLIN fd=33 ev=POLLIN|POLLHUP rev=0 fd=6 ev=POLLIN|POLLHUP rev=0 fd=30 ev=POLLIN|POLLHUP rev=0 fd=32 ev=POLLIN|POLLHUP rev=0 timeout: 32.54600 sec accept(31, 0xFEFFDE0C, 0xFEFFDDF8, SOV_DEFAULT) = 38 AF_INET name = X.X.X.X port = 55935 forkx(0)= 10502 ... pollsys(0x080849F0, 8, 0xFEFFDF58, 0x) = 1 fd=36 ev=POLLIN|POLLHUP rev=0 fd=35 ev=POLLIN|POLLHUP rev=0 fd=34 ev=POLLIN|POLLHUP rev=0 fd=33 ev=POLLIN|POLLHUP rev=0 fd=32 ev=POLLIN|POLLHUP rev=POLLIN fd=31 ev=POLLIN|POLLHUP rev=0 fd=6 ev=POLLIN|POLLHUP rev=0 fd=30 ev=POLLIN|POLLHUP rev=0 timeout: 31.03400 sec accept(32, 0xFEFFDE0C, 0xFEFFDDF8, SOV_DEFAULT) Err#130 ECONNABORTED ... write(8, a c c e p t : S o.., 43) = 43 Received signal #18, SIGCLD, in pollsys() [caught] siginfo: SIGCLD CLD_EXITED pid=10504 status=0x pollsys(0x080849F0, 8, 0xFEFFDF58, 0x) Err#4 EINTR fd=36 ev=POLLIN|POLLHUP rev=0 fd=35 ev=POLLIN|POLLHUP rev=0 fd=34 ev=POLLIN|POLLHUP rev=0 fd=33 ev=POLLIN|POLLHUP rev=0 fd=31 ev=POLLIN|POLLHUP rev=0 fd=6 ev=POLLIN|POLLHUP rev=0 fd=30 ev=POLLIN|POLLHUP rev=0 fd=32 ev=POLLIN|POLLHUP rev=0 timeout: 31.03200 sec So that would be a no - next poll() and there's no revent flagged on that same socket. Which would confirm your thought that sleep() is perhaps not the way to go. However I don't know the Samba code (at all!) nearly well enough to comment - that sleep() may be serving some other vital purpose under different circumstances? Either way, it would appear that my second suggestion would still be valid - only log this (and possibly a couple of other error conditions) when more debugging is enabled? Another passing thought ... That truss only captured 2 ECONNABORTED incidents - typical that nothing much happens when you're specifically looking at it. However, is it likely to be a coincidence that both were on the same socket? FD#32 happens to be bound to port 445 on one specific interface of the machine; tomorrow I might try a more extended test and poke lots of traffic at that interface (and/or might stick the socket descriptor number into the debug message) - if anything interesting presents itself (E.g., it's always the same port, or interface, ... where the problem occurs) I'll post an update saying so. Probably doesn't affect the solution, but possibly technically interesting anyway ... Many thanks, and regards, Tris. -Original Message- From: Jeremy Allison [mailto:j...@samba.org] Sent: 29 August 2013 20:52 To: Tris Mabbs Cc: 'Andrew Bartlett'; samba@lists.samba.org; samba-techni...@samba.org Subject: Re: [Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort. On Thu, Aug 29, 2013 at 10:10:38AM +0100, Tris Mabbs wrote: Hiya Andrew, Many thanks for the typically helpful and comprehensive reply :-) I think that's probably the right track :-) The code here is triggered when poll() indicates that the socket is readable. This socket should only be readable when a new connection is being made, and accept() should succeed. ... So, my only conclusion is that your box momentarily does not have the resources
Re: [Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort.
Probably should have posted this to samba-technical in the first place, so re-posting in case anyone has any useful ideas . From: Tris Mabbs Sent: 12 August 2013 23:08 To: 'samba@lists.samba.org' Subject: Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort. Good day oh technical ones . I was running Samba 4 (client only, not using it as a DC so effectively running Samba 3 code from the Samba 4 tree) and, other than a little Gotcha! regarding decoding Kerberos PACs, it was all working perfectly. Then recently I had to upgrade, to 4.2.0pre1-GIT-b505111 (I had to upgrade the OS on the server running Samba - 'twas OpenSolaris and is now Solaris 11.1) so I recompiled it all up and installed afresh (so no .tdbs from the previous installation or anything). But here's a funny thing (#2). The log file gets absolutely ridiculous numbers of messages thus: Aug 12 22:45:01 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:01.731562, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:01 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:03.556423, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:03.556688, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort And so on. These will come in spurts; there won't be any such messages for several minutes then a whole load will come along all at once. Rather like busses . It doesn't seem to be affecting the operation so far as any client is concerned. Or rather it evidently will be having some effect, but it's not a noticeable one. However it is really irritating having the system log getting filled up with all these messages! Murphy's law, of course, states that trying to catch one of these messages being created, so I can include a suitable system call trace in this message, will be impossible - there will be no such messages logged until the instant I click Send (at which point probably about half-a-dozen will be logged all at once). That does indeed seem to be the case - I've now been trying to persuade one of these, normally very regularly occurring, messages to be logged for about 20 minutes and still, stubbornly, nothing continues to happen. I will catch smbd in the act at some point though, and when I do I'll follow-up with a system call trace to show exactly what is happening when this message gets triggered. It will, of course, be something bizarrely Solaris specific (you didn't set the SO_DONT_RANDOMLY_ABORT_CONNECTIONS socket() option, did you? Tsk tsk tsk .). Cheers, Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #1 - Could not fetch trust account password for domain ....
.) is that the domain name is in mixed case. This is a hangover from the original setup of the domain on our DCs (and hence cannot be changed). However that should only possibly cause hiccups with Kerberos (with it's REALLY ANNOYING AND ANACHRONOUS in this day and age) insistence on case dependence in principal names, and it certainly isn't causing issues with any other use of Kerberos (and there's a realm mapping for both .firstgrade.co.uk and .Firstgrade.Co.UK to FIRSTGRADE.CO.UK in the /etc/krb5/krb5.conf file). So it probably isn't that, but that's the only thing I can see which might in any way be different from any other similar installation. Certainly the domain name on the Samba server is, as can be seen from the principals listed in the net ads status output, forced to lower case. So, does anyone have any thoughts about these log entries please? Many thanks, and regards, Tris. Ps. Copying this to the technical list as well as it might be more appropriately addressed in there; if the list moderator feels otherwise please feel free to block or remove this post from the technical group and leave it in the normal Samba discussion one only. From: Tris Mabbs [mailto:tm-samba201...@firstgrade.co.uk] Sent: 12 August 2013 22:46 To: 'samba@lists.samba.org' Subject: Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #1 - Could not fetch trust account password for domain Good day oh technical ones . I was running Samba 4 (client only, not using it as a DC so effectively running Samba 3 code from the Samba 4 tree) and, other than a little Gotcha! regarding decoding Kerberos PACs, it was all working perfectly. Then recently I had to upgrade, to 4.2.0pre1-GIT-b505111 (I had to upgrade the OS on the server running Samba - 'twas OpenSolaris and is now Solaris 11.1) so I recompiled it all up and installed afresh (so no .tdbs from the previous installation or anything). It's all working (well, except for the PAC issue which is still being worked on). I set the LDAP admin. Password using smbpasswd -W. Kerberos is set up fine. I'm joined to the domain and both net ads testjoin and net rpc testjoin (as well as wbinfo -t) all agree that the join is good. wbinfo -u reports my AD users; wbinfo -g reports my AD groups (with the domain prefix removed); wbinfo -U gives me the correct SID for UID . But here's a funny thing (#1) - wbinfo -S gives me a UID for SID . However it's not the same UID as, when given to wbinfo -U , would return that SID. Duh? So the mapping is only currently one way. UID-SID = OK; SID-UID = not OK (no error but allocated value not the one stored in the LDAP schema). This kinda-almost-sorta works. The most annoying symptom is that any UNC path which a workstation accesses winds up with an irritating $RECYCLE.BIN folder being created on it, which every time that UNC path is accessed results in a The recycle bin for \\server\path\to\unc\folder file:///\\server\path\to\unc\folder has become corrupted. Would you like to delete it?. I *suspect* that it may have something to do with the following messages, which get logged over and over (and over and .) together in the system log file: Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] [2013/08/12 20:38:31.381776, 0] ../source3/auth/auth_domain.c:266(domain_client_validate) Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] domain_client_validate: unable to validate password for user in domain to Domain controller PDC.MYDOMAIN. Error was NT_STATUS_NO_SUCH_USER. Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] [2013/08/12 20:38:31.382811, 0] ../source3/auth/auth_domain.c:419(check_trustdomain_security) Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] check_trustdomain_security: could not fetch trust account password for domain MYDOMAIN And no, that's not me editing out the username and domain in the second message, it is an empty username and an empty domain name. It's probably that I've been stupid and missed a configuration step. However I can't think what, and I've had a quick dig around in auth_domain.c and can't see what user (and domain) it might be failing to get from where. Plus, of course, it's pure speculation that this is causing the lack of a coherent bidirectional mapping between UIDs and SIDs . Anyway, if anyone has any helpful suggestions either to resolve, or to get to the bottom of, this little hiccup, I'd much appreciate hearing them :) Cheers folks! Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options
Re: [Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort.
performing an fstat() on it possibly isn't particularly useful (except mebbee to obtain the block size, but that's probably not going to be relevant on a socket anyway) . That's doubtless why the stat structure contains fs=BADVFS. Not any sort of problem, but curious minds wonder why the code is bothering to fstat() the logging socket . Cheers, Tris. From: Tris Mabbs [mailto:tm-samba201...@firstgrade.co.uk] Sent: 12 August 2013 23:08 To: 'samba@lists.samba.org' Subject: Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort. Good day oh technical ones . I was running Samba 4 (client only, not using it as a DC so effectively running Samba 3 code from the Samba 4 tree) and, other than a little Gotcha! regarding decoding Kerberos PACs, it was all working perfectly. Then recently I had to upgrade, to 4.2.0pre1-GIT-b505111 (I had to upgrade the OS on the server running Samba - 'twas OpenSolaris and is now Solaris 11.1) so I recompiled it all up and installed afresh (so no .tdbs from the previous installation or anything). But here's a funny thing (#2). The log file gets absolutely ridiculous numbers of messages thus: Aug 12 22:45:01 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:01.731562, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:01 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:03.556423, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:03.556688, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort And so on. These will come in spurts; there won't be any such messages for several minutes then a whole load will come along all at once. Rather like busses . It doesn't seem to be affecting the operation so far as any client is concerned. Or rather it evidently will be having some effect, but it's not a noticeable one. However it is really irritating having the system log getting filled up with all these messages! Murphy's law, of course, states that trying to catch one of these messages being created, so I can include a suitable system call trace in this message, will be impossible - there will be no such messages logged until the instant I click Send (at which point probably about half-a-dozen will be logged all at once). That does indeed seem to be the case - I've now been trying to persuade one of these, normally very regularly occurring, messages to be logged for about 20 minutes and still, stubbornly, nothing continues to happen. I will catch smbd in the act at some point though, and when I do I'll follow-up with a system call trace to show exactly what is happening when this message gets triggered. It will, of course, be something bizarrely Solaris specific (you didn't set the SO_DONT_RANDOMLY_ABORT_CONNECTIONS socket() option, did you? Tsk tsk tsk .). Cheers, Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #1 - Could not fetch trust account password for domain ....
Good day oh technical ones . I was running Samba 4 (client only, not using it as a DC so effectively running Samba 3 code from the Samba 4 tree) and, other than a little Gotcha! regarding decoding Kerberos PACs, it was all working perfectly. Then recently I had to upgrade, to 4.2.0pre1-GIT-b505111 (I had to upgrade the OS on the server running Samba - 'twas OpenSolaris and is now Solaris 11.1) so I recompiled it all up and installed afresh (so no .tdbs from the previous installation or anything). It's all working (well, except for the PAC issue which is still being worked on). I set the LDAP admin. Password using smbpasswd -W. Kerberos is set up fine. I'm joined to the domain and both net ads testjoin and net rpc testjoin (as well as wbinfo -t) all agree that the join is good. wbinfo -u reports my AD users; wbinfo -g reports my AD groups (with the domain prefix removed); wbinfo -U gives me the correct SID for UID . But here's a funny thing (#1) - wbinfo -S gives me a UID for SID . However it's not the same UID as, when given to wbinfo -U , would return that SID. Duh? So the mapping is only currently one way. UID-SID = OK; SID-UID = not OK (no error but allocated value not the one stored in the LDAP schema). This kinda-almost-sorta works. The most annoying symptom is that any UNC path which a workstation accesses winds up with an irritating $RECYCLE.BIN folder being created on it, which every time that UNC path is accessed results in a The recycle bin for \\server\path\to\unc\folder file:///\\server\path\to\unc\folder has become corrupted. Would you like to delete it?. I *suspect* that it may have something to do with the following messages, which get logged over and over (and over and .) together in the system log file: Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] [2013/08/12 20:38:31.381776, 0] ../source3/auth/auth_domain.c:266(domain_client_validate) Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] domain_client_validate: unable to validate password for user in domain to Domain controller PDC.MYDOMAIN. Error was NT_STATUS_NO_SUCH_USER. Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] [2013/08/12 20:38:31.382811, 0] ../source3/auth/auth_domain.c:419(check_trustdomain_security) Aug 12 20:38:31 Gateway smbd[22736]: [ID 702911 daemon.error] check_trustdomain_security: could not fetch trust account password for domain MYDOMAIN And no, that's not me editing out the username and domain in the second message, it is an empty username and an empty domain name. It's probably that I've been stupid and missed a configuration step. However I can't think what, and I've had a quick dig around in auth_domain.c and can't see what user (and domain) it might be failing to get from where. Plus, of course, it's pure speculation that this is causing the lack of a coherent bidirectional mapping between UIDs and SIDs . Anyway, if anyone has any helpful suggestions either to resolve, or to get to the bottom of, this little hiccup, I'd much appreciate hearing them :) Cheers folks! Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Odd Samba 4 (4.2.0pre1-GIT-b505111; actually only using client) behaviour #2 - accept: Software caused connection abort.
Good day oh technical ones . I was running Samba 4 (client only, not using it as a DC so effectively running Samba 3 code from the Samba 4 tree) and, other than a little Gotcha! regarding decoding Kerberos PACs, it was all working perfectly. Then recently I had to upgrade, to 4.2.0pre1-GIT-b505111 (I had to upgrade the OS on the server running Samba - 'twas OpenSolaris and is now Solaris 11.1) so I recompiled it all up and installed afresh (so no .tdbs from the previous installation or anything). But here's a funny thing (#2). The log file gets absolutely ridiculous numbers of messages thus: Aug 12 22:45:01 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:01.731562, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:01 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:03.556423, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] [2013/08/12 22:45:03.556688, 0] ../source3/smbd/server.c:556(smbd_accept_connection) Aug 12 22:45:03 Gateway smbd[16327]: [ID 702911 daemon.error] accept: Software caused connection abort And so on. These will come in spurts; there won't be any such messages for several minutes then a whole load will come along all at once. Rather like busses . It doesn't seem to be affecting the operation so far as any client is concerned. Or rather it evidently will be having some effect, but it's not a noticeable one. However it is really irritating having the system log getting filled up with all these messages! Murphy's law, of course, states that trying to catch one of these messages being created, so I can include a suitable system call trace in this message, will be impossible - there will be no such messages logged until the instant I click Send (at which point probably about half-a-dozen will be logged all at once). That does indeed seem to be the case - I've now been trying to persuade one of these, normally very regularly occurring, messages to be logged for about 20 minutes and still, stubbornly, nothing continues to happen. I will catch smbd in the act at some point though, and when I do I'll follow-up with a system call trace to show exactly what is happening when this message gets triggered. It will, of course, be something bizarrely Solaris specific (you didn't set the SO_DONT_RANDOMLY_ABORT_CONNECTIONS socket() option, did you? Tsk tsk tsk .). Cheers, Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
Good day, one and all ... I just had to rebuild our main Samba server (OpenSlowlaris - Slowlaris 11.11), during which I put the latest (at the time; currently 4.2.0pre1-GIT-b505111) Samba4 on there. I thought that by now that Gunther's speculative changes to improve the PAC decode might have made their way into the trunk revision - obviously I was wrong, as I'm once again getting a load of Can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL messages and a user who can't access any Samba shares. Whoops ... So as we previously discussed looking into things in more detail (specifically finding out why there is no client_principal being passed into kerberos_decode_pac()), but nothing else ever happened, is there anything I can do to assist in getting the improved PAC decoding included into the trunk revision? Whilst I can't guarantee immediate responses to any request, I'm quite happy to stick any code in anywhere you might want if you don't mind potentially waiting a day or so for the results :-) Also: I appreciate this is off-topic, but I was wondering whether anyone is interested in/would like me to open a separate thread on any of these ... Built the code, installed the code, set it up (joined the domain, etc. etc. etc. etc.). Had 2(-and-a-bit) problems (one of which I've fixed): 1. Although bin/default/source3/winbindd/idmap_ad_4.o gets built, bin/default/source3/winbindd/libidmap-ad.so doesn't, so TARGDIR/lib/idmap/ad.so doesn't get installed. No ad idmap backend; no AD UID/SID mapping; much administrator (me) confusion if said administrator is expecting AD UID/SID mapping to work ... I'd completely forgotten about this little hiccup - it's been a while since I initially shoe-horned Samba4 onto OpenSlowlaris, but fortunately I'd made a note of this in the build script I used so after 2 days of banging my head against a wall, I finally remembered to check my own darn' script and saw the comment If ''/usr/local/samba/lib/idmap/ad.so'' doesn't build and install then Bang bang bang bang ... Doh! Linked libidmap-ad.so manually and copied into /usr/local/samba/lib/idmap/ad.so and, as if by magic, my UID/SID mapping started working ... 2. net ads testjoin works; wbinfo -t works (as do wbinfo -u, wbinfo -g, ). In fact everything works (after installing ad.so!) *except* ... If I do a net rpc testjoin (and remember, wbinfo -t *does* work here) I get an error stating that it can't connect to GATEWAY (local server name) and therefore the join to the FIRSTGRADE domain isn't valid. Duh? So for some reason, net rpc testjoin is trying to connect to the local server rather than any DC for the domain. No particular reason apparent in the log files, and it doesn't seem to be affecting anything, but it is an odd disparity. Ramped up debugging but couldn't see any sensible explanation in the logs ... [3. Kinda ... Sorta ... Can't build Samba4 on Slowlaris 11.11 without complaints about no ldap_add_result_entry() support in LDAP libs! filling every log file on the system. So I kicked and forced and prodded and poked and finally managed to persuade Samba to build using OpenLDAP-2.4, which gets rid of this problem. However that involved fiddling with CPPFLAGS and LDFLAGS before calling any build scripts; it's nasty, messy and dirty - I don't approve of any solution which involves that sort of messing around (yuk). There has to be a better way ... From looking at other discussions, it seems Samba4 as a DC isn't supported (yet?) using OpenLDAP, but might it be worthwhile providing some way to encourage the use of OpenLDAP, rather than the OS native LDAP (whatever that may be), if it *can* be used? Perhaps a --I-cant-believe-its-not-OpenLDAP flag of some sort (sorry, British humour - that probably doesn't mean anything to anyone else ...)?] If you think it's worth opening a thread on any of these (probably, I'd guess, in the main Samba discussion rather than Samba-Technical?) then please say so and I'll do so. Otherwise I'll continue quietly to ignore them :-) Many thanks folks, and have a great week/weekend, Cheers, Tris. -Original Message- From: Tris Mabbs [mailto:tm-samba201...@firstgrade.co.uk] Sent: 15 March 2013 17:59 To: Andrew Bartlett Cc: 'Michael Wood'; Guenther Deschner; samba@lists.samba.org; samba-techni...@samba.org Subject: RE: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest). So it seems that with these changes, kerberos_decode_pac() is never entered with client_principal anything other than a NULL pointer. So I'm (very) happy that these changes fix my problem. However it does seem a little curious that client_principal now never appears to be set - I don't know whether that's expected
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
So it seems that with these changes, kerberos_decode_pac() is never entered with client_principal anything other than a NULL pointer. So I'm (very) happy that these changes fix my problem. However it does seem a little curious that client_principal now never appears to be set - I don't know whether that's expected behaviour? It isn't, we need to look into that some more. More than happy to - let me know what you want put where and it'll be done. Meanwhile, having cleared them out recently, I currently have ~3,600 PAC dumps, not a single one with the Kerberos principal in the name (every one's a PID based name). On the plus side, still nary a core dump: ---Cut here: # find /var/samba4/log/cores/ -type f # ---Cut here. Does the ndrdump run you did before now pass fine? Yes, runs perfectly: ---Cut here: % /var/tmp/samba/samba-master/samba-gd/bin/ndrdump krb5pacdecode_pac in PAC-NDR-1819 pull returned NT_STATUS_OK decode_pac: struct decode_pac in: struct decode_pac pac: struct PAC_DATA num_buffers : 0x0005 (5) version : 0x (0) buffers: ARRAY(5) buffers: struct PAC_BUFFER type : PAC_TYPE_LOGON_INFO (1) _ndr_size: 0x0248 (584) info : * info : union PAC_INFO(case 1) logon_info: struct PAC_LOGON_INFO_CTR ... buffers: struct PAC_BUFFER type : PAC_TYPE_KDC_CHECKSUM (7) _ndr_size: 0x0014 (20) info : * info : union PAC_INFO(case 7) kdc_cksum: struct PAC_SIGNATURE_DATA type : KERB_CHECKSUM_HMAC_MD 5 (0xFF76) signature: DATA_BLOB length=16 [] 3B 96 CC BB BB 9D E4 57 13 C9 6D 1C 65 A0 B1 1B ;..W ..m.e... RODCIdentifier : 0x (0) _pad : 0x (0) dump OK % --- Cut here. Large amounts of data, all looking absolutely fine. So definite progress ... Many thanks, regards, and have a great weekend everyone, Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
Hiya Andrew, Günther, Andrew, many thanks for following up on this. Where did we get with this? Currently stalled, temporarily I'm sure, by my ignorance of git I'm afraid. Günther pointed me at a branch with some changes but I've been unable to find it, either through the Samba GitWeb view on the repository or by trying to persuade git itself to locate the branch. I've asked Günther for some pointers on how to retrieve the branch but he's apparently understandably been too busy to answer what is honestly a pretty noob question on git. So my fault I'm afraid - not been able to try Günther's changes yet. Hopefully I'll be able to figure out how to access his changes, or someone will enlighten me, at which point I'll test it; then I'll put my patch back in and see whether I then also get a PAC dump written under the Kerberos principal name (which would hopefully confirm that the changes then also cause normal code paths to be followed for this user). Many thanks for the follow-up - much appreciated, Cheers, Tris. -Original Message- From: Tris Mabbs Sent: 07 March 2013 12:16 To: 'Guenther Deschner' Subject: RE: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest). Hiya again Günther, Sorry to bother you again, but is there any chance of some quick words of wisdom on how to retrieve that branch please? I'd really like to test the code but cannot find it, or how to pull that into my local Samba source tree. Again, apologies for my current complete lack of experience with git. Many thanks, and regards, Tris. -Original Message- From: Tris Mabbs Sent: 01 March 2013 18:24 To: 'Guenther Deschner' Subject: RE: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest). Hiya again Günther, I'm *really* sorry - I must be being completely dense but I can't actually find that branch. If I look for it using the Samba GitWeb, it doesn't seem to show anything in there since 2009. I also can't persuade git itself to recognise anything related to it. I'm afraid I only started using git, for anything other than a simple clone (or update) of the Samba source, a couple of days ago. Prior to that, all my RCS experience is with the somewhat dated (!) SCCS, or more recently SubVersion. If you have a moment to jot down a couple of basic instructions for pulling the branch with your changes in it, I'd greatly appreciate it, and would then be able to try the code. Apologies for my complete incompetence with git! Many thanks, and regards, Tris. -Original Message- From: Tris Mabbs Sent: 28 February 2013 22:33 To: 'Guenther Deschner'; Tris Mabbs Cc: samba@lists.samba.org Subject: RE: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest). Hiya Günther, Absolutely - I'm really sorry, I intended to try this today but haven't had the chance. Hopefully I will get the chance tomorrow, and I'll let you know the results. Many thanks, much appreciated :-) Tris. -Original Message- From: Guenther Deschner Sent: 28 February 2013 15:09 To: Tris Mabbs Cc: samba@lists.samba.org Subject: Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest). Hi Triss, can you test this branch? https://git.samba.org/?p=gd/samba/.git;a=shortlog;h=refs/heads/master-krb5pa c It contains fixes for various pac buffer types. Let us know if it resolves your issues. Thanks, Guenther -- Günther DeschnerGPG-ID: 8EE11688 Red Hat gdesch...@redhat.com Samba Team g...@samba.org -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
Hiya Michael, Many thanks for that - very much appreciated. I think I should learn more about git than currently I know - however this is not the time to do so. So I ran your commands, first not worrying about any local changes so just updating my local copy: ---Cut here: samba-master % git remote add gd git://gitweb.samba.org/gd/samba samba-master % git checkout -b master-krb5pac gd/master-krb5pac fatal: git checkout: updating paths is incompatible with switching branches/forcing Did you intend to checkout 'gd/master-krb5pac' which can not be resolved as commit? samba-master % ---Cut here. OK, not so good ... So then I (effectively) completely removed and recreated my samba-master and tried your second option: ---Cut here: samba-master % cd .. samba % mv samba-master samba-master.tmp ; mkdir samba-master ; cd samba-master samba-master % git clone git://gitweb.samba.org/gd/samba samba-gd Initialized empty Git repository in /var/tmp/samba/samba-master/samba-gd/.git/ remote: Counting objects: 928083, done. ... Resolving deltas: 100% (708307/708307), done. samba-master % cd samba-gd samba-gd % git checkout -b master-krb5pac origin/master-krb5pac Branch master-krb5pac set up to track remote branch refs/remotes/origin/master-krb5pac. Switched to a new branch master-krb5pac samba-gd % dircmp . ../../samba-master.tmp | grep -i '^different' | grep -v '/\.git/' different ./auth/credentials/pycredentials.c different ./auth/kerberos/kerberos_pac.c different ./lib/torture/torture.h different ./lib/util/samba_util.h different ./lib/util/tevent_debug.c different ./librpc/idl/krb5pac.idl different ./librpc/ndr/ndr_krb5pac.c different ./pidl/wscript different ./source3/auth/auth_generic.c different ./source3/auth/auth_util.c different ./source3/lib/events.c different ./source3/libnet/libnet_join.c different ./source3/libnet/libnet_join.h different ./source3/libsmb/pylibsmb.c different ./source3/smbd/oplock.c different ./source4/auth/gensec/pygensec.c different ./source4/lib/events/tevent_s4.c different ./source4/lib/registry/pyregistry.c different ./source4/torture/ndr/drsblobs.c different ./source4/torture/ndr/nbt.c different ./source4/torture/ndr/ndr.c different ./source4/torture/ndr/ndr.h different ./source4/torture/ndr/ntprinting.c different ./source4/torture/wscript_build different ./source4/winbind/wb_cmd_getgrgid.c different ./source4/winbind/wb_cmd_getgrnam.c different ./source4/winbind/wb_cmd_getpwnam.c samba-gd % ---Cut here. That does actually seem to have done something, and the files which are changed look as though they might be relevant to this problem. Not sure why that worked but the first option didn't, but there you go ... So, again, many thanks - I'll now try building from that branch and testing; I'll send an update once done. Cheers! Tris. -Original Message- From: Michael Wood Sent: 08 March 2013 10:33 To: Tris Mabbs Cc: Guenther Deschner; Andrew Bartlett; samba@lists.samba.org Subject: Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest). On 8 March 2013 11:03, Tris Mabbs tm-samba201...@firstgrade.co.uk wrote: Hiya Andrew, Günther, Andrew, many thanks for following up on this. Where did we get with this? Currently stalled, temporarily I'm sure, by my ignorance of git I'm afraid. If you have no local changes, try this: Change to the directory where you have the Samba git repository. $ cd /path/to/samba-master $ git remote add gd git://gitweb.samba.org/gd/samba $ git checkout -b master-krb5pac gd/master-krb5pac If you have local changes and don't want to learn more about git than you need right now, clone the repository to a separate directory: $ cd somewhere $ git clone git://gitweb.samba.org/gd/samba samba-gd $ cd samba-gd $ git checkout -b master-krb5pac origin/master-krb5pac ... -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
Hello again everyone, On 08 March 2013 13:10, Michael Wood wrote: ... ---Cut here. Sorry, I forgot a step. You would have needed a git fetch gd in there before the checkout. Ah ha! That would explain it then. Well, forgotten command or not, the help was much appreciated and I now have a version built and running from Günther's branch. So many thanks for the assistance, and I now know slightly more about git than I did before :-) So, back to the original problem ... Compiled up against Günther's branch, installed, tested. The results are interesting: 1) User access: From my perspective, it's cured the issue. My problematic user can once again access resources. This is very good news; many, many thanks to everyone who has assisted getting to this stage. 2) Core dumps: The code has now been running for a few hours, with some reasonably intensive access requests going on (lots of sessions being established and closed). By now, I'd normally have expected an smbd core-dump, but haven't had a single one. So this might have been the cause of that as well. However I'll leave things for a few days before considering that to be fixed. 3) PAC dumps. I put my patch code back into kerberos_pac.c (kerberos_decode_pac()) to see whether I now got PAC dumps named by Kerberos principal name. Previously, all other users were causing PAC dumps named by their Kerberos principal name, but there were none for the problematic user. As Andrew had indicated he considered that unusual, I thought I see what happened with Günther's changes. On the plus side, all the PAC dumps are now consistently named, all (currently) ~110 of them; on the minus side, not a single one is named with the Kerberos principal name. So it seems that with these changes, kerberos_decode_pac() is never entered with client_principal anything other than a NULL pointer. So I'm (very) happy that these changes fix my problem. However it does seem a little curious that client_principal now never appears to be set - I don't know whether that's expected behaviour? I'll leave my patch in for a few more days and see whether that changes (with sessions being established after Kerberos tickets have been renewed or re-acquired, for example), but previously I'd have had quite a few PAC dumps named by Kerberos principal by now, and I have nary a one (and while I've typed this, I'm up to ~160 PAC dumps and they're still all named by PID rather than by Kerberos principal). For both this, in case it's significant, and the core-dumps, I'll send an update in a few days. Very much appreciated everyone - thank you! Cheers, Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] no network interfaces found on OpenIndiana (Illumos)
Hiya Joeri, I had exactly the same problem with OpenSolaris - would not find the interfaces. However I found that if I explicitly defined the interfaces in the smb.conf file: interfaces = if.ip.add.ress/netmask_bits if.ip.other.address/netmask_bits Samba was quite happy to pick that up. I had the same problem with the ISC DHCP server, but there I had actually to modify code to get it to work. It does seem that there's something odd in the way some Solaris versions provide access to the interface lists, but I've never had time to get fully to the bottom of it (and I'm afraid I can't remember exactly what I had to change in the ISC DHCP server to get it to work). Something perhaps to be picked up at some point for investigation by the developers, but it's probably much easier for you right now just to try adding an interfaces line to your smb.conf and see whether that fixes it for you - hopefully it will. Hope that helps! Cheers, Tris. Ps. So the interfaces line you'd want (IPv4) would be something like interfaces 192.168.250.8/24 127.0.0.1/8 or interfaces 192.168.250.8/255.255.255.0 127.0.0.1/255.0.0.0. -Original Message- From: Joeri Vanthienen [mailto:m...@joerivanthienen.be] Sent: 06 March 2013 10:42 To: samba@lists.samba.org Subject: [Samba] no network interfaces found on OpenIndiana (Illumos) Hi, I've downloaded the samba 3.6.12 OpenCSW package. I joined openindiana to the the active directory, winbind seems to work fine, I see all the users with wbinfo -u. However, my samba server is not starting. It seems that there is no network card found. 2013/03/06 10:40:39.068405, 0] lib/interface.c:543(load_interfaces) WARNING: no network interfaces found [2013/03/06 10:40:39.072795, 0] smbd/server.c:1082(main) standard input is not a socket, assuming -D option ... [2013/03/06 10:40:39.205210, 0] smbd/server.c:746(open_sockets_smbd) open_sockets_smbd: No sockets available to bind to. Is there some problem that the get_interfaces(talloc_tos(), ifaces); call returns no interfaces on solaris/openindiana ? Any idea? I sure have interfaces: root@openindiana:/# ifconfig -a lo0: flags=2001000849UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL mtu 8232 index 1 inet 127.0.0.1 netmask ff00 e1000g0: flags=1004843UP,BROADCAST,RUNNING,MULTICAST,DHCP,IPv4 mtu 1500 index 3 inet 192.168.250.8 netmask ff00 broadcast 192.168.250.255 ether 8:0:27:bd:35:de lo0: flags=2002000849UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL mtu 8252 index 1 inet6 ::1/128 e1000g0: flags=20002004841UP,RUNNING,MULTICAST,DHCP,IPv6 mtu 1500 index 3 inet6 fe80::a00:27ff:febd:35de/10 ether 8:0:27:bd:35:de -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Making Linux and domain users the same
Hiya Phil, Thanks for the thanks, and you're most welcome :-) Even if it didn't provide you with a solution, hopefully it gave you some insight into what was going on. I'm really glad the simpler solution worked, and equally glad you've now got it all working - well done. Now just remember not to turn off NIS :-) Cheers, Tris. -Original Message- From: Phil [mailto:org-sa...@freed.com] Sent: 06 March 2013 10:14 To: Tris Mabbs Cc: samba Subject: Re: [Samba] Making Linux and domain users the same Thanks once again, Tris. As you see from the previous message, it turns out that there was a simple method to get what I needed. But I still appreciate your help, and the time you took to describe a complex solution in careful detail. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] no network interfaces found on OpenIndiana (Illumos)
Hiya Joeri, Thank you for your reply! Really helpful. You're most welcome - hope it helps! I'm suspecting that my problem had something to do with virtualbox. I deployed it today on a normal physical machine and it worked immediatly, without the interfaces line. I think it might possibly be something to do with the actual interface names. My OpenSolaris box, and your VirtualBox image, are both using e1000g0 (in my case also e1000g1) interfaces, the generic Intel 825xx NIC driver. In my case, that's the correct driver for the actual physical card in use; in your case, it is (if I remember rightly) the standard virtualised emulated hardware supplied in VirtualBox. The point is, if you look on the physical server on which you didn't have any problems, I'll bet it's not using an e1000g0 interface ... I wonder whether it's purely down to the length of the interface name? Typical Sun interface names are much shorter, E.g. qfe0, elx0, etc. Whatever, hopefully adding an interfaces line on your VirtualBox will resolve the issue (fingers crossed for you :-) Good luck! Cheers, Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Making Linux and domain users the same
Hiya, Your output shows: $ ls -n total 4 -rw-r--r-- 112903 100 3 Mar 2 03:40 File_Created_In_Linux -rwxrw-rw- 1 16777217 16777216 3 Mar 1 13:12 File_Created_In_Windows And: [global] idmap uid = 16777216-33554431 So your joe user is picking up an IDMAPped UID. That's expected behaviour unless Samba is told any other way to map the name to a Unix UID - it needs to get that information from somewhere. This should work when you can get wbinfo --uid-info 12903 to give you sensible looking information for your joe user. How do you get to that stage? Well, someone who knows Samba better than I do (so just about anyone ...) can probably correct this, and doubtless say Good grief, don't do it like THAT!, but what we use is: smb.conf: passdb backend = tdbsam idmap config MYDOMAIN : backend = ad idmap config MYDOMAIN : range = 100-99 idmap config MYDOMAIN : schema_mode = rfc2307 idmap config MYDOMAIN : default = yes idmap config * : backend = tdb idmap config * : range = 100-199 map untrusted to domain = yes ldap ssl = no ldapsam:trusted = yes ldapsam:editposix = yes # DN used to contact LDAP server. # MUST HAVE PASSWORD SET IN secrets.tdb (using smbpasswd -W)! ldap admin dn = CN=LDAP_access_user,CN=Users,DC=MYDOMAIN,DC=COM # Set the LDAP connection timeout (allowing for slow responses). ldap connection timeout = 60 # LDAP information. ldap suffix = DC=MYDOMAIN,DC=COM ldap user suffix = OU=Users ldap group suffix = OU=Groups ldap machine suffix = OU=Computers ldap idmap suffix = OU=Idmap (obviously replace the DC=MYDOMAIN,DC=COM type bits with your own information). You'll then need a user, LDAP_access_user in my example, who has read access to LDAP. Set their password on your Samba server using smbpasswd -W (so smbpasswd knows how to authenticate as that user). Then make sure you have Identity services for Unix (or whatever it's called on whichever version of Windows Server you're using on your PDC - Primary Domain Controller - your AD server(s)) installed. Then, in the user-properties (Active Directory Users and Computers) you'll have a bunch of Unix settings you can specify. These will include UID, GID, home directory, shell, etc. You can do it without loading Identity Services for Unix, but it means potentially going in and editing the LDAP information (not recommended unless you know what you're doing), and possibly even the LDAP schema (really not recommended unless ...). Identity Services for Unix sets all that up for you and gives you a nice, easy way to access the appropriate LDAP objects, in the RFC2307 schema. This is just one way to configure this, with an LDAP connection (NOT using SSL in our case, as it's completely inside a multiply firewalled network with users who aren't going to poke LDAP themselves - I haven't been bothered to set up the certificates etc. required for an SSL LDAP session so you need to be aware that what I've listed above uses unencrypted LDAP queries! Oh, you may need to enable that on your PDC as it might be disabled, depending on how you currently have it configured - there's M$ documentation that's easy to find about how to do that). When an ID mapping is required, an LDAP query is made to find the RFC2307 schema Unix information in AD; that's then used to provide the information to Samba. This does have a few Gotcha!s to be aware of: 1) That configuration is from a Samba 4 smb.conf file. Your mileage may vary depending on what version of Samba you're running. 2) It uses unencrypted LDAP queries. Yes, I know I've already mentioned that but it is a very important point. 3) It uses map untrusted to domain = yes - that's appropriate for the setup I'm running but you will want to check the documentation as to whether or not that's appropriate, or required, for your network. 4) You may need to disable VLV (Volume Level View) queries on your LDAP (AD) server. That may or may not be a problem; it probably will be if you're running Exchange 2010. Beware ... 5) This is just one approach, which I threw together to meet our specific needs. There are undoubtedly better ways to do this! 6) DON'T JUST BLINDLY COPY THAT INFORMATION, READ THE APPROPRIATE DOCUMENTATION AND MAKE SURE YOU UNDERSTAND WHAT IS BEING CONFIGURED! I mean, that's just plain common-sense anyway - don't blindly take my, or anyone else', word for how you should configure anything ... And don't blame me if it goes wrong :-) There is quite a bit of documentation on the Samba pages about how to do this sort of thing - you should check them first/as well. Hopefully this might at least point you in the right direction and give you a suitable starting point. Good luck :-) Tris. Ps. If you're stuck using NIS with your old Slowlaris machine, you
Re: [Samba] Making Linux and domain users the same
One other quick point ... I assume you've got a working LDAP configuration, because your smb.conf included a reference to not using LDAP ssl. If you *haven't* already got a working LDAP configuration, you'll need to set that up first. There's plenty of documentation out there on how to do that on Linux; make sure you set a bind user which matches the (example) LDAP_access_user in the smb.conf file. Check that that works with a suitable LDAP query command (that'll be in the documentation) before trying to get your Samba configuration to work, or you'll get nowhere fast ... You don't actually need a user like that if you're allowing anonymous LDAP binds, but that isn't really recommended (and will doubtless cause loads of warnings to be logged in your PDC event log). Windows doesn't particularly like non-SSL LDAP queries; it *really* doesn't like *anonymous* non-SSL LDAP queries ... That is, of course, if you decide to go a similar way to the example I sent earlier and not some better way anyway :-) Good luck! Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
Hiya Günther, Absolutely - I'm really sorry, I intended to try this today but haven't had the chance. Hopefully I will get the chance tomorrow, and I'll let you know the results. Many thanks, much appreciated :-) Tris. -Original Message- From: Guenther Deschner [mailto:g...@samba.org] Sent: 28 February 2013 15:09 To: Tris Mabbs Cc: samba@lists.samba.org Subject: Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest). Hi Triss, can you test this branch? https://git.samba.org/?p=gd/samba/.git;a=shortlog;h=refs/heads/master-krb5pa c It contains fixes for various pac buffer types. Let us know if it resolves your issues. Thanks, Guenther -- Günther DeschnerGPG-ID: 8EE11688 Red Hat gdesch...@redhat.com Samba Team g...@samba.org -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
literally anywhere, possibly even before the start of the string (if someone forgot to make the length unsigned, but I don't consider that likely given the general extremely high quality of the code). If that is the case, it was always going to end in tears ... That would also potentially explain why I get a SIGSEGV and you don't - perhaps the way memory had previously been used on your machine (could be different libraries, different executable because of being on a different OS - I doubt you're running OpenSolaris on your big server, different architecture, different phase-of-the-moon ...) meant there happened to be a convenient NULL lying around in the memory block into which the DNS domain name was decoded - you might have received garbage in the output, but at least not a large and obnoxious SIGSEGV hitting you in the back. I got it, and I ran an automated git bisect on our big server. The problem commit is apparently: a6be8a97f705247c1b1cbb0595887d8924740a71 is the first bad commit commit a6be8a97f705247c1b1cbb0595887d8924740a71 Author: Simo Sorce i...@samba.org Date: Thu Sep 27 14:12:06 2012 -0400 Support UPN_DNS_INFO in the PAC Previously marked as UNKNOWN_12 the UPN_DNS_INFO is defined in MS-PAC Autobuild-User(master): Simo Sorce i...@samba.org Autobuild-Date(master): Fri Sep 28 01:13:44 CEST 2012 on sn-devel-104 Oh you *so* have to love git bisect ... I'm an old SCCS die-hard, who has (recently and reluctantly) been forced into using SVN. Now I see what git is capable of, I might just take a leap into the 21st century ... I've CC'ed Simo who made the change, and GD who is working on improving our PAC handling (he has a series of patches under development, which may already solve your issue). Hopefully they can sort things out from here. Excellent - hopefully the information above is of use then. Thanks - much appreciated. If you can contribute your PAC to the public realm (the PAC itself does not contain passwords, but you will need to read the full dump to determine if any other details might be a problem), then I know it will be very much appreciated, as we can add tests to show that these exotic samples continue to work. From what I can see (can't, of course, read the dump past the SIGSEGV :-), there's not anything in there about which particularly to be concerned. OK, so normally I don't even like letting an e-mail address out into the wild, but that's just because I'm paranoid (What, me? Paranoid? Who said that?! ...). So yes, do please feel free to consider the dump contributed to the public domain as a future potential test case. Of course, if it is that the UPN length trips a padding problem, you can probably much more simply generate a test PAC. However you're still welcome to the one I sent you anyway. Thanks, Likewise! Andrew Bartlett Tris Mabbs. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
been written literally anywhere, possibly even before the start of the string (if someone forgot to make the length unsigned, but I don't consider that likely given the general extremely high quality of the code). If that is the case, it was always going to end in tears ... That would also potentially explain why I get a SIGSEGV and you don't - perhaps the way memory had previously been used on your machine (could be different libraries, different executable because of being on a different OS - I doubt you're running OpenSolaris on your big server, different architecture, different phase-of-the-moon ...) meant there happened to be a convenient NULL lying around in the memory block into which the DNS domain name was decoded - you might have received garbage in the output, but at least not a large and obnoxious SIGSEGV hitting you in the back. I got it, and I ran an automated git bisect on our big server. The problem commit is apparently: a6be8a97f705247c1b1cbb0595887d8924740a71 is the first bad commit commit a6be8a97f705247c1b1cbb0595887d8924740a71 Author: Simo Sorce i...@samba.org Date: Thu Sep 27 14:12:06 2012 -0400 Support UPN_DNS_INFO in the PAC Previously marked as UNKNOWN_12 the UPN_DNS_INFO is defined in MS-PAC Autobuild-User(master): Simo Sorce i...@samba.org Autobuild-Date(master): Fri Sep 28 01:13:44 CEST 2012 on sn-devel-104 Oh you *so* have to love git bisect ... I'm an old SCCS die-hard, who has (recently and reluctantly) been forced into using SVN. Now I see what git is capable of, I might just take a leap into the 21st century ... I've CC'ed Simo who made the change, and GD who is working on improving our PAC handling (he has a series of patches under development, which may already solve your issue). Hopefully they can sort things out from here. Excellent - hopefully the information above is of use then. Thanks - much appreciated. If you can contribute your PAC to the public realm (the PAC itself does not contain passwords, but you will need to read the full dump to determine if any other details might be a problem), then I know it will be very much appreciated, as we can add tests to show that these exotic samples continue to work. From what I can see (can't, of course, read the dump past the SIGSEGV :-), there's not anything in there about which particularly to be concerned. OK, so normally I don't even like letting an e-mail address out into the wild, but that's just because I'm paranoid (What, me? Paranoid? Who said that?! ...). So yes, do please feel free to consider the dump contributed to the public domain as a future potential test case. Of course, if it is that the UPN length trips a padding problem, you can probably much more simply generate a test PAC. However you're still welcome to the one I sent you anyway. Thanks, Likewise! Andrew Bartlett Tris Mabbs. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
Wow. Hiya Andrew, OK, this sounds like a very promising approach, and potentially saves me working through a large number of git bisects (as also most helpfully suggested by Michael Wood) - so far, I'm right back into the beta code and there have been a lot of commits since then... I'm not easily in a position to set up a test domain for this, but I have no problem with your suggestion of capturing on the live domain and sending to you (especially since changing the password doesn't affect the issue). Or of dumping the information and decoding the PAC using ndrdump (wasn't aware of that). I'll work through your suggestions and see if I can get anywhere; when I reach a stage where I can't figure it out any further I'll send you what I've got. Any useful conclusions that don't contain sensitive information, I'll put back onto this thread in case they're of use to anyone else as well. It will probably take me a few days to get anywhere useful, as I can only really poke this out of normal working hours. So if there's no update for a few days, please don't think that means I've stopped. BTW, to answer your question, access is based on the username not the full name (haven't tried that, which in itself is an interesting point - not sure whether that would affect it as presumably that just forms an alternative mapping back to the underlying internal AD entity, but ...). Many thanks, I'll update as soon as I can. Cheers! Tris. -Original Message- From: Andrew Bartlett [mailto:abart...@samba.org] Sent: 26 February 2013 11:05 To: Tris Mabbs Cc: samba@lists.samba.org Subject: Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest). On Mon, 2013-02-25 at 11:51 +, Tris Mabbs wrote: Hello, ... When accessing our main server using that account, smbd always reports can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL. This has come from ../auth/kerberos/kerberos_pac.c:149(kerberos_decode_pac), trying to use NDR to pull a blob from the Kerberos ticket (that's reported as ndr_pull_error(11): Pull bytes 34 (../librpc/ndr/ndr_string.c:591)). ... 'Clearly' (as in, clear as mud, but the general direction to look at) either the IDL in librpc/idl/krb5pac.idl is incorrect, or the parsing code in Heimdal in unpacking this particular user's PAC incorrectly. It is interesting that this user causes the issue regardless of being re-created. Is this triggered on their full or user name? Does this happen if you set up a new testing domain? If so, what would be really, really helpful would be a network capture including the server keytab. (Or if you don't mind, and change the server password after, on your live domain to me personally). The procedure you or I will need to follow is to extract the decrypted 'PAC'. You could do this either from wireshark (export selected packet bytes, after running wireshark -k /tmp/server.keytab, or by patching the code to call: _PUBLIC_ bool file_save(const char *fname, const void *packet, size_t length) somewhere near auth3_generate_session_info_pac() Then, using that file, run bin/ndrdump krb5pac decode_pac in /tmp/pac Then essentially we keep changing the idl in librpc/idl/krb5pac.idl and the C helpers in librpc/ndr/ndr_krb5pac.c until this works. See also http://msdn.microsoft.com/en-us/library/cc237917.aspx Good luck! Andrew Bartlett -- Andrew Bartletthttp://samba.org/~abartlet/ Authentication Developer, Samba Team http://samba.org -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
What I was getting at about the full name is that if this was a odd character encoding issue, knowing that this was a user with non-ascii full name would be an important data point. Yes, I see what you mean. No, neither the full username, nor the login name, contain anything other than Good 'Ole ASCII. See, the PAC is much more than just SIDs, it is a lot of different bits of information that a user needs to log in to a desktop, or (less so) to operate against a file server. I can see I'm going to have to look into the contents of the PAC in a bit more detail. Although I have some familiarity with Kerberos, I've not had to dig into a PAC before; so far as I was aware it was mainly supplemental group membership, and similar information - obviously there's more in there than I was aware of. Still, a day where something is learned is never a day wasted - it will be interesting to have a dig! The key password in this case isn't the user's password (it isn't involved), but the machine account password of the server. Sorry, yes - I meant that I had no problem sending you any data which might be contained in any WireShark capture; as you pointed out, any password can easily be changed (including the Samba machine account password on the AD server). Apologies for not being clearer. Andrew Bartlett Once again, many thanks - I'll update you when I have anything useful. Tris Mabbs. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
probably to everyone's advantage to get this sorted out - I know it would certainly be to mine :-) Many thanks, and regards, Tris Mabbs. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Samba 4 - smbd; can't parse the PAC: NT_STATUS_BUFFER_TOO_SMALL error but only for a single domain user (Server 2008 R2 domain, Server 2008 functional level forest).
Hiya Michael, Many thanks for the quick and helpful response. Yes, I can certainly try a packet capture; I think I'll go with your other suggestion first though, that of using git bisect to track down the problematic version. I'm sorry, that should have occurred to me . Once I've identified the problematic version, I can post that information and then start capturing packets if necessary. Who knows - finding where the break occurred might make someone such as yourself slap your forehead in a Homer Simpson like way (Doh!) and say Of *course*, that's what will have done it . :-). It's not in a test environment; we don't run one here (the development work we do doesn't require a separate test network), so this is on our production network. However I have considerable freedom in taking servers out of service so long as it's not during the most active times, so I'm quite happy to bounce versions around (and perform any other tests required). As for what was common between the original and the re-created user - the username. That's it. I didn't even bother setting up the description information. However I also tried renaming the account and the problem still occurred, so I'm not at all sure exactly what is causing it. I did originally set the password to be the same, but have since reset it several times (to varying lengths; I know that shouldn't affect this sort of problem but by then I was running out of ideas .). You're also quite correct in that Samba shouldn't core dump. However I think I'll get to the bottom of this problem and then perhaps start a separate thread on that, rather than obfuscating this one with multiple problems. So thanks for the thought - I'll raise a new problem for that once this has been sorted. I can't take that server down just at the moment - middle of the working day here. However I'll see whether I can switch versions around until I can find the problem hopefully later on this-evening. Once again, many thanks for the most helpful suggestions. Watch this space for the responses. Tris. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
