Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
[Samba] New Windows 8 RSAT and "OU=Domain Controllers" support?
144 views
Skip to first unread message
Pekka L.J. Jalkanen
Apr 22, 2013, 3:00:01 PM4/22/13
to
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
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
Hisham Attar
Apr 22, 2013, 5:30:02 PM4/22/13
to
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.
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.
Pekka L.J. Jalkanen
Apr 23, 2013, 9:30:01 AM4/23/13
to
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
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
Hisham Attar
Apr 23, 2013, 9:50:01 AM4/23/13
to
What does it say when you browse domain controllers OU for that DC using
the Ad users and computers snapin on the win2k3 dc?
the Ad users and computers snapin on the win2k3 dc?
Pekka L.J. Jalkanen
Apr 23, 2013, 10:50:02 AM4/23/13
to
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
> <mailto:pekka.j...@vihreat.fi
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
Michael Wood
Apr 23, 2013, 12:30:02 PM4/23/13
to
On 23 April 2013 16:43, Pekka L.J. Jalkanen <pekka.j...@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
> 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...
Windows DC and another one against the Samba DC and attach them to a
bug report.
Michael Wood <esio...@gmail.com>
Pekka L.J. Jalkanen
Apr 24, 2013, 10:20:02 AM4/24/13
to
On 23.4.2013 19:24, Michael Wood wrote:
> On 23 April 2013 16:43, Pekka L.J. Jalkanen <pekka.j...@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:
> On 23 April 2013 16:43, Pekka L.J. Jalkanen <pekka.j...@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.
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
Apr 24, 2013, 10:50:02 AM4/24/13
to
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
Pekka L.J. Jalkanen, pekka.j...@vihreat.fi, +358-44-5510534
Vihreät / De Gröna, http://www.vihreat.fi/
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
Vihreät / De Gröna, http://www.vihreat.fi/
Andrew Bartlett
Apr 25, 2013, 11:20:02 PM4/25/13
to
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
> 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...
super-secret-knowledge (the keytab in this case) you can't decrypt a
network sniff.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Pekka L.J. Jalkanen
Apr 26, 2013, 6:10:01 AM4/26/13
to
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:
> 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.
root@samba4dc:~# samba-tool domain exportkeytab ./dcdump.keytab
[0000] 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
Pekka L.J. Jalkanen
May 3, 2013, 12:30:02 PM5/3/13
to
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
>
> 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?
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?
Andrew Bartlett
May 3, 2013, 5:30:02 PM5/3/13
to
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
> 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.
is tested in our make test. Perhaps run it with -d10 and see if it
gives more clues?
> 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?
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.
Andrew Bartlett
--
Andrew Bartlett http://samba.org/~abartlet/
Authentication Developer, Samba Team http://samba.org
Pekka L.J. Jalkanen
May 6, 2013, 6:50:01 AM5/6/13
to
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:
> 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?
-----
gendb_search_v: DC=mydomain,DC=site NULL -> 1
ndr_pull_error(11): Pull bytes 2 (../librpc/ndr/ndr_basic.c:103)
[0000] 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)
-----
[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.
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.
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
Pekka L.J. Jalkanen
May 6, 2013, 9:40:02 AM5/6/13
to
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
> 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.
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)
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:10, 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:10, 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:10, 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:10, 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:10, 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:10, 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:10, 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:10, 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:10, 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:10, 0]
../source4/dsdb/repl/drepl_out_helpers.c:676(dreplsrv_op_pull_source_apply_changes_trigger)
Failed to create working schema: WERR_INTERNAL_ERROR
-----
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*
Pekka L.J. Jalkanen
May 6, 2013, 12:10:01 PM5/6/13
to
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]
> 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:
> 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*
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.
Andrew Bartlett
May 6, 2013, 7:40:01 PM5/6/13
to
On Mon, 2013-05-06 at 13:41 +0300, Pekka L.J. Jalkanen wrote:
> 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:
Those are the important details I needed.
> 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)
> [0000] 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)
database, we were unable to read this attribute correctly. I'm
surprised this works at all actually.
What does 'samba-tool dbcheck' show?
> > 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.
counts as a database error. Once we solve that, let's see what other
problems we have.
If you can send me all the files (including the smb.conf) for your
domain GPG encrypted I'll take a look. My current GPG fingerprint is
below:
pub 4096R/C8021865 2012-07-04 [expires: 2018-07-03]
Key fingerprint = 8160 9BF8 5375 BA5E 510C CEA1 FE00 1D44 C802
1865
uid Andrew Bartlett <abar...@ozlabs.org>
uid Andrew Bartlett <abar...@samba.org>
uid Andrew Bartlett <abar...@abartlet.net>
sub 4096R/D899268D 2012-07-04 [expires: 2018-07-03]
Pekka L.J. Jalkanen
May 7, 2013, 7:00:02 AM5/7/13
to
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! :)
> 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.
>> -----
>>
>> gendb_search_v: DC=mydomain,DC=site NULL -> 1
>> ndr_pull_error(11): Pull bytes 2 (../librpc/ndr/ndr_basic.c:103)
>> [0000] 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?
--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.
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.
Pekka L.J. Jalkanen
0 new messages