shodanshok's questions

To enable LDAPS I need certificates on both domain controllers. I can't use Certificate Services as I don't have a spare Windows machine and installing that role on a DC is a big no-no, so I would rather use a self-signed certificate with SANs covering both DCs (FQDN and short machine names).

Anything should I pay attention? For example:

• should the certificate have a maximum duration (ie: 1, 5, 10, 100 years)?
• can this disrupt/affect connection with client machine (unlikely as the DC have no certificate at the moment);
• EFS - not having a CA means that clients themselves are responsible for their keys. What will happen with the self-signed certificate?

I recently updated an old Win2008R2-based domain to a new Win2019-based one (with the common promote / demote / decommission dance). This was for a very small office (3 peoples), so this is a single-DC setup where both the old and the new DCs doubled down as fileserver.

For this reason, I created a DNS alias to point the old name (ie: olddc.example.com) to the new one (ie: newdc.example.com). So far, so good: all client could reach the new DC/fileserver both with the old and the new names. However, I forget to formally add to the new DC the old DC's name (as an alias). In other words, I did not issue something similar to:

netdom computername newdc.example.com /add:olddc.example.com

Today I was on the new DC and, out of muscle memory, I tried to reach its own shares via the old names (opening Explorer and writing \\olddc.example.com). Explorer immediately complained about "wrong credendials" and, indeed, a Wireshark dump shown STATUS_LOGON_FAILURE. I issued the netdom command above (adding olddc.example.com as an alias) and the problem went away: the server is now able to see its own shares via the old name.

I know and understand why the alternate/alias name should be added via netdom (or through a separate setspn command). However, what surprises me is that all the Win10 clients shown no complains at all even when such alternate name was not provided.

So, why do the Win10 clients worked with not issues at all while the server immediately walked back from accessing its own shares with a "unknown" DNS alias? Is it due to some different settings between Server and Client OSes? Or is it related to accessing a loopback share?

To enable unattended-upgrades for packages which can show dpkg config change menu, one has to configure apt and dpkg with these config options:

Dpkg::Options {
  "--force-confdef";
  "--force-confold";
};

These options should be added to a config fragment under /etc/apt/apt.conf.d; however, this will cause any apt-get upgrade command to not ask for config change selection.

My question is: does a method exist to enable --force-confdef --force-confold only for unattended-upgrades, short of modifying the systemctl apt-daily-upgrade.service unit file (ie: by adding a custom APT_CONFIG env var)? In other words, does exist a specific config file which is valid for unattended-upgrades only?

Note: I am using Ubuntu 20.04, but I expect this question to be relavant for Debian also.

I have an LDAP application which needs to talk to Active Directory via LDAPS (LDAP over SSL). I installed Active Directory Certificate Services on a test Domain Controller (I know this is not best practice, but my customer has no spare Windows Server license for a standalone CA server).

From here I read and followed these instructions:

If you install the AD CS role and specify the Setup Type as Enterprise on a domain controller, all domain controllers in the forest will be configured automatically to accept LDAP over SSL

The issued certificate was indeed loaded into the DC certificate store, and the LDAPS-aware applications is working.

My question is: will the certificate be renewed/re-enrolled automatically, or I need to manually taking care of it? What I need to check to be sure than automatic renew will work correctly?

I'm re-evaluating Windows 2016/2019 deduplication engine, which is way better (faster/more capable) than what shipped in previous Windows versions. I understand how it works (sparsifying files via holes + reparse point + compression), the recommended use cases and the ones to avoid.

My use case will be the simper one - deduplicate a big share which is a good candidate to dedup (ie: ddpeval shows ~40% savings); however, I have some doubts about application compatibility:

• Mac OS X clients (which are used by some) seems to have serious problems reading deduplication files, as you can see, for example, here, here and here

• from Microsoft docs it seems that the Expand-DedupFile cmdlet exists just for restoring files that have problems due to application compatibility.

These references let me think that deduplication is not really a "transparent" affair for the SMB client accessing the share, mainly because it seems to "export" (via SMB) the sparse nature of the files themselves. If the client has troubles managing sparse file, all sort of problem can happen.

So, my questions are:

• are you using Windows deduplication for your production shares? If so, does any client show issues?

• do you have any direct experience with Mac OS X clients?

• short of excluding some shares from deduplication, what else I can do to avoid application compatibility issues?

• apart for supporting dedup on ReFS volumes, does Windows 2019 change something else regarding deduplication?

I am tasked with recovering a VMWare 6.5 cluster that, after an unexpected power failure, has a VM (the most important one...) stuck at boot.

From the vmware.log file, it seems the problem is related to a corrupted CTK file and, as I read on this vmware KB, it should be sufficient to remove the affected CTK file (ok, not really so simple, but simple enough...)

However the affected VM has some snapshots active and, as I read on another (older) KB, such a procedure should not be attempted if snapshots are present.

What is the right path/procedure to unstuck the VM and letting the boot process to complete?

Until at least Windows 2008R2 it was possible to add multiple NetBIOS names to the same machine, with each additional name resolveable via NetBIOS broadcasts (ie: the classical NetBIOS resolution, not involving DNS). It even was one of the recommended approaches for file server consolidation.

While on Windows Server 2016 you can still adding new NetBIOS names, it seems that the only resolveable name is the first (main) one. For example, taking a server with MAINNAME and ALTNAME as primary and secondary names, only MAINNAME is resolveable via the NetBIOS-specific broadcast method. ALTNAME is resolveable via DNS, and its records are added to the DNS server indeed.

So, I ask:

• do you know why the default behavior was changed?
• do you have any suggestions on how to make secondary NetBIOS names resolveable?

With the goal of putting it in more production boxes, I'm testing Windows 2016 update behavior. I've run sconfig to select "DownloadOnly" in "Windows Update Setting" and I configured "Active Hours" from 07:00 to 19:00.

It is my understandig that this setup should work as below:

• updates are automatically downloaded;
• updates are not automatically installed; rather, a sysadmin had to manually confirm updates installation;
• if server must be rebooted, a scheduled reboot outside active hours should be automatically configured;
• in off-hours (ie: after 19:00 - 07:00) the server should reboot.

Main question: is the above understanding correct?

I'm asking because when testing on a Windows 2016 Domain Controller and manually installing updates, even if a notice shows "your device is scheduled to restart outside active hours (active hours are 07:00 to 19:00)", the reboot never occours.

I noticed that in Task Manager\Library\Windows\Windows Update, a Reboot Task launcing musnotification.exe RebootDialog was created to run at 19:20, and it runs each 30/60 mins.

Second question: how Windows 2016 behave, by default, when there are logged remote desktop users? Does it notify? Does it restart? What if the session is in disconnected state?

Note: I know the policy No auto-restart with logged on users for scheduled automatic updates installations, however:

1. It is not active/configured;
2. As I am not auto-installing updates, it should have no effect:

This policy applies only when the Configure Automatic Updates policy is configured to perform scheduled installations of updates.

Granted, I fully understand that a server should be patched and rebooted only at appropriate time. However, I would really like to understand the logic behind current (Win2016) update behavior. I strongly feel I am missing something, as this should be a basic maintenance task.

I've read these informations, but I would really like to hear some first-hand Windows sysadmin experience.

I am currently using Windows Server Backup (on a Windows 2016 DC server) for daily backups of System State to a local network folder - ie the network folder is shared by the very same host I am backing up, and from here it is automatically copied onto a different storage server.

It is my understanding that System State backups done via Windows Server Backup and stored on a network folder (even a local network folder) always are full backups: WBS only supports incremental backup via VSS, so a local target is needed for incremental copies. Moreover, backups taken via a network share have no history (only the last backup is valid).

What I see, however, is that while sometime a full (~13 GB, with extensive changed file list) backup is taken, each subsequent backup is quite small (200-300 MB, with very few changed files). After some runs/days (for example, 7 days) a full backup is automatically taken, and from here, a new cycle of apparently incremental backups begin.

Granted that I am happy to use incremental backups, I would really like to understand why and how this is happening. Based on all online articles I read, each backup should be a full one, taking its fair share of space. Anyone with an explanation?

On my domain controller (a Windows 2016 server), I have a number of opened directory as shown by Computer Management. For example, in the "Open Files" tab, I have quite a few entries as the following:

C:\Windows\SYSVOL_DFSR\sysvol\example.com\Policies\{unique-policy-id}\Machine\Scripts\Startup

It seems strange, as I have no startup/shutdown scripts. Moreover, I really expect the client to load the policy, execute it, and close the connection. Clients all are Windows 10 Pro.

Is this a sign of a problem, or it is expected behavior?

I have a two-controllers AD domain, and all domain-joined PCs have their addresses as primary and secondary DNS servers.

I wonder if I should configure a tertiary public DNS. The reasoning is that many PCs are located in smaller remote networks and they reach both domain controllers via a central VPN tunnel. If the VPN tunnel goes down, both DCs would be unavailable and the remote PCs will be unable to resolve any addresses, preventing them for surfing the internet/checking email/etc.

Adding a DC in each network is out of question (they are of 5/10 PCs), and the same can be said about creating a direct VPN tunnel from the remote network to the secondary DC site (due to hardware capacity).

A tertiary, public DNS server would prevent this, but I wonder if it can cause problems (ie: if it is, for some reason, selected as the preferred DNS, the PC would be "disconnected" from the domain).

So: it is ok to use a tertiary public DNS on a domain-joined PC, or it will cause problems? Anything to be aware of?

Both in my lab testing and on real installation I saw that, after a dcpromo (done via "Server Manager" on Windows 2016), a loopback IPv6 address is automatically added on the interface DNS settings (ie: ::1 as primary and sole DNS).

This IPv6 DNS address even take precedence over anything configured in the IPv4 DNS panel. This is confirmed both by ipconfig /all (which lists the IPV6 ::1 address as the first one) and by nslookup (which asks the ::1 server to resolve).

It is my understanding that, when having multiple domain controllers, it is never advised to use the loopback address as the primary DNS address.

So, my question is: is it correct to remove the IPv6 DNS loopback address from the interface DNS settings?

From my understanding, DSF uses the site/link information created in Active Directory Site and Services to redirect users to the nearest fileserver (when, of course, users access the share via the DFS namespace).

What about DFSR? Lets pretend that I have a two sites domain. Would DFSR replicate only with ADSS-configured link interval and schedule? For example, having a 15 min ADSS link interval would limit DFSR to a 15-min interval? Or would be the replication as fast as possible, as selected in the DFSR wizard when creating the replication group?

I've inherited an old Windows 2003 based Active Directory installation and I'm tasked to upgrade it to modern standards. I've done various (successful) test in my lab using the plan below, but I really want a reality-check / best practices suggestions from other experts in the field.

Current status: a single-label, Windows-2000 mixed mode Active Directory Domain running on a Windows 2003 installation. The DNS component is running with unsecure dynamic updates.

Target status: migrate to a Windows 2012R2 level domain on a Windows 2016 installation (note: the target level of Windows 2012R2, rather than 2016, is due to my customer having other Windows 2012R2 servers). The migration should be done in the least disruptive manner; anyway, as I am going to work on it during a weekend, short service disruptions are accepted.

Caveats: while single-label domain are deprecated, I really need to keep it running as-is. I evaluated both a domain rename and/or a domain migration to a new name, but they simply seem too much to ask for my customer.

My plan:

• install a new Windows 2016 server and add it, as a simple member, to the current domain
• raise the current forest/domain functional level to Windows 2003
• promote the new Windows 2016 server to the Domain Controller (with Global Catalog) role
• demote the old server (via dcpromo)
• on the new Windows 2016 server, use "Active Directory Sites and Services" to remove any eventual leftover from the demote operation
• on the new Windows 2016, use "DNS Manager" to change the DNS dynamic update type to "Secure only"
• raise the forest/domain functional level to Windows 2012R2
• change the old server's original IP address (eg: from 192.168.1.1 to 192.168.1.2)
• change the new server's IP address to match the old domain controller (eg: from 192.168.1.10 to 192.168.1.1). Note: I'm planning to do that due to current DHCP settings and gateway firewall/VPN rules
• migrate from FSR to DFSR (see here and here)
• install another Windows 2016 server on a branch office, adding it as a new Domain Controller (with Global Catalog).

Questions:

• I am missing something important?
• Is my idea of swapping the IP address of the old/new server to minimize firewall/VPN/DHCP changes a good one, or should I avoid that?
• Anything should I be aware of?

UPDATE: after much discussion and testing, I convinced my customer to go for a domain rename. I've done it via the rendom utility, as per Microsoft recommendations, and all went smooth (it did not have any on-premise Exchange server, fortunately).

We all know about Spectre and Meltdown, at this point. The take away is the while Meltdown can be solved/worked around with a (complex and invasive) kernel patch (namely KAISER/PTI), Spectre requires an updated microcode with advanced branch control.

Until some days ago, Red Hat shipped an updated microcode_ctl package which, in some (but not all) cases, had the appropriate microcode to patch/update (early in the boot process) the base processor microcode.

However, it seems the updated microcode causes system instability, unexpected reboot and even unbootable systems. So Red Hat reverted the microcode_ctl package to not load the microcode update needed to fix Spectre. Now their official suggestion is "to contact their silicon vendor to get the latest microcode for their particular processor".

While understandable, this stance only move the "instability provider" down from the OS to the BIOS/firmware itself.

So, my question is: how to you feel about the microcode update? Have you applied the new BIOS/firmware to production systems? Any instability to report/comment? Finally, should I wait for a new "patch round" or you advise to immediately apply the BIOS/firmware fix?

I noticed that some hosting companies providing both DNS and email services irrevocably ties the latter to the former - specifying an external DNS as the authoritative one automatically means not only the suspension of the mail/webmail service, but the deletion of all emails also.

While I understand the practical motivation behind a suspended service, the email deletion clause really surprise me. Moreover, this can be an hassle during a domain and/or email migration.

So:

• why so much haste in suspending and deleting the service? There are some imperative technical reasons?

• how do you manage such situation (domain and email migration from an hosting provider to another)?

Thanks.

I need to connect to a Win2008R2 RDP Remote App server using various client platforms, especially Win7, Android and iOS. On all cases, I'm using the official Microsoft's apps/programs to connect to the server. The server will publish some basic applications and it should be visible both from internal LAN and from the Internet (via a NAT/port redirect).

Connecting from internal LAN, I have no problem at all: any client can connect without troubles. However, when testing connection from outside (from Internet) via NAT/port redirect, problems begin. Both Android and iOS clients can see the name/icon of the published application without problems, but when trying to connect they die with the following message:

We couldn't connect to the remote PC because the PC can't be found. Please provide the fully-qualified name or IP address of the remote PC, and then try again. Error code: 0x104

From Wireshark output, it seems that Android and iOS clients try to resolve the machine NetBIOS name via a NetBIOS query, which is an inherently unroutable resolve process (it sends a NetBIOS packet to the broadcast address, somewhat similarly to what ARP does). Of course, the client can not resolve and die with the above error.

It seems very strange to me that a such important feature (RemoteApp) require mobile clients to connect from inside LAN only. I am missing something?

I would like to understand what is the best solution for realtime replication between two ZFS on Linux (ZoL) boxes connected by a 10 GbE link. The goal is to use them for virtual machines; only one box at a time will run the virtual machines and the ZFS filesystem itself. Snapshot need to be possible on the first (active) box. I plan to use enterprise/nearline grade SATA disks, so dual-port SAS disks are out of question.

I thought at the following possibilities:

• use iSCSI to export the remote disks and make a mirror between the local box's ZFS disks and the remote iSCSI disks. The bigger appeal of this solution is its simplicity, as it uses ZFS own mirroring. On the other side, ZFS will not give priority to the local disks over the remote ones, and that can cause some performance degradation (barely relevant on a 10 GbE network, I suppose). Moreover, and cause of bigger concern, is how ZFS will behave in case of network link loss between the two boxes. Will it re-sync the array when the remote machine become available, or manual intervention will be required?
• use DRBD to synchronize two ZVOLS and lay ZFS on top of the DRBD device. In other words, I'm speaking about a stacked ZVOL + DRBD + ZFS solution. This seems the preferred approach to me, as DRBD 8.4 is very stable and proven. However, many I/O layers are at a play here and performance may suffer.
• use plain ZFS + GlusterFS on top. From ZFS standpoint, this is the simpler/better solution, as all replication traffic is delegated to GlusterFS. Do you found GlusterFS stable enough?

What do you feel is the better approach? Thanks.

I've been tasked to install a new SFTP server. Per-se, this is a very simple operation: simply using the internal-sftp role of the ubiquitous SSH service (with chrooting) is sufficient to have a reliable SFTP server.

However it's in my nature to always try at least two different approach for the same problem, and I realized I can use ProFTPD with a sftp plugin to do the same thing, with the added benefit of more granular filetransfer-related options (eg: bandwidth throttling). On the other hand, this plugin is not compiled (and bundled) by default, and I would like to avoid (perhaps) "less tested" solution.

At the moment, the only required service is SFTP; however, I'm playing in advance and I would like to implement a solution which can not only work with SFTP, but with FTP/S also.

Considering that I am going to chroot users inside their homes, what do you feel is a better solution?

1. use SSH internal-sftp and a standalone FTP server (vsftpd or proftpd) for FTP/S services
2. only use the ProFTPD service with the relevant plugin

I would like to understand if, and how, it is possible to configure default kernel boot parameters on Red Hat 6 / CentOS 6 (grub legacy bootloader).

I very well understand how to manually configure the required parameters: I simply have to edit /etc/grub.conf and edit the specific stanza. However, a similar configuration will not last a kernel update: the new stanza will be configured with default kernel boot parameters.

Newer system (eg: RHEL7) use grub2 and the /etc/default/grub file and the GRUB_CMDLINE_LINUX variable to solve that specific problem.

So my question is: it is possible to specify system-wide, default kernel boot parameters and let these parameters to be the default settings for new kernels (updated via YUM/RPM) also?

Thanks.