HPlum78

You should have a lot of functionality to help prevent this in your FW. Your ISP should be blocking any fraudulent IP packets at their level but there are things you can do yourself like stopping the return address from being rewritten dropping icmp and rate limiting other well known attack protocols. DDoS attacks by nature are hard to pinpoint and are normally orchestrated by a large number of zombie clients without the actual owners knowledge so its hard to get help from the authorities.....

If you are doing a lot of cutting get an half decent electric mitre saw I use an evolution one. https://www.screwfix.com/p/evolution-r210sms-210mm-single-bevel-sliding-compound-mitre-saw-230v/2965V?tc=FT4&ds_kid=92700030658981616&ds_rl=1245250&ds_rl=1249484&ds_rl=1249796&gclid=EAIaIQobChMIl8u2tZD32wIV4ZXtCh31vQqaEAQYASABEgIi7fD_BwE&gclsrc=aw.ds&dclid=CMGygrqQ99sCFRcX0wod4qoMXw would do you.

Windows Hello for business is here as well....

Sounds like a client side issue to me, what do the message tracking logs say? Also be worth looking at the headers.

First letters from each name and then a number that increments (so no duplicates), duplicates are the devil in identity management even more so when you throw AAD Connect into the mix.

You should not have to do an initial sync on a new user creation / account updates a delta will do. Triggering an initial sync is generally done when the schema of the metaverse changes/ or a MA changes. A delta sync will do for day to day operation. - - - Updated - - - As a side note to the issue

When do you run that script?

Are these schedule tasks? If so I would guess that the task has the -execution bypass setting being passed. (as part of the arguments of the task)

$SMTPServer = 'YourSMTPServer.YourDomain.com' $mailFromAddress = '[email protected]' $mailtoAddress = '[email protected]' $evtData = Get-EventLog -LogName System -Newest 1 | select * $mailBody = $evtData.Message $mailFrom = $mailFromAddress $mailTo = $mailtoAddress $mailSubject = "Event $($evtData.EventID) has been raised on $($evtData.MachineName)" $SMTPServer = $SMTPServer Send-MailMessage -From $mailFrom -To $mailTo -Subject $mailSubject -body $mailBody -SmtpServer $SMTPServer Something like the above in code I think.... In fact the $mailBody line I would do like this now I have actually run the code! $mailBody = "Event Type:- `r $($evtData.EntryType)`r `nEvent Message: `r $($evtData.Message) `r `nEvent Generated `r$($evtData.TimeGenerated)"

https://technet.microsoft.com/en-us/library/dn931280(v=exchg.150).aspx Documentation above may help.

I don't know what OS you are talking about or indeed what version of PS either but instead of hobbling PowerShell in a manner that is unsupported you could try the New-PSRoleCapabilityFile:- The full details are here:- https://docs.microsoft.com/en-us/powershell/module/Microsoft.PowerShell.Core/New-PSRoleCapabilityFile?view=powershell-5.1 I will have to look into what MS has around best practice/ recommendations around this, I know it the later version of PS have more integration for JEA and app looker support has been added but needs more investigation before I can be sure of what is the best approach. I have probably added these in the past on here a little old (also a little off topic) but worth a look:- https://channel9.msdn.com/Events/Blue-Hat-Security-Briefings/BlueHat-Security-Briefings-Fall-2013-Sessions/PowerShell-Best-Practices And this is a later view, and Lee covers the hobbling of PS and why its not good from a security/ admin perspective:- https://blogs.msdn.microsoft.com/powershell/2017/10/23/defending-against-powershell-attacks/

Looked at both websites, nether are using https! I would make very sure that what you think you are downloading is what you are actually downloading. Also just took a quick look at one of them and took me about 5 seconds to get the username and new password out of an account that it changed the password for.... sometimes the free and easy way could end up costing.

#region Script Header <# Script that connects to O365 Room Calendars and gets the events from the calendar for the specified number of days Auth - HAP12 #> #endregion #region Rest API <# O365 Rest API connection to access a Room calendar - the /users/meetingroom1.yourdomain.com part needs updating for the Room calendar that you are connecting to. Could be scripted to connect to all the Room calendars using the commented line below (get-mailbox....) The startDateTime=$(Get-Date)&endDateTime=$((Get-Date).AddDays(7)) could be passed via a var - default is to get TODAY and add 7 days. The Foreach could do with beging a var that represents the name of the room that is being exported. #> Invoke-RestMethod ` -Uri "https://outlook.office365.com/api/v1.0/users/meetingroom1.yourdomain.com/calendarview?startDateTime=$(Get-Date)&endDateTime=$((Get-Date).AddDays(7))"` -Credential (Get-Credential) | foreach-object{ $_.Value } -OutVariable phfmr1evts #Get-Mailbox -ResultSize unlimited -Filter '(RecipientTypeDetails -eq "RoomMailBox")' | Select Name,Alias #endregion #region Functions #region Get-CalEventData <# creates the object to receive each event in the loop - if more properties are required from the raw data add additional params to handle the data required. #> function Event-Data() { param ($organizerName, $organizerAddress, $location, $subject, $startTime, $endTime, $eventIsAllDay, $eventImportance) $eventData = new-object PSObject $eventData | add-member -type NoteProperty -Name OrganizerName -Value $organizerName $eventData | add-member -type NoteProperty -Name OrganizerAddress -Value $organizerAddress $eventData | add-member -type NoteProperty -Name Location -Value $location $eventData | add-member -type NoteProperty -Name Subject -Value $subject $eventData | add-member -type NoteProperty -Name StartTime -Value $startTime $eventData | add-member -type NoteProperty -Name EndTime -Value $endTime $eventData | add-member -type NoteProperty -Name AllDayEvent -Value $eventIsAllDay $eventData | add-member -type NoteProperty -Name EventImportance -Value $eventImportance return $eventData } #endregion #endregion #region THE BIT THAT DOES THE WORK! <# The foreach loop grabs each event from the var created when we gathered the events via the API above, this iterates through the events and pulls out the details that we are interested in, the function above is then called and each event is exported out to the CSV specified at the end of the Get-CalEventData line below. This needs changing to a var and should probably represent the calendar name. #> foreach($event in $phfmr1evts){ $organizerName = $event.Organizer.EmailAddress.Name $organizerAddress = $event.Organizer.EmailAddress.Address $location = $event.Location.DisplayName $subject = $event.Subject $startTime = $event.Start $endTime = $event.End $eventIsAllDay = $event.IsAllDay $eventImportance = $event.Importance Get-CalEventData -organizerName $organizerName -organizerAddress $organizerAddress -location $location -subject $subject -startTime $startTime -endTime $endTime -eventIsAllDay $eventIsAllDay -eventImportance $eventImportance | Export-Csv -Path C:\localapp\meetingroom1.csv -NoTypeInformation -Append } #endregion Woking on event data from room calendars the above connects to a calendar, get the events in the calendar and outputs them to a CSV

Set-ADObject https://docs.microsoft.com/en-us/powershell/module/activedirectory/set-adobject?view=winserver2012-ps I would tend to agree that first.last is a bad idea from an identity management point of view also should try not to reuse any identities as well..... anyhow the above may help.

Can you Script (Powershell)?

I started thinking around the stack version between the servers and the client you are connecting from..... but based on that info I am thinking that they are/ should be the same.

So you have two hyper-V server (win srv 2012 R2) and are connecting to these remotely from a server/ client? if so what's the OS?

Test-WSMAN -computername I am just thinking out loud now.....

Anything in the logs here C:\Windows\System32\LogFiles\HTTPERR\ ?

Ah well that will cover the service right there then! :-P

Have you tried to restart the Windows Remote Management service? one other thought not that its the message I would expect you have not set a GPO up that has disabled the Allow Remote Shell Access by any chance? (Computer Configuration > Administrative Templates > Windows Components > Windows Remote Shell > Allow Remote Shell Access)

Yeah the aforementioned book is worth a look along with Lee Holmes Powershell cookbook is another good book to get your hands on. And the god father of PS https://channel9.msdn.com/events/speakers/Jeffrey-Snover take a look at there. PowerShell.org is also a good place to look subscribe to the RSS feed. https://blogs.msdn.microsoft.com/powershell/ That lot should get you started oh and always, always get-help

And then you are setting out the behaviour that should be avoided at all costs. You best hope that the company that is being slated so much for offering modern auth methods don't have any rouge employees now that they own all of your usernames and passwords..... that is a really bad idea. I am not going to get involved in a massive conversation around authentication methods and the merits of each, from a security stand point claims/ token based is the way forward no matter what the scale of your individual organisations are. And if any of you are using LDAP(s) I hope that this is not directly to your DC's as that would be worse than spending time moving to AD FS (or at least have LDAP proxies).

Can you only install AD FS on your DC's? being installed on a DC is not a requirement for AD FS. - - - Updated - - - you could just use your LDAP proxy boxes (as ADFS servers)

LDAPS is not what I would recommend I have just worked really hard to get shot of LDAP proxies. In fact AD FS is now a requirement for new applications (on prem/ cloud based) as LDAP(s) is just not an application authentication method that we are willing to support!. I don't understand why AD FS is such a massive issue out there? I have the thick wedge of 50 services authenticating via AD FS and if you see my other post from today you will see the use of the AD FS environment. On that note we are also trying to move towards using Azure for Seamless SSO but as I have said in another post recently its just not quite there around the authorization piece just yet. I would blacklist any app that could only do authentication by LDAP(s)!