We find that if we rename the PC, then allow more than a day to go by before restarting, this can happen.

Also, if we rename a PC, then the user allows the PC to go into Lock mode (screen saver timeout with login required to return) they will encounter this upon wake up/re-logon.

In the above two cases a reboot usually resolves it, when it doesn't, we go in as local admin and disjoin then rejoin the domain to resolve it.

Also, in the above two cases, we did not lose the computer in active directory, so after the disjoin/rejoin you'd want to remove the orphan computer from AD.

There's an article online somewhere about why you should NOT disjoin and rejoin the domain in this case, but we have always done it this way and have never experienced ill effects.

@Fredtx said in Multiple Tombstoned DC's:

@JaredBusch said in Multiple Tombstoned DC's:

Mesh of multiple locations like you have is simply asking for crypto to hit all the things.

Exactly what I've been telling them.

VPNs and AD the same. The mesh "should" not pose any threat because there should be nothing exposed over the mesh. But given the rest of the design, we can safely assume there are security holes everywhere and they are just trying to open more.

These are the flags that hackers look for for finding easy targets.

@oksana said in Changes to Kerberos and Azure Active Directory Authentication:

Kerberos is an authentication protocol that has been around since Windows Server 2000.

That should read: Kerberos is an authentication protocol that was introduced to Windows in Server 2000.

It was around for a long time before then: https://en.wikipedia.org/wiki/Kerberos_(protocol)

@dashrender said in Computer Name Issue: Domain Joined:

@scottalanmiller said in Computer Name Issue: Domain Joined:

@dashrender said in Computer Name Issue: Domain Joined:

@gjacobse Weird is right.

the closest I've seen is when 'nix boxes get a DHCP - they send this number that is some form of extended MAC as the hardware ID.

Interested to hear what you find out.

DHCP seems reasonable. Or there was a conflict.

in my case it's something in the way many Linux's now work. This thread talks about it.
https://community.spiceworks.com/topic/2288212-strange-extra-long-linux-mac-address-in-dhcp-active-leases

Not clicking the link, but it is the last 4 sets of the MAC address and the machine id as noted in /etc/machine-id. It is part of the DHCP RFC.

@scottalanmiller said in Active Directory Domain name:

@stacksofplates said in Active Directory Domain name:

@dbeato said in Active Directory Domain name:

@scottalanmiller said in Active Directory Domain name:

used that way. No certificate maker should ever have included it (and I've never heard of that as it would always indicate a scam CA as you cannot own that domain by definition).

The Majority if not all did add the .local, .lan and others, unless you think all CA are scams then I wouldn't say they are a scam.

Yeah from a quick search looks like at least GoDaddy and Digicert offered them.

Nov 2015 is when CA/Browser Forum set the standard to not allow internal domains. So looks like most if not all would have supported it before that.

https://cabforum.org/internal-names/

Damn, that's a major security hole! So I could go get a cert issued for a domain someone else used and there had to be zero verification since.... there was nothing to verify!

Yup.

@irj said in ADUC Set Password Expiry:

@gjacobse said in ADUC Set Password Expiry:

@irj said in ADUC Set Password Expiry:

You gotta teach good culture

Good Luck

Sometimes people have to be inconvenienced for security

Don't disagree - but can't stop doing business either.

Managing all these exceptions is an operational nightmare that will create a load of technical debt.

No lie - and no argument there. But resetting the expiry date/time doesn't seem all that different than resetting any password. few clicks and poof.

I can understand your point, but some responsibility for security must fall on the user. Management of course has to buy in on this and/or give full control of IT policies to a CISO/IT manager/generalist (depending on size of business).

Again - no disagreement. Barring this - being able to set a date for the password to expire that isn't to far out of policy seems better and more ideal than some of the options.

@dbeato said in You Have Exceeded the Maximum Number of Computer Accounts - Windows and Active Directory:

@scottalanmiller This is for a standard user without any Domain Admin Privileges. I am assuming this is for a Technician joining computers that no one wants to have admin permissions.

That would be an example case. Yes.

@JaredBusch said in Using non MS DHCP in MS AD:

Setup the way I show, Windows DNS still gets updated form workstations.

03b94431-bd00-4eb2-ad58-a26eb0814fd0-image.png

Good to know Windows is doing what it's supposed to do!

Thanks Jared

Hmmmm.....

There are two releases per year: January, 31th and July, 31th.

@Obsolesce said in Active Directory - User Attribute RFID/HID Badge:

@DustinB3403 said in Active Directory - User Attribute RFID/HID Badge:

@Dashrender I'm a 3rd party to the end customer here. Acting as the middle man as the customer's IT department wanted to engage outside support to try and vet different products.

I candidly told the customer that while this product will work, it won't work with all of the features they want without some substantial changes to their infrastructure and that the support (at least from this vendor) is pretty awful.

The simple approach here is to not integrate RFID/HID's to the system and simply use the AD Integration with the built-in QR codes that each member is assigned.

Just because something may be supported, doesn't imply that it is support.

Except in this case the vendor very clearly has stated they support you adding custom attributes within AD.

@Dashrender said in Managing Distribution Groups in an Exchange Hybrid Environment:

@EddieJennings said in Managing Distribution Groups in an Exchange Hybrid Environment:

I ought to have clarified. DUO MFA comes into play with Outlook for our mailboxes that are in Exchange Online. On-prem mailboxes (the few we have left aren't subject to DUO).

Are those that are left on prem - are they actual users? If so, I'm curious why they can't be migrated?

Eventually all users will be migrated, so, yes, we still have real users on-prem.

This is outside the scope of the original question / scenario, but I've learned a good bit during this process with much of that learning validating a few things I already knew, such as the value of taking the necessary time to plan, and prep the environment for migration (removing unnecessary objects, etc.).

So far the rebuild appears to be still working. It ran all night. No complaints yet.

Try this instead:

$FolderPath = Get-ChildItem -Recurse -Depth 2 -Path "P:\Public" -Force

Where -Depth is the how many levels deep you want to go.

If you want to see what a cmdlet can do, you can use:

Get-Help Get-ChildItem -Full