Active Directory

Active Directory, Windows Server

ADDS Forest and Domain Functional Levels

/

Regularly customers ask « why should I raise ADDS functional level »?Here are the anwsers on each functional level. Whatever the application in your AD, raise the level at the maximum Windows Server 2016 Supported Domain Controller Operating System: Windows Server 2016 forest functional level features Windows Server 2016 domain functional level features Windows Server 2012R2 Supported Domain Controller Operating System: Windows Server 2012R2 forest functional level features Windows Server 2012R2 domain functional level features Windows Server 2012 Supported Domain Controller Operating System: Windows Server 2012 forest functional level features Windows Server 2012 domain functional level features Windows Server 2008R2 Supported Domain Controller Operating System: Windows Server 2008R2 forest functional level features Windows Server 2008R2 domain functional level features Windows Server 2008 Supported Domain Controller Operating System: Windows Server 2008 forest functional level features Windows Server 2008 domain functional level features Windows Server 2003 Supported Domain Controller Operating System: Windows Server 2003 forest functional level features Windows Server 2003 domain functional level features Windows 2000 Supported Domain Controller Operating System: Windows 2000 native forest functional level features Windows 2000 native domain functional level features

Active Directory

Active Directory error message « 2148074274 The target principal name is incorrect »

/

 Hi, as it regularly happens when you stop a test platform for a long time, computer accounts password expire and Active Directory controllers do not replicate anymore (well known item since Windows 2000 Active Directory). When you try to manually replicate using dssite.msc, you get the error message « 2148074274 The target principal name is incorrect ». Moreover, you can see in event viewer some messages such as: Log Name: SystemSource: Security-KerberosEvent ID: 4Error: The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server DC2. The target name used was cifs/DC2.dom2016.local. This indicates that the target server failed to decrypt the ticket provided by the client. This can occur when the target server principal name (SPN) is registered on an account other than the account the target service is using. Ensure that the target SPN is only registered on the account used by the server. This error can also happen if the target service account password is different than what is configured on the Kerberos Key Distribution Center for that target service. Ensure that the service on the server and the KDC are both configured to use the same password. If the server name is not fully qualified, and the target domain (DOM2016.LOCAL) is different from the client domain (DOM2016.LOCAL), check if there are identically named server accounts in these two domains, or use the fully-qualified name to identify the server. Solution – Locate PDC emulator with Active Directory Users and Computers snap-in– On the DC(s) no more replicating:

Active Directory, Non classé

Authenticating users with smartcard and login/password

/

Context When a user opens an Active Directory session with his smartcard, it happens that some applications do not support smartcard logon, but needs classical user/password login. Dilemma When you use Active Directory Users and Computers MMC, you only have the option « Smart Card is required for interactive logon »: This action does the following: Solution User modification Do not change user with ADUC MMC Change users properties with a PowerShell Script $oUser = [ADSI](« LDAP:// » + $Props.distinguishedname) Write-Output « Found user: $($oUser.DistinguishedName) » Write-Output  »   –> Setting SMARTCARD_REQUIRED (No password change) » [int]$userFlags = $oUser.useraccountcontrol[0] $oUser.useraccountcontrol = $userFlags -bor $ADS_UF_SMARTCARD_REQUIRED $oUser.setinfo() #    $oUser.ObjectSecurity $self = [System.Security.Principal.SecurityIdentifier]’S-1-5-10′ [guid]$nullGuid = [guid] »00000000-0000-0000-0000-000000000000″ Write-Output  »   –> Changing rights and attributes » $oUser.get_ObjectSecurity().AddAccessRule($(New-Object DirectoryServices.ActiveDirectoryAccessRule `     $self, « ExtendedRight », « Allow », $(GetADRightGuid(« Reset Password »))  `  )) $oUser.get_ObjectSecurity().AddAccessRule($(New-Object DirectoryServices.ActiveDirectoryAccessRule `  $self, « ExtendedRight », « Allow », $(GetADRightGuid(« Change Password »))  `  )) $oUser.CommitChanges() Check password expires On the OU in which the account is, link a GPO with a PowerShell login script and add the equivalent script: $oUser = SearchAD -ADSearchBase $RootDSE.defaultNamingContext ` -ADFilter « (&(objectClass=user)(objectcategory=person)(sAMAccountName=$($env:username))) » ` -ADProperties « distinguishedname », « displayname », « samAccountName », « useraccountcontrol », « objectGUID », « PwdLastSet » $PwdLastSet = ([DateTime]::FromFileTime([Int64]::Parse($oUser.Properties[« pwdlastset »]))) $UF = [int32]$oUser.Properties[« useraccountcontrol »][0] $bSmartCard = ($UF -bor 0x40000) -eq $UF $bExpiresPassword = ($UF -bor 0x10000) -eq $UF $pwdAge = (get-date) – $pwdLastSet $OutBox.AppendText( » –> DistinguishedName : $($oUser.Properties[« distinguishedname »])`n ») $OutBox.AppendText( » –> DisplayName : $($oUser.Properties[« displayname »])`n ») $OutBox.AppendText( » –> Password expires : $($bExpiresPassword)`n ») $OutBox.AppendText( » –> Requires SmartCard : $($bSmartCard)`n ») $OutBox.AppendText( » –> Password date (UTC) : $($pwdLastSet)`n ») $OutBox.AppendText( » –> Password age : $($pwdAge.Days) Days $($pwdAge.Hours) Hours $($pwdAge.Minutes) Mn

Retour en haut