Can I change custom attributes in EO once user lost EO license ? (Hybrid env.)

Answer is yes, you can, however not to the any value you want. If your organization sync AD extensibleAttributes to EO, and use them for some advance filtering etc. could be problem once user lost EO license and some change in extensibleAttributes in AD happens (usually you do some cleanup of values, or you replace original value by some neutral which means user is not active etc. ). This change is not sync to EO anymore, because user is missing EO license (O365 license).
Result can looks like this: in AD extansibleAttribute1 = “” , in EO customAttribute1 = “Marketing”


This could be the problem when you use Dynamic Distribution Groups which have members based on customAttributes . User does not have license, and customAttributes still show in EO original values from AD from age of success AD sync.

There are some ways how to solve it. You coul add back EO license to the user and wait for sync which will change the value/’s in customAttributes in EO, or setup/cleanup values in AD in extensibleAttributes, wait for Azure AD sync (this action requires that user without EO license is still sync to Azure !) and setup same value in EO via powershell 🙂 , yes simple, but sometime can head may spin:)

Delegate permission to manage “User cannot change password” in User ‘Account Options’

Hey, have you noticed, when you delegate write permissions for nt_SecurityDescriptor, you still cannot change an option ‘User cannot change password’ ? When you try mark this option and save, all looks fine, because you can save it, but once you open user account properties again, you see that option ‘User cannot change password’ is blank :\ . This is cause by missing permission to add ‘Everyone’ – DENY in security Tab. Yes, you also must have permission to modify permission of user object. If you do not want to give Full permission, you must explicitly add and allow ‘modify permissions’

User Object – Account Options

get-adgroupmember : The size limit for this request was exceeded

Although I have worked in big infrastructures, it is not long time ago, I have personally met with the limitation of ADWS service.  Because exists good reasons why this limit should not be changed on DC server, command-let get-adgroupmember can be easily replaced by Get-ADGroup ‘GroupName’ -properties Member | select-object -ExpandProperty member 🙂

https://docs.microsoft.com/en-us/archive/blogs/activedirectoryua/active-directory-maximum-limits-and-scalability-topic-updated
https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/dd391908(v=ws.10)?redirectedfrom=MSDN

ADLDS and Password Policies

Have you ever thought about how password policies are managed in ADLDS ? This short article will describe how it works.

When host server of the ADLDS instance is domain member, domain password policies are applied.  Host server in workgroup is using local password policies. To ignore inherited domain password policies can be done by using ADSIEdit.
Open ADSIEdit and connect to the Configuration naming context on the LDAP server., please find path below.

On the object:
CN=Optional Features,CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,CN={guid},
there is a multi-valued attribute called msDS-Other-Settings. The attribute ADAMDisablePasswordPolicies has by default value 0, set value to 1 means disable inheritance from domain and start using local password policies of the host server.

TLS 1.0 is also obsolete ! This article tell you how to protect Windows Web Servers against vulnerabilities.

If your servers still support TLS 1.0 or older obsolete cryptographic protocols (SSL, PCT, …) for communication over the network , you should act asap!

Description:

SSL 3.0 and older protocols, now also TLS 1.0 are vulnerable to man-in-the-middle attacks, risking the integrity and authentication of data sent between a website and a browser. Disabling TLS 1.0 and older protocols support on your server is sufficient to mitigate this issue! These obsolete protocols should be Disabled before public deadline – June 30, 2018 for SSL/Early TLS Migration. Ups.. Yes , this date is gone already :\….and also Windows Servers 2016 by default support these protocols !!!

The deadline -June 30, 2018  it is not my invention. This deadline was scheduled by The PCI Security Standards Council which is a global open body formed to develop, enhance, disseminate and assist with the understanding of security standards for payment account security. Probably after this date, this vulnerability could be reported to ICT teams by their local security team. – https://blog.pcisecuritystandards.org/4-things-to-know-about-pci-dss-in-2018

 

Technical Details:

Secure Sockets Layer (SSL) and early versions of Transport Layer Security (TLS) are no longer considered secure forms of encryption. It is critically important that organizations upgrade to a secure version of TLS – such as TLS v1.2 or higher – as soon as possible and disable any fallback to SSL/early TLS.
Many PCI DSS requirements require the use of ‘strong cryptography’ as defined in the PCI DSS glossary. After 30 June 2018 SSL/early TLS should not be used as a security control to meet any PCI DSS requirements attempting to demonstrate strong cryptography.

 

Default Windows Server 2012 R2, Server 2016 configuration is below:

Recommend configuration (change requires server restart):

Screenshots from tool – https://www.nartac.com/Products/IISCrypto
IISCrypto is very good alternative way how to set secure sonfiguration on your server, when you do not want to do it directly in Registry.

Microsoft sources about this topic:

https://support.microsoft.com/en-us/help/245030/how-to-restrict-the-use-of-certain-cryptographic-algorithms-and-protocols

https://support.microsoft.com/en-us/help/187498/how-to-disable-pct-1-0-ssl-2-0-ssl-3-0-or-tls-1-0-in-internet-informat