I was wondering how it works because we see a problem where a couple of Win 10 clients can resolve all the internal Windows servers names, but not the statically assigned names of linux servers.
I thought if the name resolution works over different mechanisms and uses different ports it could be an firewall or L3 switch somewhere that has been misconfigured.
This is common in situations where Linux is not given an opportunity to auto-update the DNS entries, no one makes them manually, and they are not joined to AD.
Exactly - have you or anyone else added these servers to AD's DNS?
They have been added manually. The name of the service is also not the name as the server. So if a webserver is abc001.company.com the name in the DNS that will send you to that server might be logistics.company.com.
if you're being sent to logistics, that's the entry that must be in DNS.. you can have as many entries as are needed for a single server.
each name is it's own entry.
Which is just a layer on top of Powershell. The Active Directory Powershell module is still required.
It's not required, or that module is included already in Windows 10 by default. Because I haven't had to install it on any machine I managed with Ansible.
Wherever you need the password in plain text form.
Thanks. It mostly works. The only problem is that it isn't actually using the password I specify at the top. It is somehow generating its own and then writing it at the end. I put in
write-host "Plain Text Says: $plainText"
and it shows the password that I typed in for the secure variable at the beginning, followed by the one that it generated.
Plain Text Says: $#@%4#@177
Jof91348
Works fine for me here.... Check and make sure you don't have an extra write-host or anything somewhere.
I think your knowledge of FG is not allowing you to do this, just create a new interface with the desired subnet and leave or tick DHCP option. And they you can do it what you want with it. Create an IPv4 policy to give access to internet to the new interface.
@nerdydad - Yes, you do get a skimped down version of Azure AD with the O365 license. The prerequisites mention using Azure AD, but don't say which one, except where they say that the Premium version is optional for auto enrollment with intune. Although, they have several plans/tiers, including 2 premium tiers.
import-module activedirectory
$domain = "domain.mydom.com"
$DaysInactive = 90
$time = (Get-Date).Adddays(-($DaysInactive))
# Get all AD computers with lastLogonTimestamp less than our time
Get-ADComputer -Filter {LastLogonTimeStamp -lt $time} -Properties LastLogonTimeStamp |
# Output hostname and lastLogonTimestamp into CSV
select-object Name,@{Name="Stamp"; Expression={[DateTime]::FromFileTime($_.lastLogonTimestamp)}} | export-csv OLD_Computer.csv -notypeinformation
I'll add a note for clarity given the title... SaltStack does not do authentication like AD does. AD does not do patching of any sort like Salt does. Salt is an alternative to common myths about AD functionality, but not to actual AD functionality. But you can use Salt to do distributed local authentication management, which does replace the need for AD, but is very different than what is being discussed here. In this case Salt is replacing GPO, not AD.
