Re: [Samba] User policy in samba
On 22.5.2013 19:44, Marc Muehlfeld wrote: Hello, Am 22.05.2013 16:24, schrieb Gregory Sloop: Is it possible to set User specific password policies in Samba4. Say I wan to set the Password length of a particular user to be 7 where as my domain policy is 10 How to do this in samba4? The only way I can think of that would apply some policies to some users and a different policy to others would be a GPO. But I'm not entirely sure if password complexity reqs. can be applied selectively via GPO. [I think so, but I've never tried it - and the docs sure look like it's possible.] GPO won't work for that: https://wiki.samba.org/index.php/Samba4/FAQ#Is_it_possible_to_set_user_specific_password_policies_in_Samba4_.28e._g._on_a_OU-base.29.3F Note that Samba should still serve those GPO objects to clients that process them. Unmodified Windows clients should thus still obey those policies, but Samba as a server just doesn't enforce them, which also means that non-Windows clients will ignore them. At least that's how I'm understanding it. Pekka L.J. Jalkanen -- 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 Admt to other Domain Windows Server 2008
If I were in your position, to keep things simple I would first transfer or seize all FSMO roles to the Windows DC, copy SYSVOL over to it as well (Samba doesn't auto-sync it) and then take the Samba DC offline; don't know if you did so already. However, I believe that if you're still having problems after that you'll really have to ask Microsoft, as an ADMT migration between two domains running exclusively Windows DCs is no Samba problem anymore. But just to give you a starting point: a quick googling with your error message points me to the following discussion: http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/f1c1e2b8-12d8-4fef-b9a3-ec6e671ad909 Perhaps you're having a permissions problem? My own experiences with ADMT are such that it really takes a moment to set all the relevant permissions group memberships properly or else things won't work. Pekka L.J. Jalkanen On 21.5.2013 9:33, wong lmark wrote: I had added the Windows 08 DC in Samba 4 domain. But I cannot migrate the SID when I tick Migrate User SID, it will show Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate Sid's. 2013/5/21 Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi On 21.5.2013 6:56, Andrew Bartlett wrote: On Tue, 2013-05-21 at 11:19 +0800, wong lmark wrote: Hi, I have a Samba 4 domain created and now I need to transfer all users and groups to other Windows 2008 Domain. How can I use the ADMT? Why do you want to use ADMT? If you just need to move to Windows, then just join a Windows DC to the Samba domain as DC, transfer the FSMO roles, and then offline the Samba DC. Also, it is good to note that even if you can't avoid ADMT (in the case you must migrate your users to another _existing_ domain) you'd still need to do as Andrew says and add a Windows DC to the _source_ domain first, because the target domain needs to be trusted by the source for ADMT to work at all. While Samba can be trusted by others, it currently cannot itself trust other domains, so ADMT simply cannot work without a Windows DC in the source. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba -- 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 Admt to other Domain Windows Server 2008
Like I said, you should really ask your questions on an MS forum if you're having problems in a pure Windows environment. Googling your error this time gives this: http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/bba3d024-4d94-4c6e-a014-d457cdbaeee4/ Based on what I've read there your trouble sounds like a DNS or a sysvol problem. If you copied your sysvol directory from the Samba DC without taking care of all of the ACLs and attributes (I'm always doing my manual sysvol copies to or from Windows using robocopy to guard against losing them), this might be the reason. But this is just a guess; I can't really help you any further. Read the linked page; that might give you some ideas. Pekka L.J. Jalkanen On 21.5.2013 12:39, wong lmark wrote: I had transfer all FSMO roles to Win DC, copy and paste the sysvol in Win DC. But the win dc shown error message call Naming information cannot be located because: The specified domain either does not exist or could not be contacted. Is it any thing I did wrong? 2013/5/21 Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi If I were in your position, to keep things simple I would first transfer or seize all FSMO roles to the Windows DC, copy SYSVOL over to it as well (Samba doesn't auto-sync it) and then take the Samba DC offline; don't know if you did so already. However, I believe that if you're still having problems after that you'll really have to ask Microsoft, as an ADMT migration between two domains running exclusively Windows DCs is no Samba problem anymore. But just to give you a starting point: a quick googling with your error message points me to the following discussion: http://social.technet.microsoft.com/Forums/en-US/winserverDS/thread/f1c1e2b8-12d8-4fef-b9a3-ec6e671ad909 Perhaps you're having a permissions problem? My own experiences with ADMT are such that it really takes a moment to set all the relevant permissions group memberships properly or else things won't work. Pekka L.J. Jalkanen On 21.5.2013 9:33, wong lmark wrote: I had added the Windows 08 DC in Samba 4 domain. But I cannot migrate the SID when I tick Migrate User SID, it will show Could not verify auditing and TcpipClientSupport on domains. Will not be able to migrate Sid's. 2013/5/21 Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi On 21.5.2013 6:56, Andrew Bartlett wrote: On Tue, 2013-05-21 at 11:19 +0800, wong lmark wrote: Hi, I have a Samba 4 domain created and now I need to transfer all users and groups to other Windows 2008 Domain. How can I use the ADMT? Why do you want to use ADMT? If you just need to move to Windows, then just join a Windows DC to the Samba domain as DC, transfer the FSMO roles, and then offline the Samba DC. Also, it is good to note that even if you can't avoid ADMT (in the case you must migrate your users to another _existing_ domain) you'd still need to do as Andrew says and add a Windows DC to the _source_ domain first, because the target domain needs to be trusted by the source for ADMT to work at all. While Samba can be trusted by others, it currently cannot itself trust other domains, so ADMT simply cannot work without a Windows DC in the source. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] configuring Shares, Users with Samba 4.0.5 as an AD DC
Hi Thierry, that command is called wbinfo. For details, run wbinfo --help. Some examples below: To find the Windows sid of an uid, run: wbinfo -U 300 (or any other uid). That sid can in turn be used to find the username: wbinfo -s S-1-5-32-544 So if you want to combine the whole thing into one, just run: wbinfo -s `wbinfo -U 300` Which should output something like: BUILTIN\Administrators 4 The number following the username just tells how many Windows users or groups are represented by that uid, if I'm understanding it correctly. For reversed direction (to get the uid from username), try: wbinfo -S `wbinfo -n Administrator` Although in most cases you should be able to just run getent passwd username to find the uid, whether the account is a windows account or not. Pekka L.J. Jalkanen On 20.5.2013 11:16, Thierry Gonon wrote: Hello Ulrich, It's simply the uid (user id) that are given by samba. You should have a command to find who ius which number, but I don't know it yet (I'm new to samba too !!) Thierry Gonon Archéologue - Administrateur Systèmes et Réseaux Responsable Informatique Chronoterre Archéologie - Mail original - De: Ulrich Schneider m...@ulrichschneider.de À: samba@lists.samba.org Envoyé: Lundi 20 Mai 2013 10:03:25 Objet: Re: [Samba] configuring Shares, Users with Samba 4.0.5 as an AD DC I created two folders as different win users in a samba share. 1. Folder is testadmin created as user Domain Administrator 2. Folder is testschueler2 created as user schueler2 ls -la drwxrwxr-x+ 2 300 users 4096 Mai 20 09:57 testadmin drwxrwxr-x+ 2 326 users 4096 Mai 20 09:59 testschueler2 What`s that number starting wird 3... and how do I know that this number belongs to wich user? Uli -- 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 Admt to other Domain Windows Server 2008
On 21.5.2013 6:56, Andrew Bartlett wrote: On Tue, 2013-05-21 at 11:19 +0800, wong lmark wrote: Hi, I have a Samba 4 domain created and now I need to transfer all users and groups to other Windows 2008 Domain. How can I use the ADMT? Why do you want to use ADMT? If you just need to move to Windows, then just join a Windows DC to the Samba domain as DC, transfer the FSMO roles, and then offline the Samba DC. Also, it is good to note that even if you can't avoid ADMT (in the case you must migrate your users to another _existing_ domain) you'd still need to do as Andrew says and add a Windows DC to the _source_ domain first, because the target domain needs to be trusted by the source for ADMT to work at all. While Samba can be trusted by others, it currently cannot itself trust other domains, so ADMT simply cannot work without a Windows DC in the source. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Sudden authentication failures, hex dumps in log.samba
On 14.5.2013 19:49, Pekka L.J. Jalkanen wrote: On 14.5.2013 19:31, Andrew Bartlett wrote: On Tue, 2013-05-14 at 11:04 +0300, Pekka L.J. Jalkanen wrote: On 14.5.2013 8:04, Andrew Bartlett wrote: The issue is the same for all of these accounts. We simply have a password encoded in a format that we do not correctly parse. The 00 20 stuff is literally some unicode space (ie the spacebar, yes!) padding that is in this structure. Huh?! Now I'm surprised, both about that there is such a parsing problem and that the problem is _that_ trivial. Shouldn't this mean that I can most likely work the problem away by simply changing the passwords of these users? Now that would be great news indeed! Yes, if I'm understanding it correctly. OK, I'll ask some of them to change their password, and then see what will happen. Thank you! Confirmed (so far only on one user): after password change logon works normally, and there are no errors in log.samba. (The account migration between domains was done earlier this year, but the accounts were temporarily marked as having never expiring passwords so that no password changes would be imposed in the process. Perhaps the whole issue wouldn't exist if this hadn't been done...) So it is now quite clear that there is something fishy in passwords migrated by MS's Password Export Server (the one shipped with ADMT v3.0). Unless this is fixed it will be important that at least one password change should be forced for any users previously migrated from other domains, or any present or future Samba DCs in the target domain won't understand them. (It's good to remember that even pure Samba DC environments could end up using ADMT if in need, because running it only requires presence of a Windows DC for a short period of time, so eval version should do. Also, one-way trust should suffice, with the target domain as the trusted one, so having Samba DC's on target shouldn't cause any problems. ADMT is also often simply quite necessary tool when organisation's structure changes for some reason.) Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Sudden authentication failures, hex dumps in log.samba
On 14.5.2013 8:04, Andrew Bartlett wrote: On Mon, 2013-05-13 at 14:24 +0300, Pekka L.J. Jalkanen wrote: Any ideas how to resolve this problem? No comments, it seems. I can see that even if this is a bug in Samba it would be really hard to reproduce. But it's really frustrating too, because if the authentication isn't reliable I sort of have to keep the Windows DC around. So if somebody would have an enlightened suggestion what to do, I'd be grateful. The only idea I'm having myself would be to recreate the machine accounts of the computers in question, but that'd be just a shot in the dark, and if the problem lies within the user accounts instead, that wouldn't help. G'Day, I'm sorry I haven't been able to get back to you. Please don't. I've had all too many questions for you already. Thank you for your patience with me! The issue is the same for all of these accounts. We simply have a password encoded in a format that we do not correctly parse. The 00 20 stuff is literally some unicode space (ie the spacebar, yes!) padding that is in this structure. Huh?! Now I'm surprised, both about that there is such a parsing problem and that the problem is _that_ trivial. Shouldn't this mean that I can most likely work the problem away by simply changing the passwords of these users? Now that would be great news indeed! I need to get both and encrypted copy of the data and some time to work over it, so we can correct this issue in our IDL. You already have a complete copy of our Samba DC's DB due to that exportkeytab issue. I can send you nonsanitised logs separately so that you can see the relevant account names. Is that enough, or do you need me to try to make an actual packet capture of this problem? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Sudden authentication failures, hex dumps in log.samba
On 14.5.2013 19:31, Andrew Bartlett wrote: On Tue, 2013-05-14 at 11:04 +0300, Pekka L.J. Jalkanen wrote: On 14.5.2013 8:04, Andrew Bartlett wrote: The issue is the same for all of these accounts. We simply have a password encoded in a format that we do not correctly parse. The 00 20 stuff is literally some unicode space (ie the spacebar, yes!) padding that is in this structure. Huh?! Now I'm surprised, both about that there is such a parsing problem and that the problem is _that_ trivial. Shouldn't this mean that I can most likely work the problem away by simply changing the passwords of these users? Now that would be great news indeed! Yes, if I'm understanding it correctly. OK, I'll ask some of them to change their password, and then see what will happen. Thank you! (The account migration between domains was done earlier this year, but the accounts were temporarily marked as having never expiring passwords so that no password changes would be imposed in the process. Perhaps the whole issue wouldn't exist if this hadn't been done...) I need to get both and encrypted copy of the data and some time to work over it, so we can correct this issue in our IDL. You already have a complete copy of our Samba DC's DB due to that exportkeytab issue. I can send you nonsanitised logs separately so that you can see the relevant account names. Is that enough, or do you need me to try to make an actual packet capture of this problem? The exportkeytab issue is the same issue. You are just seeing the same failure to read the password for a particular account in multiple ways. Oh. Well, now I'm understanding it all much better (or I at least hope that I do now). Thank you for explaining this! And thanks for replying--that reminded me that I forgot to send that log file to you. Will do so promptly. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Sudden authentication failures, hex dumps in log.samba
On 10.5.2013 16:32, Pekka L.J. Jalkanen wrote: On 10.5.2013 14:04, Pekka L.J. Jalkanen wrote: Question: how much more verbosity for log.samba would be needed to further investigate this problem? I'd rather not log everything with -d10 for extended periods of time, because I really can't know how long it will take for the problem to reappear. I've now increased logging from the default level to -d3. -d3 logging pays off: [2013/05/10 14:31:06, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: Client no longer in database: someu...@mydomain.site [2013/05/10 14:31:06, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: Failed building TGS-REP to ipv4:10.10.59.151:4736 [2013/05/10 14:31:06, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: TGS-REQ someu...@mydomain.site from ipv4:10.10.59.151:4737 for cifs/w2k3r2dc.mydomain.s...@mydomain.site [renewable, forwardable] [2013/05/10 14:31:06, 1] ../librpc/ndr/ndr.c:412(ndr_pull_error) ndr_pull_error(11): Pull bytes 2 (../librpc/ndr/ndr_basic.c:103) Client is Windows XP. I've yet to see this problem on newer clients... this and the other one that previously failed are the last two XP clients here that still remain in heavy production use. Somewhat similar error occurred with a Windows 7 machine. But note that for some reason only the short domain dame was used in reference to the realm: [2013/05/13 08:04:53, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: AS-REQ otheruser@MYDOMAIN from ipv4:10.10.59.148:58027 for krbtgt/MYDOMAIN@MYDOMAIN [2013/05/13 08:04:53, 1] ../librpc/ndr/ndr.c:412(ndr_pull_error) ndr_pull_error(11): Pull bytes 2 (../librpc/ndr/ndr_basic.c:103) [2013/05/13 08:04:53, 0] ../lib/util/util.c:457(dump_data) [] 00 00 00 00 62 00 00 00 00 00 00 00 20 00 20 00 b... . . [0010] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0020] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0030] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0040] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0050] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0060] 20 00 20 00 20 00 20 00 20 00 20 00 50 00 00 . . . . . .P.. [2013/05/13 08:04:53, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: UNKNOWN -- otheruser@MYDOMAIN: no such entry found in hdb What is also common with this client and the other that previously failed is that they both have once been migrated from a different domain (that no longer exists) using MS ADMT. This also applies to the users' accounts that were used. Don't know if that really matters, but just for the record. Also the Windows 7 client was once migrated this way. Both the second case and the third case were also different from the first one in the way that the users had no problems logging on. However, even though they said to me that they had had no authentication problems, I still think that they haven't just noticed, as I found the following from the event log of the second client: - Event Type: Warning Event Source: LSASRV Event Category: SPNEGO (Negotiator) Event ID: 40960 Date: 10.5.2013 Time: 13:52:42 User: N/A Computer: XPWKSTN2 Description: The Security System detected an attempted downgrade attack for server LDAP/samba4dc.mydomain.site. The failure code from authentication protocol Kerberos was Insufficient system resources exist to complete the API. (0xc09a). Event Type: Warning Event Source: LSASRV Event Category: SPNEGO (Negotiator) Event ID: 40961 Date: 10.5.2013 Time: 13:52:42 User: N/A Computer: XPWKSTN2 Description: The Security System could not establish a secured connection with the server LDAP/samba4dc.mydomain.site. No authentication protocol was available. Event Type: Warning Event Source: LSASRV Event Category: SPNEGO (Negotiator) Event ID: 40960 Date: 10.5.2013 Time: 14:31:05 User: N/A Computer: XPWKSTN2 Description: The Security System detected an attempted downgrade attack for server cifs/w2k3r2dc.mydomain.site. The failure code from authentication protocol Kerberos was Insufficient system resources exist to complete the API. (0xc09a). Event Type: Warning Event Source: LSASRV Event Category: SPNEGO (Negotiator) Event ID: 40961 Date: 10.5.2013 Time: 14:31:06 User: N/A Computer: XPWKSTN2 Description: The Security System could not establish a secured connection with the server cifs/w2k3r2dc.mydomain.site. No authentication protocol was available. - All this is really odd, though, as these machines have been part of the domain
[Samba] Winbind failover timeout?
I've got no answers, but I realised that I had a picked up a rather poor title, so here's a better one, combined with a more concise summary of my earlier babbling... Are there any smb.conf settings that control (Samba 3) Winbind's DC failover timeout when security = ADS? I do realise that there is a setting called ldap connection timeout, but I assume it is only related to situations where domain logons have been turned on and ldapsam is being utilised as a password backend. Is this correct? In case such settings do not exist can anyone please explain me the way that Winbind actually handles these failover situations internally? How transparent should the failover process be in practice? Any experiences? Thanks, Pekka L.J. Jalkanen On 10.5.2013 21:14, Pekka L.J. Jalkanen wrote: Hello all, I've a box running Samba 3.5.6 (Debian Squeeze) that retrieves its user accounts from AD, using Winbind. The box is receiving incoming mail. Idmap backend is AD, with rfc2307 schema mode. Currently it's only accessing one AD DC, and the MTA on the Samba box is stopped whenever the DC is temporarily offline to prevent rejection of any incoming mail with user unknown status. However, I'd like to add another DC to the mix, but I'm concerned that mail could get rejected if the active DC suddenly goes offline and winbind doesn't switch to another DC promptly enough. Consider the following scenario: 1. There is an AD account foo. The account hasn't been used for some time, and it's thus not in winbind's cache. It's possibly not even in Winbind's idmap cache. 2. There are two AD DCs, A and B. 3. Samba member server C runs Winbind and is currently using the DC A. 4. Hardware fails and the DC A suddenly drops offline. 5. Just few seconds later an e-mail is arriving for foo. The MTA tries to check for the user. 6. As Winbind is not yet aware of the unavailability of the DC A, it tries to contact it. A. Now, in the ideal world this would continue as follows: 7. Winbind can't contact the DC A anymore, so it promptly contacts the DC B. 8. The DC B confirms the existence of foo. 9. The MTA delivers mail for foo. B. However, I'm afraid that in the real world, the following could result: 7. Winbind frantically tries to contact the DC A, but timeouts and can't confirm the existence of foo. It tells the MTA that there's no account. 8. The MTA replies sender with a 550 5.1.1 f...@my.site... User unknown error. 9. After the timeout Winbind finally manages to switch to the DC B, but the sender has already got the delivery failure message and now thinks that the address f...@my.site is no longer valid. I tried to look at the documentation, but didn't find any recommendations regarding winbind cache settings in situations where availability is critical. Is it recommended to just disable all Winbind caching entirely? Or do just the opposite and try to cache as much as ever possible? What are the practical effects of winbind cache time and idmap cache time smb.conf options in this situation? Also, are the caches for all accounts replenished every time the cache of any account expires, or in per-account basis? And do the idmap cache times even work in a predictable way with this old Samba, where bug 8658 still unfixed? Or should I just try to upgrade as soon as possible? I build a test box similar to the actual box receiving mail (Winbind cache time was the default (300 seconds) and idmap cache time was set to 86,400 seconds (one day)) and flooded it with messages while at the same time switching connections to the DCs back and forth. And sure enough, I did get some delivery errors due to Winbind unavailability, if the account receiving the mail hadn't been queried after the last winbind restart and before the DC went offline. So the likelihood of the scenario 'B' feels all too great. Any recommendations for avoiding it? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Sudden authentication failures, hex dumps in log.samba
In a leap of faith, I decided to relax the iptables rules on our Samba DC (4.0.5) on Wednesday, permitting some of our production clients to actually authenticate against it (in addition to our W2k3R2 DC). After all, there are no replication errors and no errors either in log.samba or Windows event log, so things _should've_ been generally working, and various test clients also have had no problems. To limit the fallout of potential failures I chose to do this on the eve of the Ascension Day (a public holiday where I live), knowing that almost all people would be off work on the following day, and that many people would also be having an extra day off today. Alas, things didn't go entirely smoothly. One person, who had came to work on Thursday afternoon despite the holiday, complained to me that he was having login problems (wrong username or password) and that only after first (successfully) logging on to a different workstation he, on a second attempt, managed to log on to his normal workstation. He also said that these problems had been repeated this morning. Given this information, I investigated log.samba and found the following: [2013/05/09 12:39:57, 0] ../lib/util/util.c:457(dump_data) [] 00 00 00 00 62 00 00 00 00 00 00 00 20 00 20 00 b... . . [0010] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0020] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0030] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0040] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0050] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0060] 20 00 20 00 20 00 20 00 20 00 20 00 50 00 00 . . . . . .P.. That hexdump with exactly the same contents was repeated 10 times yesterday afternoon and another 31 times this morning. The times of the dumps roughly matched the times of the logon failures. Question: how much more verbosity for log.samba would be needed to further investigate this problem? I'd rather not log everything with -d10 for extended periods of time, because I really can't know how long it will take for the problem to reappear. I've now increased logging from the default level to -d3. I also wish to turn on Kerberos logging in Samba so that I could have something akin to Windows's security log and see all successful and failed login attempts. Can this be achieved by normal krb5 logging settings in krb5.conf (as described on man 3 krb5_openlog)? Any recommended logging settings? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Sudden authentication failures, hex dumps in log.samba
On 10.5.2013 14:04, Pekka L.J. Jalkanen wrote: Question: how much more verbosity for log.samba would be needed to further investigate this problem? I'd rather not log everything with -d10 for extended periods of time, because I really can't know how long it will take for the problem to reappear. I've now increased logging from the default level to -d3. -d3 logging pays off: [2013/05/10 14:31:05, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: TGS-REQ someu...@mydomain.site from ipv4:10.10.59.151:4736 for cifs/w2k3r2dc.mydomain.s...@mydomain.site [renewable, forwardable] [2013/05/10 14:31:06, 1] ../librpc/ndr/ndr.c:412(ndr_pull_error) ndr_pull_error(11): Pull bytes 2 (../librpc/ndr/ndr_basic.c:103) [2013/05/10 14:31:06, 0] ../lib/util/util.c:457(dump_data) [] 00 00 00 00 62 00 00 00 00 00 00 00 20 00 20 00 b... . . [0010] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0020] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0030] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0040] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0050] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0060] 20 00 20 00 20 00 20 00 20 00 20 00 50 00 00 . . . . . .P.. [2013/05/10 14:31:06, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: Client no longer in database: someu...@mydomain.site [2013/05/10 14:31:06, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: Failed building TGS-REP to ipv4:10.10.59.151:4736 [2013/05/10 14:31:06, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: TGS-REQ someu...@mydomain.site from ipv4:10.10.59.151:4737 for cifs/w2k3r2dc.mydomain.s...@mydomain.site [renewable, forwardable] [2013/05/10 14:31:06, 1] ../librpc/ndr/ndr.c:412(ndr_pull_error) ndr_pull_error(11): Pull bytes 2 (../librpc/ndr/ndr_basic.c:103) [2013/05/10 14:31:06, 0] ../lib/util/util.c:457(dump_data) [] 00 00 00 00 62 00 00 00 00 00 00 00 20 00 20 00 b... . . [0010] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0020] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0030] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0040] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0050] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0060] 20 00 20 00 20 00 20 00 20 00 20 00 50 00 00 . . . . . .P.. [2013/05/10 14:31:06, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: Client no longer in database: someu...@mydomain.site [2013/05/10 14:31:06, 3] ../source4/auth/kerberos/krb5_init_context.c:80(smb_krb5_debug_wrapper) Kerberos: Failed building TGS-REP to ipv4:10.10.59.151:4737 [2013/05/10 14:31:20, 3] ../source4/dsdb/repl/drepl_service.c:202(_drepl_schedule_replication) Client is Windows XP. I've yet to see this problem on newer clients... this and the other one that previously failed are the last two XP clients here that still remain in heavy production use. What is also common with this client and the other that previously failed is that they both have once been migrated from a different domain (that no longer exists) using MS ADMT. This also applies to the users' accounts that were used. Don't know if that really matters, but just for the record. Any ideas how to resolve this problem? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] Samba 3 member, winbind caching and DC availability
Hello all, I've a box running Samba 3.5.6 (Debian Squeeze) that retrieves its user accounts from AD, using Winbind. The box is receiving incoming mail. Idmap backend is AD, with rfc2307 schema mode. Currently it's only accessing one AD DC, and the MTA on the Samba box is stopped whenever the DC is temporarily offline to prevent rejection of any incoming mail with user unknown status. However, I'd like to add another DC to the mix, but I'm concerned that mail could get rejected if the active DC suddenly goes offline and winbind doesn't switch to another DC promptly enough. Consider the following scenario: 1. There is an AD account foo. The account hasn't been used for some time, and it's thus not in winbind's cache. It's possibly not even in Winbind's idmap cache. 2. There are two AD DCs, A and B. 3. Samba member server C runs Winbind and is currently using the DC A. 4. Hardware fails and the DC A suddenly drops offline. 5. Just few seconds later an e-mail is arriving for foo. The MTA tries to check for the user. 6. As Winbind is not yet aware of the unavailability of the DC A, it tries to contact it. A. Now, in the ideal world this would continue as follows: 7. Winbind can't contact the DC A anymore, so it promptly contacts the DC B. 8. The DC B confirms the existence of foo. 9. The MTA delivers mail for foo. B. However, I'm afraid that in the real world, the following could result: 7. Winbind frantically tries to contact the DC A, but timeouts and can't confirm the existence of foo. It tells the MTA that there's no account. 8. The MTA replies sender with a 550 5.1.1 f...@my.site... User unknown error. 9. After the timeout Winbind finally manages to switch to the DC B, but the sender has already got the delivery failure message and now thinks that the address f...@my.site is no longer valid. I tried to look at the documentation, but didn't find any recommendations regarding winbind cache settings in situations where availability is critical. Is it recommended to just disable all Winbind caching entirely? Or do just the opposite and try to cache as much as ever possible? What are the practical effects of winbind cache time and idmap cache time smb.conf options in this situation? Also, are the caches for all accounts replenished every time the cache of any account expires, or in per-account basis? And do the idmap cache times even work in a predictable way with this old Samba, where bug 8658 still unfixed? Or should I just try to upgrade as soon as possible? I build a test box similar to the actual box receiving mail (Winbind cache time was the default (300 seconds) and idmap cache time was set to 86,400 seconds (one day)) and flooded it with messages while at the same time switching connections to the DCs back and forth. And sure enough, I did get some delivery errors due to Winbind unavailability, if the account receiving the mail hadn't been queried after the last winbind restart and before the DC went offline. So the likelihood of the scenario 'B' feels all too great. Any recommendations for avoiding it? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] samba-tool domain exportkeytab failure
On 7.5.2013 2:32, Andrew Bartlett wrote: On Mon, 2013-05-06 at 13:41 +0300, Pekka L.J. Jalkanen wrote: On 4.5.2013 0:22, Andrew Bartlett wrote: It would be useful to know why samba-tool exportkeytab didn't work, it is tested in our make test. Perhaps run it with -d10 and see if it gives more clues? Not much--only the two lines above the hexdump: Those are the important details I needed. Excellent! :) - gendb_search_v: DC=mydomain,DC=site NULL - 1 ndr_pull_error(11): Pull bytes 2 (../librpc/ndr/ndr_basic.c:103) [] 00 00 00 00 62 00 00 00 00 00 00 00 20 00 20 00 b... . . [0010] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0020] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0030] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0040] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0050] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0060] 20 00 20 00 20 00 20 00 20 00 20 00 50 00 00 . . . . . .P.. ERROR(runtime): uncaught exception - Invalid argument File /usr/local/samba4/lib/python2.6/site-packages/samba/netcmd/__init__.py, line 175, in _run return self.run(*args, **kwargs) File /usr/local/samba4/lib/python2.6/site-packages/samba/netcmd/domain.py, line 103, in run net.export_keytab(keytab=keytab, principal=principal) The issue here is that when we migrated the key from your existing database, we were unable to read this attribute correctly. I'm surprised this works at all actually. What does 'samba-tool dbcheck' show? Zero errors (even with --cross-ncs), unless I run with --reset-well-known-acls, in which case four ACL errors are reported. But I've let those unfixed this far as I'm not sure if I'm really having any problem there or not. Windows is not complaining about any errors with sysvol or the GPOs. While I do take GPG encrypted stuff, I prefer not to unless I'm actually fixing database errors in databases or other things that would never be reproduced again. I understand your point. Sorry that can't help quickly, but if you don't see a delay of one to two months to be a problem, I can try this then. If you do, then the encryption is the only way. I'm not in terrible hurry, even if it would be nice to get this fixed. The failure to parse the keys in the supplementalCredentials attribute counts as a database error. Once we solve that, let's see what other problems we have. As you can see from my previous messages, I've rebuilt our Samba DC yesterday (and no backups of the old conf, sorry--so far I've only been backing up the Windows DC), so I hope that with that parse error you're referring just to the exportkeytab failure, as the other errors are no longer reproducible for me. If you can send me all the files (including the smb.conf) for your domain GPG encrypted I'll take a look. OK, this is what I'll do. You'll have that shortly. Pekka L.J. Jalkanen signature.asc Description: OpenPGP digital signature -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
On 4.5.2013 0:22, Andrew Bartlett wrote: On Fri, 2013-05-03 at 19:21 +0300, Pekka L.J. Jalkanen wrote: On 26.4.2013 13:05, Pekka L.J. Jalkanen wrote: So it seems that for some reason, exporting the keytab from Samba DC doesn't work. I tried to kinit first using the domain admin account, but to no avail--exportkeytab still throws the same error. Now, for the purposes of bug 9828 I could probably export it from our Windows DC using ktpass.exe, but I'd naturally like to know what's wrong here. What should I do? Am I missing something here? I forgot this for some time... as the samba-tool exportkeytab didn't work, the easiest way to get a proper keytab for decrypting the capture was apparently just copy secrets.keytab from the Samba DC and feed that file to Wireshark. At least I've now managed to decrypt the stuff myself. It would be useful to know why samba-tool exportkeytab didn't work, it is tested in our make test. Perhaps run it with -d10 and see if it gives more clues? Not much--only the two lines above the hexdump: - gendb_search_v: DC=mydomain,DC=site NULL - 1 ndr_pull_error(11): Pull bytes 2 (../librpc/ndr/ndr_basic.c:103) [] 00 00 00 00 62 00 00 00 00 00 00 00 20 00 20 00 b... . . [0010] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0020] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0030] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0040] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0050] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0060] 20 00 20 00 20 00 20 00 20 00 20 00 50 00 00 . . . . . .P.. ERROR(runtime): uncaught exception - Invalid argument File /usr/local/samba4/lib/python2.6/site-packages/samba/netcmd/__init__.py, line 175, in _run return self.run(*args, **kwargs) File /usr/local/samba4/lib/python2.6/site-packages/samba/netcmd/domain.py, line 103, in run net.export_keytab(keytab=keytab, principal=principal) - All the output right until that point consists of just LDB searches with error 0 responses, so I guess that it would not help all that much--but I can send an uncensored version to you personally, if you want to. (Not on list, because such an output lists all the accounts in the database with very detailed information, even though the most secret attributes are redacted.) However, as this is not a test domain, I can't just post such a sensitive piece of information to Bugzilla. I am, however, ready to send it in a GPG-encrypted message to Andrew (currently assigned to the bug) or another trusted Samba dev working on the bug. Would that be OK? Can you reproduce this on a test domain? That would be better. Two limitations here: 1) Replicating the exact setup would require installing another W2k3 R2 DC, which I'm unable to do (no licence). But I can, at least in theory, try to do the same thing with Win 2008 R2 (there is an evaluation version). The bug might be reproducible in such a setup, but might as well not. 2) In practice this would still be a relatively labourious procedure (needs me to install three non-production virtual machines, create a domain on Windows server, configure it to roughly match our production environment, join it with samba on Linux server, install and join a windows client, install RSAT on the client and then do the actual capture) and right now I've other more urgent priorities at work. So if I'll really have to do this it most likely won't happen until about mid-June at earliest. While I do take GPG encrypted stuff, I prefer not to unless I'm actually fixing database errors in databases or other things that would never be reproduced again. I understand your point. Sorry that can't help quickly, but if you don't see a delay of one to two months to be a problem, I can try this then. If you do, then the encryption is the only way. I'm not in terrible hurry, even if it would be nice to get this fixed. I think that the thing I'm going to try right now is to actually run the MS adprep.exe tool that ships with W2k8 R2. It should add RODC support to the schema and MS also tells to run it before installing any W2k8 DCs (RODC or not) to an existing W2k3 domain, so at least it shouldn't do any damage. If it works around this bug, all the better. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
On 6.5.2013 13:41, Pekka L.J. Jalkanen wrote: I think that the thing I'm going to try right now is to actually run the MS adprep.exe tool that ships with W2k8 R2. It should add RODC support to the schema and MS also tells to run it before installing any W2k8 DCs (RODC or not) to an existing W2k3 domain, so at least it shouldn't do any damage. If it works around this bug, all the better. I've now run the first phase of the procedure described in http://technet.microsoft.com/en-us/library/cc731243%28v=ws.10%29.aspx, i.e. the adprep /forestprep part. The tool itself ran successfully, and extended the schema with the files sch32.ldf - sch47.ldf and PAS.ldf, but it seems that now I'm having a replication problem: Windows Directory Service log: - Event Type: Error Event Source: NTDS Replication Event Category: DS RPC Client Event ID: 1411 Date: 6.5.2013 Time: 15:17:00 User: NT AUTHORITY\ANONYMOUS LOGON Computer: W2K3R2DC Description: Active Directory failed to construct a mutual authentication service principal name (SPN) for the following domain controller. Domain controller: 005c4019-c468-411d-9090-7b130c5c4fe5._msdcs.mydomain.site The call was denied. Communication with this domain controller might be affected. Additional Data Error value: 8589 The DS cannot derive a service principal name (SPN) with which to mutually authenticate the target server because the corresponding server object in the local DS database has no serverReference attribute. For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. - The error is repeated many times (at least 30). I took a look of the schema with ADSI Edit. If the active DC is the Windows DC, I can see the attribute serverReferenceBL on both DC objects. If the active DC is the Samba DC, ADSI Edit first throws an error that says Windows could not load the values for all the attributes. Error code: Xac. At the same time the familiar cannot find attr[msDS-isRODC] in of schema is seen on log.samba. After that the dialog opens, but shows all the attribute values as unset. log.samba (loglevel 0) at roughly the same time when the replication error appears in windows shows the following: - [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/replicated_objects.c:159(dsdb_repl_make_working_schema) Can't continue Schema load: didn't manage to convert any objects: all 6 remaining of 133 objects failed to convert [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/drepl_out_helpers.c:676(dreplsrv_op_pull_source_apply_changes_trigger) Failed to create working schema: WERR_INTERNAL_ERROR [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/replicated_objects.c:159(dsdb_repl_make_working_schema) Can't continue Schema load: didn't manage to convert any objects: all 6 remaining of 133 objects failed to convert [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/drepl_out_helpers.c:676(dreplsrv_op_pull_source_apply_changes_trigger) Failed to create working schema: WERR_INTERNAL_ERROR [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/replicated_objects.c:159(dsdb_repl_make_working_schema) Can't continue Schema load: didn't manage to convert any objects: all 6 remaining of 133 objects failed to convert [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/drepl_out_helpers.c:676(dreplsrv_op_pull_source_apply_changes_trigger) Failed to create working schema: WERR_INTERNAL_ERROR [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/replicated_objects.c:159(dsdb_repl_make_working_schema) Can't continue Schema load: didn't manage to convert any objects: all 6 remaining of 133 objects failed to convert [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/drepl_out_helpers.c:676(dreplsrv_op_pull_source_apply_changes_trigger) Failed to create working schema: WERR_INTERNAL_ERROR [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/drepl_out_helpers.c:705(dreplsrv_op_pull_source_apply_changes_trigger) Failed to convert objects: WERR_DS_DRA_SCHEMA_MISMATCH/NT_STATUS_INVALID_NETWORK_RESPONSE [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/drepl_out_helpers.c:705(dreplsrv_op_pull_source_apply_changes_trigger) Failed to convert objects: WERR_DS_DRA_SCHEMA_MISMATCH/NT_STATUS_INVALID_NETWORK_RESPONSE [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/replicated_objects.c:159(dsdb_repl_make_working_schema) Can't continue Schema load: didn't manage to convert any objects: all 6 remaining of 133 objects failed to convert [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/drepl_out_helpers.c:676(dreplsrv_op_pull_source_apply_changes_trigger) Failed to create working schema: WERR_INTERNAL_ERROR [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/replicated_objects.c:159(dsdb_repl_make_working_schema) Can't continue Schema load: didn't manage to convert any objects: all 6 remaining of 133 objects failed to convert [2013/05/06 15:18:09, 0] ../source4/dsdb/repl/drepl_out_helpers.c:676(dreplsrv_op_pull_source_apply_changes_trigger
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
On 6.5.2013 16:31, Pekka L.J. Jalkanen wrote: On 6.5.2013 13:41, Pekka L.J. Jalkanen wrote: I think that the thing I'm going to try right now is to actually run the MS adprep.exe tool that ships with W2k8 R2. It should add RODC support to the schema and MS also tells to run it before installing any W2k8 DCs (RODC or not) to an existing W2k3 domain, so at least it shouldn't do any damage. If it works around this bug, all the better. I've now run the first phase of the procedure described in http://technet.microsoft.com/en-us/library/cc731243%28v=ws.10%29.aspx, i.e. the adprep /forestprep part. The tool itself ran successfully, and extended the schema with the files sch32.ldf - sch47.ldf and PAS.ldf, but it seems that now I'm having a replication problem: [for actual errors, see the previous messages] There are many pages of similar errors, and Samba tries in vain to continue replication all the time. samba-tool drs showrepl is reporting increasing number of consecutive failures. I guess I'll have little alternatives to demoting and re-promoting my Samba DC again. *sigh* OK, done that now. Actually I couldn't demote using samba-tool, because the previous replication failures prevented successful demotion. So I had to delete server and computer objects manually and clean metadata using the procedure outlined in http://technet.microsoft.com/en-us/library/cc736378%28v=ws.10%29.aspx. Now, before re-installing and re-promoting the Samba DC I also ran second and third steps of the adprep procedure. Lo and behold: it works now! Can run ADSI edit (and yes, the infamous msDS-isRODC -attribute can be found there now). Can run any version of the RSAT. No errors! Now, if there only were an RSAT for Windows 8 with support for RFC 2307 attributes... Barring the immediate resolution of bug 9828 I suggest updating https://wiki.samba.org/index.php/Samba4/HOWTO/Join_a_domain_as_a_DC so that it would warn that the complete adprep procedure as described by Microsoft--including the /rodcprep part--should be run _before_ attempting samba-tool domain join with Windows 2003 -based domains, just like should be done before joining any Windows 2008 DCs. If this is not done, the DC should be demoted before the adprep is run. As this now works for me I'm not willing to build a full-scale test environment just to get bug 9828 solved, and probably even couldn't do that given the workaround stated above: It's quite clear now that the problem is reproducible only if all the Windows DCs in the domain are still 2003s. As I'm not aware of any W2k3 evaluation versions, and I don't have free licences for testing purposes, I most likely wouldn't be able to reproduce the situation. Having said that, I can still send my keytab to you, Andrew, if you feel like you want to investigate that bug anyway. Oh, and the samba-tool domain exportkeytab command still fails exactly the same way it did before. But to investigate that further I need more advice. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Recently joined 2k3, shut down primary, seized roles, now have slight dns (maybe) problem.
Caio Zanolla wrote: One more detail. When browsing Domain Controllers on AD Users and Computers it says there are no domain controllers and the folder gets an exclamation mark. Also Im not sure it should, but the samba DC is not listed on the Computers list. Hi Caio, I've no idea what part of this is due to your DNS problems, but I had a similar problem with a similar domain (Samba DC joined to old Windows 2003 domain; see Samba bug 9828), and what helped for me was to execute the same steps on my Windows DC that MS instructs you to do before adding Windows 2008 DCs to old domains. See the following links: http://technet.microsoft.com/en-us/library/cc771461%28v=ws.10%29.aspx http://technet.microsoft.com/en-us/library/cc731243%28v=ws.10%29.aspx http://blogs.technet.com/b/askds/archive/2008/11/11/so-you-want-to-upgrade-to-windows-2008-domain-controllers-adprep.aspx Note also the adprep /rodcprep part that MS lists as optional: at least in my setup Samba was specifically looking for the msDS-isRODC -attributes (evident by errors in log.samba), even though I've no RODCs. Note that for this to work I had to run these commands before adding any Samba DCs to the mix (running these afterwards just broke replication, requiring me to forcibly demote my Samba DC and run ntdsutil/metadata cleanup). So as you've already seized the operations masters roles, you might want to re-install your Windows DC, re-transfer the roles to it and demote your Samba DC(s) before trying any of this. This probably won't solve your DNS problems, though. But at least for me, it got the RSAT working. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
On 26.4.2013 13:05, Pekka L.J. Jalkanen wrote: So it seems that for some reason, exporting the keytab from Samba DC doesn't work. I tried to kinit first using the domain admin account, but to no avail--exportkeytab still throws the same error. Now, for the purposes of bug 9828 I could probably export it from our Windows DC using ktpass.exe, but I'd naturally like to know what's wrong here. What should I do? Am I missing something here? I forgot this for some time... as the samba-tool exportkeytab didn't work, the easiest way to get a proper keytab for decrypting the capture was apparently just copy secrets.keytab from the Samba DC and feed that file to Wireshark. At least I've now managed to decrypt the stuff myself. However, as this is not a test domain, I can't just post such a sensitive piece of information to Bugzilla. I am, however, ready to send it in a GPG-encrypted message to Andrew (currently assigned to the bug) or another trusted Samba dev working on the bug. Would that be OK? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
On 26.4.2013 6:13, Andrew Bartlett wrote: On Wed, 2013-04-24 at 17:39 +0300, Pekka L.J. Jalkanen wrote: By the way, is a kerberos keytab actually necessary to decrypt the GSS-API packets in Wireshark? Samba Wiki (https://wiki.samba.org/index.php/Capture_Packets) doesn't say so (just tells to capture the kerberos exchange), but I became somewhat suspicious, while reading the following page: http://wiki.wireshark.org/Kerberos Just trying to figure out how to inspect my own capture here... Yes, the whole point of GSSAPI security with Kerberos is that without super-secret-knowledge (the keytab in this case) you can't decrypt a network sniff. OK... but in that case I'm having another rather surprising problem: root@samba4dc:~# samba-tool domain exportkeytab ./dcdump.keytab [] 00 00 00 00 62 00 00 00 00 00 00 00 20 00 20 00 b... . . [0010] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0020] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0030] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0040] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0050] 20 00 20 00 20 00 20 00 20 00 20 00 20 00 20 00. . . . . . . . [0060] 20 00 20 00 20 00 20 00 20 00 20 00 50 00 00 . . . . . .P.. ERROR(runtime): uncaught exception - Invalid argument File /usr/local/samba4/lib/python2.6/site-packages/samba/netcmd/__init__.py, line 175, in _run return self.run(*args, **kwargs) File /usr/local/samba4/lib/python2.6/site-packages/samba/netcmd/domain.py, line 103, in run net.export_keytab(keytab=keytab, principal=principal) So it seems that for some reason, exporting the keytab from Samba DC doesn't work. I tried to kinit first using the domain admin account, but to no avail--exportkeytab still throws the same error. Now, for the purposes of bug 9828 I could probably export it from our Windows DC using ktpass.exe, but I'd naturally like to know what's wrong here. What should I do? Am I missing something here? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
On 23.4.2013 19:24, Michael Wood wrote: On 23 April 2013 16:43, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi wrote: Nothing. It just works. I can even explicitly change it to point to the Samba 4 DC and it still works. It is just Vista and newer RSATs that are the problem. And they also work just fine as long as the selected DC is the W2k3R2 DC... Perhaps you could get a packet capture of the newer RSAT against the Windows DC and another one against the Samba DC and attach them to a bug report. I've now filed a ticket: https://bugzilla.samba.org/show_bug.cgi?id=9828. Hopefully this helps! There is only one continuous capture, as the RSAT ADUC snap-in always seems to connect to the Windows DC first anyway (I assume that this is due to the operations master roles, because all the krb5 tickets are actually issued by the Samba DC), so if I'd try to purge krb5 tickets in-between the tests and re-connect before switching DCs to take another capture, it'd connect to the Windows DC anyway. But there are only three different IPs in the capture anyway (My RSAT box and the two DCs), and I've only captured ports 88 and 389, so it shouldn't be too hard to follow what's happening. While I do think that this is a bug I also think that I'm going to test the adprep tool anyway, as it shouldn't really damage anything... MS says that if I were to install Windows 2008 R2 DCs, I should run it anyway, so it really shouldn't hurt. Pekka L.J. Jalkanen On 23.4.2013 16:39, Hisham Attar wrote: What does it say when you browse domain controllers OU for that DC using the Ad users and computers snapin on the win2k3 dc? On Tue, Apr 23, 2013 at 11:25 PM, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi wrote: Raising the functional level above 2003 doesn't sound like a good plan as long as we still have to keep the Windows 2003 DC around. I don't know about Samba, but RSAT wouldn't even let me do that. Also note that it is the Windows DC (CN=W2K3R2DC) that doesn't have this attribute. I figured out that I should be able to download MS's adprep tools by subscribing to Windows 2008 R2 trial. If nobody has better ideas I'll just do that, and then try to run the various adprep commands. If Samba truly functions like the 2008 R2, then these tools actually should've been run anyway before adding Samba DCs to 2003 domains (see that Technet article again). I really hope that the version of Windows Samba mimics would be better documented, though... obviously none of this is a problem in a pure Samba 4 environment, but many organisations migrating from Windows to Samba are definitely not going to do so overnight, so the different DCs must co-exist for quite some time. Also, people are most likely going to run various different RSAT versions, so the compatibility of those is an important factor, too. Pekka L.J. Jalkanen On 23.4.2013 0:29, Hisham Attar wrote: That attribute is a 2008+ schema attribute, as far as I was aware when you provision with Samba your DC functionality is at 2008 R2 but forest/domain is at 2003 and can be raised to 2008 R2 try samba-tool domain level raise --domain 2008_R2 --forest 2008_R2 maybe that will add the attribute to the schema. On Tue, Apr 23, 2013 at 4:43 AM, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi wrote: Hello, We have two DCs. One runs Windows 2003 R2, and the other Samba 4.0.5. Forest functional level is Windows 2000 native. I recently demoted (worked flawlessy now, which was a great relief), rebuilt and re-promoted my Samba 4 DC, as my problems that I posted to this list about two monts were still unresolved (see https://lists.samba.org/archive/samba/2013-February/171898.html), and I thoght that I might as well give it a shot. And yes, it all seems to work now. (I even got the rfc2307 uid/gid support working, finally! Doesn't matter a lot on a DC-only box, but still.) Everything, this far, except one thing: if 1. RSAT, specifically one shipped with Windows Vista or newer (older tools do not seem to be affected) is used to manage the domain, 2. Samba 4 DC is the domain controller that RSAT's AD User and Computers console connects to, and 3. one clicks the Domain Controllers OU in the tree then the following error message will result: Data from Domain Controllers is not available from Domain Controller SAMBA4DC.mydomain.site because: An operations error occurred. Try again later, or choose
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
By the way, is a kerberos keytab actually necessary to decrypt the GSS-API packets in Wireshark? Samba Wiki (https://wiki.samba.org/index.php/Capture_Packets) doesn't say so (just tells to capture the kerberos exchange), but I became somewhat suspicious, while reading the following page: http://wiki.wireshark.org/Kerberos Just trying to figure out how to inspect my own capture here... Pekka L.J. Jalkanen On 24.4.2013 17:18, Pekka L.J. Jalkanen wrote: On 23.4.2013 19:24, Michael Wood wrote: On 23 April 2013 16:43, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi wrote: Nothing. It just works. I can even explicitly change it to point to the Samba 4 DC and it still works. It is just Vista and newer RSATs that are the problem. And they also work just fine as long as the selected DC is the W2k3R2 DC... Perhaps you could get a packet capture of the newer RSAT against the Windows DC and another one against the Samba DC and attach them to a bug report. I've now filed a ticket: https://bugzilla.samba.org/show_bug.cgi?id=9828. Hopefully this helps! There is only one continuous capture, as the RSAT ADUC snap-in always seems to connect to the Windows DC first anyway (I assume that this is due to the operations master roles, because all the krb5 tickets are actually issued by the Samba DC), so if I'd try to purge krb5 tickets in-between the tests and re-connect before switching DCs to take another capture, it'd connect to the Windows DC anyway. But there are only three different IPs in the capture anyway (My RSAT box and the two DCs), and I've only captured ports 88 and 389, so it shouldn't be too hard to follow what's happening. While I do think that this is a bug I also think that I'm going to test the adprep tool anyway, as it shouldn't really damage anything... MS says that if I were to install Windows 2008 R2 DCs, I should run it anyway, so it really shouldn't hurt. Pekka L.J. Jalkanen On 23.4.2013 16:39, Hisham Attar wrote: What does it say when you browse domain controllers OU for that DC using the Ad users and computers snapin on the win2k3 dc? On Tue, Apr 23, 2013 at 11:25 PM, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi wrote: Raising the functional level above 2003 doesn't sound like a good plan as long as we still have to keep the Windows 2003 DC around. I don't know about Samba, but RSAT wouldn't even let me do that. Also note that it is the Windows DC (CN=W2K3R2DC) that doesn't have this attribute. I figured out that I should be able to download MS's adprep tools by subscribing to Windows 2008 R2 trial. If nobody has better ideas I'll just do that, and then try to run the various adprep commands. If Samba truly functions like the 2008 R2, then these tools actually should've been run anyway before adding Samba DCs to 2003 domains (see that Technet article again). I really hope that the version of Windows Samba mimics would be better documented, though... obviously none of this is a problem in a pure Samba 4 environment, but many organisations migrating from Windows to Samba are definitely not going to do so overnight, so the different DCs must co-exist for quite some time. Also, people are most likely going to run various different RSAT versions, so the compatibility of those is an important factor, too. Pekka L.J. Jalkanen On 23.4.2013 0:29, Hisham Attar wrote: That attribute is a 2008+ schema attribute, as far as I was aware when you provision with Samba your DC functionality is at 2008 R2 but forest/domain is at 2003 and can be raised to 2008 R2 try samba-tool domain level raise --domain 2008_R2 --forest 2008_R2 maybe that will add the attribute to the schema. On Tue, Apr 23, 2013 at 4:43 AM, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi wrote: Hello, We have two DCs. One runs Windows 2003 R2, and the other Samba 4.0.5. Forest functional level is Windows 2000 native. I recently demoted (worked flawlessy now, which was a great relief), rebuilt and re-promoted my Samba 4 DC, as my problems that I posted to this list about two monts were still unresolved (see https://lists.samba.org/archive/samba/2013-February/171898.html), and I thoght that I might as well give it a shot. And yes, it all seems to work now. (I even got the rfc2307 uid/gid support working, finally! Doesn't matter a lot on a DC-only box, but still.) Everything, this far, except one thing: if 1. RSAT, specifically one shipped with Windows Vista or newer (older tools do not seem
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
Raising the functional level above 2003 doesn't sound like a good plan as long as we still have to keep the Windows 2003 DC around. I don't know about Samba, but RSAT wouldn't even let me do that. Also note that it is the Windows DC (CN=W2K3R2DC) that doesn't have this attribute. I figured out that I should be able to download MS's adprep tools by subscribing to Windows 2008 R2 trial. If nobody has better ideas I'll just do that, and then try to run the various adprep commands. If Samba truly functions like the 2008 R2, then these tools actually should've been run anyway before adding Samba DCs to 2003 domains (see that Technet article again). I really hope that the version of Windows Samba mimics would be better documented, though... obviously none of this is a problem in a pure Samba 4 environment, but many organisations migrating from Windows to Samba are definitely not going to do so overnight, so the different DCs must co-exist for quite some time. Also, people are most likely going to run various different RSAT versions, so the compatibility of those is an important factor, too. Pekka L.J. Jalkanen On 23.4.2013 0:29, Hisham Attar wrote: That attribute is a 2008+ schema attribute, as far as I was aware when you provision with Samba your DC functionality is at 2008 R2 but forest/domain is at 2003 and can be raised to 2008 R2 try samba-tool domain level raise --domain 2008_R2 --forest 2008_R2 maybe that will add the attribute to the schema. On Tue, Apr 23, 2013 at 4:43 AM, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi wrote: Hello, We have two DCs. One runs Windows 2003 R2, and the other Samba 4.0.5. Forest functional level is Windows 2000 native. I recently demoted (worked flawlessy now, which was a great relief), rebuilt and re-promoted my Samba 4 DC, as my problems that I posted to this list about two monts were still unresolved (see https://lists.samba.org/archive/samba/2013-February/171898.html), and I thoght that I might as well give it a shot. And yes, it all seems to work now. (I even got the rfc2307 uid/gid support working, finally! Doesn't matter a lot on a DC-only box, but still.) Everything, this far, except one thing: if 1. RSAT, specifically one shipped with Windows Vista or newer (older tools do not seem to be affected) is used to manage the domain, 2. Samba 4 DC is the domain controller that RSAT's AD User and Computers console connects to, and 3. one clicks the Domain Controllers OU in the tree then the following error message will result: Data from Domain Controllers is not available from Domain Controller SAMBA4DC.mydomain.site because: An operations error occurred. Try again later, or choose another DC by selecting Connect to Domain Controller on the Domain context menu. At the same time the following is written to log.samba: [2013/04/17 18:03:24, 0] ../lib/ldb-samba/ldb_wrap.c:69(ldb_wrap_debug) ldb: acl_read: CN=W2K3R2DC,OU=Domain Controllers,DC=mydomain,DC=site cannot find attr[msDS-isRODC] in of schema If the RSAT's AD Users Computers console is deliberately changed to use our Windows DC, the problem disappears. The console reports DC version for the domain controllers as W2K3 for the Windows DC and as W2K for the Samba DC. Is this error expected? I find the error message in log.samba a bit peculiar, because it talks about msDS-isRODC attribute. But the way I see it there shouldn't even be anything RODC-related in the schema, as a prerequisite for any RODCs is Windows 2003 forest functional level, and even then the schema should be extended first (see http://technet.microsoft.com/en-us/library/cc731243%28v=ws.10%29.aspx for Microsoft's documentation). Because Samba doesn't really seem to support Windows 2000 functional level properly anymore (samba-tool domain level just showed the following error: ERROR: Could not retrieve the actual domain, forest level and/or lowest DC function level!), and we no longer had real reasons to stick to that, I tried to promote the forest. Now that failed too, and I had to demote Samba (so that Windows doesn't think it is just a W2k box), raise forest level on Windows, and then purge Samba's config and re-join it. (Simply running samba-tool domain dcpromo doesn't work either--it just gives an error Account SAMBA4DC$ appears to be an active DC, use 'samba-tool domain join' if you must re-create this account.) But: now the forest functional level *is* Windows 2003, RSAT AD User Computers reports the Samba DC as W2k8 R2, and all this still didn't affect the actual RSAT / ldb: acl_read error at all. The issue is still reproducible! I don't know if running the MS adprep tool on the Windows DC would help
Re: [Samba] New Windows 8 RSAT and OU=Domain Controllers support?
Nothing. It just works. I can even explicitly change it to point to the Samba 4 DC and it still works. It is just Vista and newer RSATs that are the problem. And they also work just fine as long as the selected DC is the W2k3R2 DC... Pekka L.J. Jalkanen On 23.4.2013 16:39, Hisham Attar wrote: What does it say when you browse domain controllers OU for that DC using the Ad users and computers snapin on the win2k3 dc? On Tue, Apr 23, 2013 at 11:25 PM, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi wrote: Raising the functional level above 2003 doesn't sound like a good plan as long as we still have to keep the Windows 2003 DC around. I don't know about Samba, but RSAT wouldn't even let me do that. Also note that it is the Windows DC (CN=W2K3R2DC) that doesn't have this attribute. I figured out that I should be able to download MS's adprep tools by subscribing to Windows 2008 R2 trial. If nobody has better ideas I'll just do that, and then try to run the various adprep commands. If Samba truly functions like the 2008 R2, then these tools actually should've been run anyway before adding Samba DCs to 2003 domains (see that Technet article again). I really hope that the version of Windows Samba mimics would be better documented, though... obviously none of this is a problem in a pure Samba 4 environment, but many organisations migrating from Windows to Samba are definitely not going to do so overnight, so the different DCs must co-exist for quite some time. Also, people are most likely going to run various different RSAT versions, so the compatibility of those is an important factor, too. Pekka L.J. Jalkanen On 23.4.2013 0:29, Hisham Attar wrote: That attribute is a 2008+ schema attribute, as far as I was aware when you provision with Samba your DC functionality is at 2008 R2 but forest/domain is at 2003 and can be raised to 2008 R2 try samba-tool domain level raise --domain 2008_R2 --forest 2008_R2 maybe that will add the attribute to the schema. On Tue, Apr 23, 2013 at 4:43 AM, Pekka L.J. Jalkanen pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi mailto:pekka.jalka...@vihreat.fi wrote: Hello, We have two DCs. One runs Windows 2003 R2, and the other Samba 4.0.5. Forest functional level is Windows 2000 native. I recently demoted (worked flawlessy now, which was a great relief), rebuilt and re-promoted my Samba 4 DC, as my problems that I posted to this list about two monts were still unresolved (see https://lists.samba.org/archive/samba/2013-February/171898.html), and I thoght that I might as well give it a shot. And yes, it all seems to work now. (I even got the rfc2307 uid/gid support working, finally! Doesn't matter a lot on a DC-only box, but still.) Everything, this far, except one thing: if 1. RSAT, specifically one shipped with Windows Vista or newer (older tools do not seem to be affected) is used to manage the domain, 2. Samba 4 DC is the domain controller that RSAT's AD User and Computers console connects to, and 3. one clicks the Domain Controllers OU in the tree then the following error message will result: Data from Domain Controllers is not available from Domain Controller SAMBA4DC.mydomain.site because: An operations error occurred. Try again later, or choose another DC by selecting Connect to Domain Controller on the Domain context menu. At the same time the following is written to log.samba: [2013/04/17 18:03:24, 0] ../lib/ldb-samba/ldb_wrap.c:69(ldb_wrap_debug) ldb: acl_read: CN=W2K3R2DC,OU=Domain Controllers,DC=mydomain,DC=site cannot find attr[msDS-isRODC] in of schema If the RSAT's AD Users Computers console is deliberately changed to use our Windows DC, the problem disappears. The console reports DC version for the domain controllers as W2K3 for the Windows DC and as W2K for the Samba DC. Is this error expected? I find the error message in log.samba a bit peculiar, because it talks about msDS-isRODC attribute. But the way I see it there shouldn't even be anything RODC-related in the schema, as a prerequisite for any RODCs is Windows 2003 forest functional level, and even then the schema should be extended first (see http://technet.microsoft.com/en-us/library/cc731243%28v=ws.10%29.aspx
[Samba] New Windows 8 RSAT and OU=Domain Controllers support?
Hello, We have two DCs. One runs Windows 2003 R2, and the other Samba 4.0.5. Forest functional level is Windows 2000 native. I recently demoted (worked flawlessy now, which was a great relief), rebuilt and re-promoted my Samba 4 DC, as my problems that I posted to this list about two monts were still unresolved (see https://lists.samba.org/archive/samba/2013-February/171898.html), and I thoght that I might as well give it a shot. And yes, it all seems to work now. (I even got the rfc2307 uid/gid support working, finally! Doesn't matter a lot on a DC-only box, but still.) Everything, this far, except one thing: if 1. RSAT, specifically one shipped with Windows Vista or newer (older tools do not seem to be affected) is used to manage the domain, 2. Samba 4 DC is the domain controller that RSAT's AD User and Computers console connects to, and 3. one clicks the Domain Controllers OU in the tree then the following error message will result: Data from Domain Controllers is not available from Domain Controller SAMBA4DC.mydomain.site because: An operations error occurred. Try again later, or choose another DC by selecting Connect to Domain Controller on the Domain context menu. At the same time the following is written to log.samba: [2013/04/17 18:03:24, 0] ../lib/ldb-samba/ldb_wrap.c:69(ldb_wrap_debug) ldb: acl_read: CN=W2K3R2DC,OU=Domain Controllers,DC=mydomain,DC=site cannot find attr[msDS-isRODC] in of schema If the RSAT's AD Users Computers console is deliberately changed to use our Windows DC, the problem disappears. The console reports DC version for the domain controllers as W2K3 for the Windows DC and as W2K for the Samba DC. Is this error expected? I find the error message in log.samba a bit peculiar, because it talks about msDS-isRODC attribute. But the way I see it there shouldn't even be anything RODC-related in the schema, as a prerequisite for any RODCs is Windows 2003 forest functional level, and even then the schema should be extended first (see http://technet.microsoft.com/en-us/library/cc731243%28v=ws.10%29.aspx for Microsoft's documentation). Because Samba doesn't really seem to support Windows 2000 functional level properly anymore (samba-tool domain level just showed the following error: ERROR: Could not retrieve the actual domain, forest level and/or lowest DC function level!), and we no longer had real reasons to stick to that, I tried to promote the forest. Now that failed too, and I had to demote Samba (so that Windows doesn't think it is just a W2k box), raise forest level on Windows, and then purge Samba's config and re-join it. (Simply running samba-tool domain dcpromo doesn't work either--it just gives an error Account SAMBA4DC$ appears to be an active DC, use 'samba-tool domain join' if you must re-create this account.) But: now the forest functional level *is* Windows 2003, RSAT AD User Computers reports the Samba DC as W2k8 R2, and all this still didn't affect the actual RSAT / ldb: acl_read error at all. The issue is still reproducible! I don't know if running the MS adprep tool on the Windows DC would help (see the Technet article linked above), but that tool is anyway only shipped with Windows 2008, and I don't have that. Should I file a bug? Or is this error expected? Any experiences by people who regularly run newer RSATs? What about those that also have Windows DCs, like me? Thanks, Pekka L.J. Jalkanen PS. The Win 8 RSAT that I've been trying to use is actually hugely problematic, because there is no way to install the Server for NIS tools that are required for RFC2307 management, even though MS does claim (http://support.microsoft.com/kb/2693643) that those tools are still supported. I can't recommend it to anyone. -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Synchronising password of some AD users with an external LDAP?
On 26.2.2013 23:34, Andrew Bartlett wrote: On Tue, 2013-02-26 at 18:16 +0200, Pekka L.J. Jalkanen wrote: True, webservers can authenticate against AD in a similar fashion to other LDAPs. But that's not the whole story. The thing is that Samba 4 is designed from a ground up with AD in mind, and AD itself has been designed with workstation authentication and NT4 client compatibility in mind. All this adds a lot of complexity to the system--and to the schema itself--that isn't in my opinion really benefical. Also, manually editing the AD schema, and especially removing objectclasses and/or attributes from the default schema, is generally regarded as a big no-no. If I'd have to do this with AD, I'd use AD LDS, but that isn't an option with Samba (which is perfectly understandable, as on Linux, unlike Windows, there are many alternatives). However, after a lot of googling it appears that there should be a way to make OpenLDAP to accept simple binds both with and without kerberos backing, using SASL as an authentication vehicle: http://www.openldap.org/lists/openldap-software/201002/threads.html#3 Perhaps I'll try that route. So to avoid your perceived complexity of the Samba 4.0 AD DC, you instead want to build a private and even more complex arrangement with synchronisation between multiple directories? It may sound strange but this is really only about potentially enabling 30+ users to log to the LDAP using their AD passwords, while the total amount of users in the LDAP could well end up being several hundreds if not even thousands. But if it seems that this ends up being too complex, then I'll simply scrap that plan and force two different passwords for these users. I do understand that in your opinion just putting up a Samba subdomain would do, but while no longer in beta, Samba 4 still isn't all that mature product, and should problems arise... well, I simply am not such an expert with it as you very obviously are, so I'd rather err on the safe side and risk having 30 users with minor authentication annoyances than having 1,000 users that can't log in at all. Anyway, currently the only way to get a cleartext password out of Samba 4.0 as an AD DC is to permit storage of cleartext passwords in the password policy and set it per-user. Then a tool (not yet written) could extract these from Samba. Thanks! I don't really think that I'm willing to go down that route, but it's still good to know what's actually possible and what isn't. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Recommended Upgrade technique for 4.0.3 (was Re: Should I run dbcheck and sysvolreset when upgrading 4.0.0 to 4.0.3?)
On 26.2.2013 23:53, Andrew Bartlett wrote:
On Tue, 2013-02-26 at 13:36 +0200, Pekka L.J. Jalkanen wrote:
On Sat, 2013-02-16 Andrew Bartlett wrote:
On Sat, 2013-02-16 at 12:55 +1100, Andrew Bartlett wrote:
On Fri, 2013-02-15 at 12:52 +1100, Andrew Bartlett wrote:
On Thu, 2013-02-14 at 20:50 -0500, Thomas Simmons wrote:
Thank you, Andrew. Just to be clear, you're saying I can upgrade to 4.0.3
(but do nothing after make install)? If it will make things worse in any
way, I can stay at 4.0.0. Thanks, Thomas.
It's fine to upgrade. That protects you against the security issue we
fixed in 4.0.1, and makes a significant number of other fixes.
My current testing shows that:
samba_upgradeprovision --full
dbcheck --cross-ncs [--fix [--yes]]
Will break some ACLs on DNS, and not fix one of the ACLs on the DC's own
LDAP object. The --full is important, without that the result is
actually worse (as far as I can tell).
I would like to make some progress on this before I recommend it as the
final solution.
It is however pretty close, and better than what is in the database
right now.
I retract any advise to run this tool. I hope to have patches soon, but
for the moment it treats any beta or release version as being *before*
alpha9. Essentially we have been caught out by a regex that never
expected Samba to move beyond endless alphas :-)
Please do not run samba_upgradeprovision under any circumstances, until
I have tested patches to fix this.
Since the discussion on samba-technical gave somehow mixed
recommendations about whether it should be run or not, I had attempted
to run it anyway, when I upgraded my installation from 4.0.0 to 4.0.3.
NO!
Please don't panic: like I said, I already tried it, so it's too late
for remorse now. And even if I were to lose this specific DC completely,
it would still not be a catastrophe. Extra work though, sure.
At this point I've tried to be very clear, and I'm not sure what
part of what I've said above was not clear.
Everything what you wrote above was very, very clear, but perhaps I
wasn't that clear when I said that I only found about this thread after
the upgrade. In short: I upgraded before I had read what you said.
Who suggested you should run this tool?
I think that after reading your message on samba-technical (see
https://lists.samba.org/archive/samba-technical/2013-February/090442.html)
I thought that, OK, there are some problems, but also thought that at
worst I may lose some ACLs, and I wasn't too worried about that. I also
somehow thought that I either have to run this tool, or stick with
4.0.2. I know better now, but what's done is done.
I
figured out that as I'm having some problems with my group policies
anyway, and am not generally using them, it shouldn't hurt too much.
(Back then, I had missed this thread, as I had mistakenly only followed
the samba-technical list.)
See above: I simply hadn't read your advise here before upgrading. So
don't feel bad here: it's my fault, not yours.
Here are my experiences:
-- cut --
Third, it finally didn't run at all, as it stated that multiple DC
setups aren't supported. This wasn't stated anywhere in advance. The
command doesn't have a manpage, and --help switch doesn't give any
clue what the command is actually supposed to do.
This is an extra safety check we added. But the lack of clear
documentation on this is one of the many reasons why I'm now of a mind
to remove this tool until it meets these and many other standards.
That would probably be a good move. At least that would be one count
less with virtually undocumented things in Samba 4 (there still would be
others left, but I guess that's another topic).
So in the end I didn't run it at all, as it can only be run in single DC
setups. But I did run the ldbadd command, and don't know how serious
mistake that was.
Afterwards, I tried to run samba-tool dbcheck --cross-ncs --fix, and
unlike in 4.0.0, it didn't manage to fix everything:
-- cut --
Failed to correct missing instanceType on CN=RID Set,CN=W2K3DC,OU=Domain
Controllers,DC=mydomain,DC=site by setting instanceType=4 : (65,
objectclass_attrs: at least one mandatory attribute ('rIDNextRID') on
entry 'CN=RID Set,CN=W2K3DC,OU=Domain Controllers,DC=mydomain,DC=site'
wasn't specified!)
-- cut --
This is a concern, and looks like it was initially due to an incorrect
implementation of the instanceType check in the dbcheck shipped with
4.0.0, after your domain was imported from a Windows 2000 level domain.
Can you give me some more detail on this history of this domain?
It's a long story, but I'll try to be brief.
It's originally a one-DC Windows 2003 R2 domain, with which I've been
trying to use S4 since beta 2 or so. But most of the time I've kept it
firewalled so that only our Windows DC and a handful of clients are
actually allowed to communicate with it; the rest of the clients are
still using the Windows DC exclusively. I've
Re: [Samba] Recommended Upgrade technique for 4.0.3 (was Re: Should I run dbcheck and sysvolreset when upgrading 4.0.0 to 4.0.3?)
On Sat, 2013-02-16 Andrew Bartlett wrote:
On Sat, 2013-02-16 at 12:55 +1100, Andrew Bartlett wrote:
On Fri, 2013-02-15 at 12:52 +1100, Andrew Bartlett wrote:
On Thu, 2013-02-14 at 20:50 -0500, Thomas Simmons wrote:
Thank you, Andrew. Just to be clear, you're saying I can upgrade to 4.0.3
(but do nothing after make install)? If it will make things worse in any
way, I can stay at 4.0.0. Thanks, Thomas.
It's fine to upgrade. That protects you against the security issue we
fixed in 4.0.1, and makes a significant number of other fixes.
My current testing shows that:
samba_upgradeprovision --full
dbcheck --cross-ncs [--fix [--yes]]
Will break some ACLs on DNS, and not fix one of the ACLs on the DC's own
LDAP object. The --full is important, without that the result is
actually worse (as far as I can tell).
I would like to make some progress on this before I recommend it as the
final solution.
It is however pretty close, and better than what is in the database
right now.
I retract any advise to run this tool. I hope to have patches soon, but
for the moment it treats any beta or release version as being *before*
alpha9. Essentially we have been caught out by a regex that never
expected Samba to move beyond endless alphas :-)
Please do not run samba_upgradeprovision under any circumstances, until
I have tested patches to fix this.
Since the discussion on samba-technical gave somehow mixed
recommendations about whether it should be run or not, I had attempted
to run it anyway, when I upgraded my installation from 4.0.0 to 4.0.3. I
figured out that as I'm having some problems with my group policies
anyway, and am not generally using them, it shouldn't hurt too much.
(Back then, I had missed this thread, as I had mistakenly only followed
the samba-technical list.)
Here are my experiences:
First, the command failed with python errors because I don't run DNS in
my AD, and as such didn't have DnsAdmins group. I then went on to create
the said group.
Second, it asked me to run the following command, and then re-run it:
ldbadd -H /usr/local/samba/private/sam.ldb /tmp/usnprovTuWu85dif
I ran it. Don't know exactly what it did, but I didn't get any errors.
Third, it finally didn't run at all, as it stated that multiple DC
setups aren't supported. This wasn't stated anywhere in advance. The
command doesn't have a manpage, and --help switch doesn't give any
clue what the command is actually supposed to do.
So in the end I didn't run it at all, as it can only be run in single DC
setups. But I did run the ldbadd command, and don't know how serious
mistake that was.
Afterwards, I tried to run samba-tool dbcheck --cross-ncs --fix, and
unlike in 4.0.0, it didn't manage to fix everything:
Checking 3378 objects
ERROR: wrong instanceType 0 on CN=RID Set,CN=W2K3DC,OU=Domain
Controllers,DC=mydomain,DC=site, should be 4
Change instanceType from 0 to 4 on CN=RID Set,CN=W2K3DC,OU=Domain
Controllers,DC=mydomain,DC=site? [y/N/all/none] all
Failed to correct missing instanceType on CN=RID Set,CN=W2K3DC,OU=Domain
Controllers,DC=mydomain,DC=site by setting instanceType=4 : (65,
objectclass_attrs: at least one mandatory attribute ('rIDNextRID') on
entry 'CN=RID Set,CN=W2K3DC,OU=Domain Controllers,DC=mydomain,DC=site'
wasn't specified!)
ERROR: wrong instanceType 0 on CN=RID Set,CN=SAMBA4DC,OU=Domain
Controllers,DC=mydomain,DC=site, should be 4
Change instanceType from 0 to 4 on CN=RID Set,CN=SAMBA4DC,OU=Domain
Controllers,DC=mydomain,DC=site? [YES]
Failed to correct missing instanceType on CN=RID
Set,CN=SAMBA4DC,OU=Domain Controllers,DC=mydomain,DC=site by setting
instanceType=4 : (65, objectclass_attrs: at least one mandatory
attribute ('rIDNextRID') on entry 'CN=RID Set,CN=SAMBA4DC,OU=Domain
Controllers,DC=mydomain,DC=site' wasn't specified!)
Checked 3378 objects (0 errors)
Don't know if I should be worried about these errors, though, or whether
they have anything to do with my mistaken ldbadd command.
Pekka L.J. Jalkanen
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
[Samba] Synchronising password of some AD users with an external LDAP?
I'm in a situation where I should establish an external (i.e. non-AD) LDAP directory for my employer for various web-based authentication purposes. I don't think that Samba--or Windows AD, for that matter--in and itself would be the best tool for this purpose; so far I've been reviewing 389 DS, ApacheDS, OpenDJ and plain old OpenLDAP, but have made no final decision yet. Now however, it would be beneficial, even if not strictly speaking necessary, if I could automatically synchronise the passwords of certain accounts between that LDAP and our AD; most sensible solution here would probably be to do it between the LDAP users having a corresponding AD account belonging to a specific AD OU. Other than passwords, the accounts and their attributes themselves should stay separate. I know that if I were running a Windows AD, I could most likely accomplish what I want with--if nothing else--the 389 DS by using DS-provided Password Sync Service (see https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Windows_Sync-Configuring_Windows_Sync.html for more information). However, our goal is to completely migrate our AD to Samba 4, so committing to any software that depends on the continued availability of a Windows DC simply won't do. How could I accomplish this synchronisation with Samba 4? Can anyone nudge me to the right direction? Or is possible at all? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Synchronising password of some AD users with an external LDAP?
True, webservers can authenticate against AD in a similar fashion to other LDAPs. But that's not the whole story. The thing is that Samba 4 is designed from a ground up with AD in mind, and AD itself has been designed with workstation authentication and NT4 client compatibility in mind. All this adds a lot of complexity to the system--and to the schema itself--that isn't in my opinion really benefical. Also, manually editing the AD schema, and especially removing objectclasses and/or attributes from the default schema, is generally regarded as a big no-no. If I'd have to do this with AD, I'd use AD LDS, but that isn't an option with Samba (which is perfectly understandable, as on Linux, unlike Windows, there are many alternatives). However, after a lot of googling it appears that there should be a way to make OpenLDAP to accept simple binds both with and without kerberos backing, using SASL as an authentication vehicle: http://www.openldap.org/lists/openldap-software/201002/threads.html#3 Perhaps I'll try that route. Pekka L.J. Jalkanen On 26.2.2013 16:13, Daniel Müller wrote: Apache can authenticate against samba4 ads the same way as if it were openldap. http://wiki.samba.org/index.php/Samba4/beyond Good Luck Daniel --- EDV Daniel Müller Leitung EDV Tropenklinik Paul-Lechler-Krankenhaus Paul-Lechler-Str. 24 72076 Tübingen Tel.: 07071/206-463, Fax: 07071/206-499 eMail: muel...@tropenklinik.de Internet: www.tropenklinik.de --- -Ursprüngliche Nachricht- Von: samba-boun...@lists.samba.org [mailto:samba-boun...@lists.samba.org] Im Auftrag von Pekka L.J. Jalkanen Gesendet: Dienstag, 26. Februar 2013 15:01 An: samba@lists.samba.org Betreff: [Samba] Synchronising password of some AD users with an external LDAP? I'm in a situation where I should establish an external (i.e. non-AD) LDAP directory for my employer for various web-based authentication purposes. I don't think that Samba--or Windows AD, for that matter--in and itself would be the best tool for this purpose; so far I've been reviewing 389 DS, ApacheDS, OpenDJ and plain old OpenLDAP, but have made no final decision yet. Now however, it would be beneficial, even if not strictly speaking necessary, if I could automatically synchronise the passwords of certain accounts between that LDAP and our AD; most sensible solution here would probably be to do it between the LDAP users having a corresponding AD account belonging to a specific AD OU. Other than passwords, the accounts and their attributes themselves should stay separate. I know that if I were running a Windows AD, I could most likely accomplish what I want with--if nothing else--the 389 DS by using DS-provided Password Sync Service (see https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/ html/Administration_Guide/Windows_Sync-Configuring_Windows_Sync.html for more information). However, our goal is to completely migrate our AD to Samba 4, so committing to any software that depends on the continued availability of a Windows DC simply won't do. How could I accomplish this synchronisation with Samba 4? Can anyone nudge me to the right direction? Or is possible at all? Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] Synchronising password of some AD users with an external LDAP?
On 26.2.2013 17:16, Gregory Sloop wrote: PLJJ I know that if I were running a Windows AD, I could most likely PLJJ accomplish what I want with--if nothing else--the 389 DS by using PLJJ DS-provided Password Sync Service (see PLJJ https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Directory_Server/9.0/html/Administration_Guide/Windows_Sync-Configuring_Windows_Sync.html PLJJ for more information). This is way over my head, in terms of expertise - but since the AD should function identically to the Windows AD setup, it may well work just fine, even though the back-end isn't a Windows AD box, but a Samba4 AD. Read the guide on the page that I linked. The said Password Sync Service is a Windows application. It installs a new password filtering DLL and a system service to a Windows DC. Samba, on the other hand, hardly runs on Windows. And even if it can be run (by compiling under Cygwin, perhaps?) it would be rather pointless. Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
Re: [Samba] make install fails, can't link libreplace.inst.so [SOLVED]
For the record: Stupid, really, but I simply didn't have enough memory.
I had a small virtual test box, with merely 256 MiB of RAM. When I
increased that to 512, make install ran without a fuzz.
It took me several days to solve. Only, when I finally in my desperation
(after testing all possible library combinations) attempted to run make
test, I got an error that clearly informed me that no more memory could
be allocated.
Pekka
On 30.7.2012 20:32, Pekka L.J. Jalkanen wrote:
I can compile Samba4 beta 4, but can't install it:
root@samba4dc:/usr/src/samba-4.0.0beta4# ./configure.developer
snip
'configure' finished successfully (49.871s)
root@samba4dc:/usr/src/samba-4.0.0beta4# make
WAF_MAKE=1 ./buildtools/bin/waf build
snip
Waf: Leaving directory `/usr/src/samba-4.0.0beta4/bin'
'build' finished successfully (13m25.444s)
root@samba4dc:/usr/src/samba-4.0.0beta4# make install
WAF_MAKE=1 ./buildtools/bin/waf install
Waf: Entering directory `/usr/src/samba-4.0.0beta4/bin'
* creating /usr/local/samba/etc
* creating /usr/local/samba/private
* creating /usr/local/samba/var
* creating /usr/local/samba/private
* creating /usr/local/samba/var/lib
* creating /usr/local/samba/var/locks
* creating /usr/local/samba/var/cache
* creating /usr/local/samba/var/lock
* creating /usr/local/samba/var/run
* creating /usr/local/samba/var/run
Selected embedded Heimdal build
Checking project rules ...
Project rules pass
[ 129/4246] Linking default/lib/replace/libreplace.inst.so
Waf: Leaving directory `/usr/src/samba-4.0.0beta4/bin'
Build failed: - task failed (err #-1):
{task: cc_link replace_2.o,getpass_2.o - libreplace.inst.so}
make: *** [install] Error 1
Could anybody help me to figure out how to diagnose this problem?
The example above is from a tarball source, but the same first happened
with git source (git checkout samba-4.0.0beta4).
Pekka L.J. Jalkanen
--
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 install fails, no matter what I do [SOLVED]
This was a simple memory allocation problem, and entirely my own fallacy. For details, see https://lists.samba.org/archive/samba/2012-August/168709.html Pekka On 31.7.2012 15:32, Pekka L.J. Jalkanen wrote: I can't install Samba 4 in practically any fashion. I've tried Debian packages without much success (see https://lists.samba.org/archive/samba-technical/2012-July/085301.html) I later on figured out that it is not possible to use those packages without using ntvfs (see http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679678). I've attempted to compile it from source under Debian Squeeze, but while it indeed compiles, make install doesn't succeed (see the message I posted on this list yesterday: https://lists.samba.org/archive/samba/2012-July/168490.html) I've now installed a new VM from scratch running Debian Wheezy to test S4 under that, but make install didn't succeed that way either. I've now attached to this message a complete log of everything that I've done in hope that somebody could help me understand why on earth it doesn't work. Surely Samba 4 should be at least installable under Debian; it's not, after all, an alpha release any more... Pekka L.J. Jalkanen -- To unsubscribe from this list go to the following URL and read the instructions: https://lists.samba.org/mailman/options/samba
[Samba] make install fails, can't link libreplace.inst.so
I can compile Samba4 beta 4, but can't install it:
root@samba4dc:/usr/src/samba-4.0.0beta4# ./configure.developer
snip
'configure' finished successfully (49.871s)
root@samba4dc:/usr/src/samba-4.0.0beta4# make
WAF_MAKE=1 ./buildtools/bin/waf build
snip
Waf: Leaving directory `/usr/src/samba-4.0.0beta4/bin'
'build' finished successfully (13m25.444s)
root@samba4dc:/usr/src/samba-4.0.0beta4# make install
WAF_MAKE=1 ./buildtools/bin/waf install
Waf: Entering directory `/usr/src/samba-4.0.0beta4/bin'
* creating /usr/local/samba/etc
* creating /usr/local/samba/private
* creating /usr/local/samba/var
* creating /usr/local/samba/private
* creating /usr/local/samba/var/lib
* creating /usr/local/samba/var/locks
* creating /usr/local/samba/var/cache
* creating /usr/local/samba/var/lock
* creating /usr/local/samba/var/run
* creating /usr/local/samba/var/run
Selected embedded Heimdal build
Checking project rules ...
Project rules pass
[ 129/4246] Linking default/lib/replace/libreplace.inst.so
Waf: Leaving directory `/usr/src/samba-4.0.0beta4/bin'
Build failed: - task failed (err #-1):
{task: cc_link replace_2.o,getpass_2.o - libreplace.inst.so}
make: *** [install] Error 1
Could anybody help me to figure out how to diagnose this problem?
The example above is from a tarball source, but the same first happened
with git source (git checkout samba-4.0.0beta4).
Pekka L.J. Jalkanen
--
To unsubscribe from this list go to the following URL and read the
instructions: https://lists.samba.org/mailman/options/samba
