Author Topic: AD synch and ad-migrate script - both failing  (Read 3509 times)

AlecM

  • Zen Apprentice
  • *
  • Posts: 8
  • Karma: +0/-0
    • View Profile
AD synch and ad-migrate script - both failing
« on: June 20, 2017, 12:36:39 pm »
We have a Zentyal (Dev/community) v.5 system running as a BDC for an old Windows AD system.  The PDC is a rather ancient Windows 2003 SP2 system that had the 2008 R2 domain upgrade applied to it (I know, it really ought not to be still in use).

The Zentyal system was originally a 3.5 install, later upgraded to 4.2. The more recent upgrade to v5 totally borked it, so I had to fresh-build it (retaining server name and same modules installed).

Recently the old PDC Windows system has been failing to synch the AD data from the newer Zentyal BDC - this was flagged up when users changed their passwords successfully (apparently serviced by the Z-box), but then when accessing a share or service from the old PDC, their accounts would immediately get locked.  Using the MS resource tool to change the user password on the old server to match their new password resolved the connections for them.

I tried manually synchronising from the BDC Z-box to the PDC using the MS tool "Active Directory Sites and Services", as per the guide doc from Technet.  The synch errored out reporting that "The replication operation failed because of a schema mismatch between the servers involved."

I don't know if this is something caused by a Zentyal update, or really is simply the old Windows system just being old kak.

Either way, I had planned to use the Zentyal-provided Operations Master migration script "ad-migrate" to transfer the PDC role to the Zentyal system, so that I could start to decommission the old Windows server.  But this script fails, reporting back with the following "not found" messages:

Code: [Select]
./ad-migrate: 18: ./ad-migrate: use: not found
./ad-migrate: 19: ./ad-migrate: use: not found
./ad-migrate: 21: ./ad-migrate: use: not found
./ad-migrate: 22: ./ad-migrate: use: not found
./ad-migrate: 25: ./ad-migrate: use: not found
./ad-migrate: 27: ./ad-migrate: use: not found
./ad-migrate: 28: ./ad-migrate: use: not found
./ad-migrate: 29: ./ad-migrate: use: not found
./ad-migrate: 34: ./ad-migrate: Syntax error: Bad function name

Has anyone else encountered this issue?

I had wondered if (in lieu of the ad-migrate not working) I could change the Zentyal Domain setting from "Additional domain controller" to "Domain controller" (ie. standalone), then stop the old Windows AD service, but I really don't want to end up with no working DC at all!
« Last Edit: June 20, 2017, 12:43:11 pm by AlecM »

dolanj00

  • Zen Apprentice
  • *
  • Posts: 1
  • Karma: +0/-0
    • View Profile
Re: AD synch and ad-migrate script - both failing
« Reply #1 on: August 03, 2017, 06:03:41 pm »
Hello,

if anyone run into this problem (it appers after a clean install of zentyal5), you can simply solve it by adding:

Code: [Select]
#!/usr/bin/perl
to the begining of the script file and save it. After that it will start working as expected.

AlecM

  • Zen Apprentice
  • *
  • Posts: 8
  • Karma: +0/-0
    • View Profile
Re: AD synch and ad-migrate script - both failing
« Reply #2 on: August 16, 2017, 04:05:44 pm »
Thanks to dolanj00 for the debugging contribution - I have not tried that, as we have tried to follow an alternative solution.

After my original post I ended up adding a new Windows 2008 R2 server, installing the AD services and promoting that to be the PDC for our domain.  The Zentyal system is still configured as an Additional Domain Controller.  The old W2K3 server has now been demoted and removed from AD duties and is a simple member server (temporarily retained until all features are migrated elsewhere).

The domain various FSMO "masters" were transferred to the new W2K8R2 server (named "Neptune").  The Forest Functional Level was raised to "Windows Server 2008 R2".

At this point Neptune was logging lots of DNS access issues (the DNS service couldn't connect to the AD PDC, which is also Neptune).  This seemed to be due to the Kerberos system having an issue, but I got that sorted by stopping the Kerberos Distribution Centre service (on the Windows PDC, Neptune), setting the service startup to "manual", restarting the PDC, then restarting the Kerberos service and setting its startup back to automatic.

But, I'm still seeing issues where the Zentyal server (name "Titan") is failing to synch back to Neptune in just one aspect.  All other directory features seem to be synchronising correctly.  The error log indicates Event ID 8418.

Following the MS troubleshooting guide https://support.microsoft.com/en-gb/help/2734946/troubleshooting-ad-replication-error-8418-the-replication-operation-fa
, obtaining CSV report using the command
Code: [Select]
repadmin /showrepl * /csv > replresults.csv, we see the one-way failure:

showrepl_COLUMNSDestination DSA SiteDestination DSANaming ContextSource DSA SiteSource DSATransport TypeNumber of FailuresLast Failure TimeLast Success TimeLast Failure Status
showrepl_INFOHeadOfficeTITANDC=DomainDnsZones,DC=copeohs,DC=comHeadOfficeNEPTUNERPC0016/08/2017 11:530
showrepl_INFOHeadOfficeTITANCN=Configuration,DC=copeohs,DC=comHeadOfficeNEPTUNERPC0016/08/2017 11:560
showrepl_INFOHeadOfficeTITANCN=Schema,CN=Configuration,DC=copeohs,DC=comHeadOfficeNEPTUNERPC0016/08/2017 11:530
showrepl_INFOHeadOfficeTITANDC=ForestDnsZones,DC=copeohs,DC=comHeadOfficeNEPTUNERPC0016/08/2017 11:530
showrepl_INFOHeadOfficeTITANDC=copeohs,DC=comHeadOfficeNEPTUNERPC0016/08/2017 11:530
showrepl_INFOHeadOfficeNEPTUNEDC=copeohs,DC=comHeadOfficeTITANRPC2016/08/2017 11:5612/07/2017 07:088418
showrepl_INFOHeadOfficeNEPTUNECN=Configuration,DC=copeohs,DC=comHeadOfficeTITANRPC0016/08/2017 11:560
showrepl_INFOHeadOfficeNEPTUNECN=Schema,CN=Configuration,DC=copeohs,DC=comHeadOfficeTITANRPC0016/08/2017 11:560
showrepl_INFOHeadOfficeNEPTUNEDC=ForestDnsZones,DC=copeohs,DC=comHeadOfficeTITANRPC0016/08/2017 11:560
showrepl_INFOHeadOfficeNEPTUNEDC=DomainDnsZones,DC=copeohs,DC=comHeadOfficeTITANRPC0016/08/2017 11:560

Has anyone else come across this situation?

At this point I'm stumped for what to do next - I've considered reinstalling the Zentyal system, or even getting rid of the Zentyal mechanisms altogether and using a "normal" Ubuntu server with Webmin on top instead.

Is it possible/feasible to remove the ActiveDirectory feature from the Zentyal 5 server without losing the file sharing (Samba) capability?  The Zentyal Wiki docs for version 4 seemed to indicate this might be possible (https://wiki.zentyal.org/wiki/En/4.0/Users,_Computers_and_File_Sharing) via "external Active Directory" config, but this info is not present in the v.5 wiki of the same topic (indicating either the wiki docs are inconsistent, or the capability is deprecated).

AlecM

  • Zen Apprentice
  • *
  • Posts: 8
  • Karma: +0/-0
    • View Profile
Re: AD synch and ad-migrate script - both failing
« Reply #3 on: September 20, 2017, 01:28:47 pm »
Thought I'd come back and update our status on this.  Dolanj00's suggested script fix was spot on to correct the ad-migrate script (giving it the target language/engine to use).

I ended up disabling the AD service on the Windows 2008 server and adding a second Zentyal system ("pluto") as a BDC.  This has stabilised most of the authentication issues we had experienced, but it is by no means a fully resolved situation, as some Windows server-based authentication processes will still fail. 

The two problem areas I've discovered so far have been;
  • Trying to launch a Hyper-V machine console (from the Hyper-V admin window on my local PC) will fail to authenticate the user login for the connection, even with the domain administrator credentials.  Launching the Hyper-V virtual console directly on the Hyper-V host (via an RDP session) does still work.
  • Launching Visual Studio with a project that is under Team Foundation Services (TFS) source code control. The TFS server (a Windows 2008 server) fails to authenticate my domain credentials - yet it manages to "see" enough to be able to lock my account if I keep trying  :-[.

Weirdly, using Remote Desktop (RDP) from my PC to the Hyper-V VM's still works fine (thankfully).

Looking at the Windows server error logs, the Hyper-V issue seem to relate to the Group Policy folders not being present in the Zentyal version of the Sysvol path - that is, \\[domain]\pdc\[domain]\sysvol\Policies (actual error Event ID 1096).  Some folks suggested setting a local machine policy to override the domain policy to allow the supplied credentials to work - but when trying to apply the change using "gpupdate /force", the system errors out reporting the lack of the sysvol policy folder (which seems a rather circular problem).

I managed to get a copy of the Policies folder and it's content (GUID-named sub-folders) from the Windows server ("neptune"), but I cannot copy these to the Zentyal sysvol area - the system tells me I don't have permission (I've got domain admins membership).  This permission setting may be by intentional design of how sysvol operates, but I don't know.

I have recently found several other Zentyal forum posts that touch on the same "sysvol" issue, dating back a few years - so this is (sadly) not a new problem:

https://forum.zentyal.org/index.php?topic=22923.0  (The noted summary in this matches almost exactly with the start of the issues I observed on our systems)
https://forum.zentyal.org/index.php?topic=30507.0
https://forum.zentyal.org/index.php/topic,23116.msg89031.html#msg89031

Following some of the suggested tests/resolution steps posted by Zentyal staff in the last linked page, the samba-tools are returning python script errors.
On the PDC ("titan"), command:

Code: [Select]
sudo samba-tool ntacl sysvolcheck
Gives the following (note the "ERROR" after opening the idmap data file):

Code: [Select]
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
Processing section "[homes]"
Processing section "[IT]"
Processing section "[ScanArchive]"
Processing section "[COPEDocs]"
Processing section "[MedicallyConfidential]"
Processing section "[Public]"
Processing section "[WPT]"
Processing section "[HP_Scans]"
Processing section "[netlogon]"
Processing section "[sysvol]"
ldb_wrap open of idmap.ldb
ERROR(<type 'exceptions.TypeError'>): uncaught exception - (61, 'No data available')
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 176, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 270, in run
    lp)
  File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1714, in checksysvolacl
    fsacl = getntacl(lp, dir_path, direct_db_access=direct_db_access, service=SYSVOL_SERVICE)
  File "/usr/lib/python2.7/dist-packages/samba/ntacls.py", line 81, in getntacl
    xattr.XATTR_NTACL_NAME)

Checking replication status - and I expect the Neptune server synch to fail as I've turned off the AD service on it:

Code: [Select]
sudo samba-tool drs showrepl
Gives:

Code: [Select]
ldb_wrap open of secrets.ldb
GENSEC backend 'gssapi_spnego' registered
GENSEC backend 'gssapi_krb5' registered
GENSEC backend 'gssapi_krb5_sasl' registered
GENSEC backend 'spnego' registered
GENSEC backend 'schannel' registered
GENSEC backend 'naclrpc_as_system' registered
GENSEC backend 'sasl-EXTERNAL' registered
GENSEC backend 'ntlmssp' registered
GENSEC backend 'ntlmssp_resume_ccache' registered
GENSEC backend 'http_basic' registered
GENSEC backend 'http_ntlm' registered
GENSEC backend 'krb5' registered
GENSEC backend 'fake_gssapi_krb5' registered
Using binding ncacn_ip_tcp:titan.copeohs.com[,seal]
resolve_lmhosts: Attempting lmhosts lookup for name titan.copeohs.com<0x20>
resolve_lmhosts: Attempting lmhosts lookup for name titan.copeohs.com<0x20>
resolve_lmhosts: Attempting lmhosts lookup for name titan.copeohs.com<0x20>
HeadOffice\TITAN
DSA Options: 0x00000001
DSA object GUID: 5f9f0c17-282e-47b2-ac00-40edb9d29b74
DSA invocationId: 87a25fb1-187b-48dd-b885-a2fd93d8e6ee

==== INBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=copeohs,DC=com
        HeadOffice\NEPTUNE via RPC
                DSA object GUID: 24e8a117-37b2-4146-9474-da7c45278313
                Last attempt @ Wed Sep 20 11:40:29 2017 BST failed, result 1234 (WERR_PORT_UNREACHABLE)
                5514 consecutive failure(s).
                Last success @ Fri Sep  1 08:11:45 2017 BST

DC=DomainDnsZones,DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ Wed Sep 20 11:40:29 2017 BST was successful
                0 consecutive failure(s).
                Last success @ Wed Sep 20 11:40:29 2017 BST

CN=Configuration,DC=copeohs,DC=com
        HeadOffice\NEPTUNE via RPC
                DSA object GUID: 24e8a117-37b2-4146-9474-da7c45278313
                Last attempt @ Wed Sep 20 11:40:29 2017 BST failed, result 1234 (WERR_PORT_UNREACHABLE)
                5515 consecutive failure(s).
                Last success @ Fri Sep  1 08:11:45 2017 BST

CN=Configuration,DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ Wed Sep 20 11:40:29 2017 BST was successful
                0 consecutive failure(s).
                Last success @ Wed Sep 20 11:40:29 2017 BST

CN=Schema,CN=Configuration,DC=copeohs,DC=com
        HeadOffice\NEPTUNE via RPC
                DSA object GUID: 24e8a117-37b2-4146-9474-da7c45278313
                Last attempt @ Wed Sep 20 11:40:29 2017 BST failed, result 1234 (WERR_PORT_UNREACHABLE)
                5514 consecutive failure(s).
                Last success @ Fri Sep  1 08:11:45 2017 BST

CN=Schema,CN=Configuration,DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ Wed Sep 20 11:40:29 2017 BST was successful
                0 consecutive failure(s).
                Last success @ Wed Sep 20 11:40:29 2017 BST

DC=ForestDnsZones,DC=copeohs,DC=com
        HeadOffice\NEPTUNE via RPC
                DSA object GUID: 24e8a117-37b2-4146-9474-da7c45278313
                Last attempt @ Wed Sep 20 11:40:29 2017 BST failed, result 1234 (WERR_PORT_UNREACHABLE)
                5514 consecutive failure(s).
                Last success @ Fri Sep  1 08:11:45 2017 BST

DC=ForestDnsZones,DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ Wed Sep 20 11:40:29 2017 BST was successful
                0 consecutive failure(s).
                Last success @ Wed Sep 20 11:40:29 2017 BST

DC=copeohs,DC=com
        HeadOffice\NEPTUNE via RPC
                DSA object GUID: 24e8a117-37b2-4146-9474-da7c45278313
                Last attempt @ Wed Sep 20 11:40:30 2017 BST failed, result 1234 (WERR_PORT_UNREACHABLE)
                5513 consecutive failure(s).
                Last success @ Fri Sep  1 08:12:56 2017 BST

DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ Wed Sep 20 11:40:30 2017 BST was successful
                0 consecutive failure(s).
                Last success @ Wed Sep 20 11:40:30 2017 BST

==== OUTBOUND NEIGHBORS ====

DC=DomainDnsZones,DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ NTTIME(0) was successful
                0 consecutive failure(s).
                Last success @ NTTIME(0)

CN=Configuration,DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ NTTIME(0) was successful
                0 consecutive failure(s).
                Last success @ NTTIME(0)

CN=Schema,CN=Configuration,DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ NTTIME(0) was successful
                0 consecutive failure(s).
                Last success @ NTTIME(0)

DC=ForestDnsZones,DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ NTTIME(0) was successful
                0 consecutive failure(s).
                Last success @ NTTIME(0)

DC=copeohs,DC=com
        HeadOffice\PLUTO via RPC
                DSA object GUID: ac19e956-ee12-4a4c-943d-3b0883f33c74
                Last attempt @ NTTIME(0) was successful
                0 consecutive failure(s).
                Last success @ NTTIME(0)

==== KCC CONNECTION OBJECTS ====

Connection --
        Connection name: 6f8dd7a5-2ad2-4354-a5a9-099fd08bf301
        Enabled        : TRUE
        Server DNS name : pluto.copeohs.com
        Server DN name  : CN=NTDS Settings,CN=PLUTO,CN=Servers,CN=HeadOffice,CN=Sites,CN=Configuration,DC=copeohs,DC=com
                TransportType: RPC
                options: 0x00000001
Warning: No NC replicated for Connection!
Connection --
        Connection name: f3671125-06e5-464f-8cd3-57313e483a20
        Enabled        : TRUE
        Server DNS name : Neptune.copeohs.com
        Server DN name  : CN=NTDS Settings,CN=NEPTUNE,CN=Servers,CN=HeadOffice,CN=Sites,CN=Configuration,DC=copeohs,DC=com
                TransportType: RPC
                options: 0x00000001
Warning: No NC replicated for Connection!

I have not yet been brave enough to try the samba-tools ntacl sysvolreset command.

Additionally, I have tried to run DCPROMO on neptune to demote it - but due to the status it thinks its under (FSMO master but not verified - which I couldn't even correct by forced seizing) this fails.  Trying to delete it from the Windows domain admin tools fails with a "script not present" error.

Would greatly appreciate feedback on what I should try next....

EDIT
Found another posted thread https://forum.zentyal.org/index.php?topic=23892.0 where the Group Policy problem was mentioned again...
This also mentioned running the sysvolreset samba command, so I have now tried this - but again there are Python script errors reported (scroll to bottom of output for this):

Code: [Select]
lp_load_ex: refreshing parameters
Initialising global parameters
rlimit_max: increasing rlimit_max (1024) to minimum Windows limit (16384)
Processing section "[global]"
Processing section "[homes]"
Processing section "[IT]"
Processing section "[ScanArchive]"
Processing section "[COPEDocs]"
Processing section "[MedicallyConfidential]"
Processing section "[Public]"
Processing section "[WPT]"
Processing section "[HP_Scans]"
Processing section "[netlogon]"
Processing section "[sysvol]"
ldb_wrap open of idmap.ldb
lp_load_ex: refreshing parameters
Processing section "[global]"
Processing section "[homes]"
Processing section "[IT]"
Processing section "[ScanArchive]"
Processing section "[COPEDocs]"
Processing section "[MedicallyConfidential]"
Processing section "[Public]"
Processing section "[WPT]"
Processing section "[HP_Scans]"
Processing section "[netlogon]"
Processing section "[sysvol]"
Initialising default vfs hooks
Initialising custom vfs hooks from [/[Default VFS]/]
Initialising custom vfs hooks from [acl_xattr]
Module 'acl_xattr' loaded
Initialising custom vfs hooks from [dfs_samba4]
Module 'dfs_samba4' loaded
connect_acl_xattr: setting 'inherit acls = true' 'dos filemode = true' and 'force unknown acl user = true' for service Unknown Service (snum == -1)
Initialising default vfs hooks
Initialising custom vfs hooks from [/[Default VFS]/]
Initialising custom vfs hooks from [acl_xattr]
Initialising custom vfs hooks from [dfs_samba4]
connect_acl_xattr: setting 'inherit acls = true' 'dos filemode = true' and 'force unknown acl user = true' for service Unknown Service (snum == -1)
lp_load_ex: refreshing parameters
Processing section "[global]"
Processing section "[homes]"
Processing section "[IT]"
Processing section "[ScanArchive]"
Processing section "[COPEDocs]"
Processing section "[MedicallyConfidential]"
Processing section "[Public]"
Processing section "[WPT]"
Processing section "[HP_Scans]"
Processing section "[netlogon]"
Processing section "[sysvol]"
ldb_wrap open of idmap.ldb
ldb_wrap open of idmap.ldb
Initialising default vfs hooks
Initialising custom vfs hooks from [/[Default VFS]/]
Initialising custom vfs hooks from [acl_xattr]
Initialising custom vfs hooks from [dfs_samba4]
connect_acl_xattr: setting 'inherit acls = true' 'dos filemode = true' and 'force unknown acl user = true' for service sysvol
unpack_nt_owners: owner sid mapped to uid 0
unpack_nt_owners: group sid mapped to gid 4
set_nt_acl: chown /var/lib/samba/sysvol. uid = 0, gid = 4.
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
Initialising default vfs hooks
Initialising custom vfs hooks from [/[Default VFS]/]
Initialising custom vfs hooks from [acl_xattr]
Initialising custom vfs hooks from [dfs_samba4]
connect_acl_xattr: setting 'inherit acls = true' 'dos filemode = true' and 'force unknown acl user = true' for service sysvol
unpack_nt_owners: owner sid mapped to uid 0
unpack_nt_owners: group sid mapped to gid 4
set_nt_acl: chown /var/lib/samba/sysvol/copeohs.com/scripts. uid = 0, gid = 4.
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
Initialising default vfs hooks
Initialising custom vfs hooks from [/[Default VFS]/]
Initialising custom vfs hooks from [acl_xattr]
Initialising custom vfs hooks from [dfs_samba4]
connect_acl_xattr: setting 'inherit acls = true' 'dos filemode = true' and 'force unknown acl user = true' for service sysvol
unpack_nt_owners: owner sid mapped to uid 0
unpack_nt_owners: group sid mapped to gid 4
set_nt_acl: chown /var/lib/samba/sysvol/copeohs.com. uid = 0, gid = 4.
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
idmap range not specified for domain '*'
Initialising default vfs hooks
Initialising custom vfs hooks from [/[Default VFS]/]
Initialising custom vfs hooks from [acl_xattr]
Initialising custom vfs hooks from [dfs_samba4]
connect_acl_xattr: setting 'inherit acls = true' 'dos filemode = true' and 'force unknown acl user = true' for service sysvol
open: error=2 (No such file or directory)
ERROR(runtime): uncaught exception - (-1073741823, 'Undetermined error')
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/__init__.py", line 176, in _run
    return self.run(*args, **kwargs)
  File "/usr/lib/python2.7/dist-packages/samba/netcmd/ntacl.py", line 239, in run
    lp, use_ntvfs=use_ntvfs)
  File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1609, in setsysvolacl
    set_gpos_acl(sysvol, dnsdomain, domainsid, domaindn, samdb, lp, use_ntvfs, passdb=s4_passdb)
  File "/usr/lib/python2.7/dist-packages/samba/provision/__init__.py", line 1502, in set_gpos_acl
    use_ntvfs=use_ntvfs, skip_invalid_chown=True, passdb=passdb, service=SYSVOL_SERVICE)
  File "/usr/lib/python2.7/dist-packages/samba/ntacls.py", line 162, in setntacl
    smbd.set_nt_acl(file, security.SECINFO_OWNER | security.SECINFO_GROUP | security.SECINFO_DACL | security.SECINFO_SACL, sd, service=service)
« Last Edit: September 20, 2017, 02:48:59 pm by AlecM »