I need to transfer FSMO roles from Windows Server 2012 R2 to Windows Server 2019. It works well with clean Datacenter editions of both systems but not with existing Windows Server 2012 R2 Essentials.
There are existing Windows Server 2012 R2 Essentials with an FSMO role. I have added new Windows Server 2019 Essentials to the domain to which I need t transfer FSMO and installed AD-Domain-Services.
When I execute:
Install-ADDSDomainController
-CreateDnsDelegation:$false
-NoGlobalCatalog:$true
-InstallDns:$true
-DomainName "mydomain.com"
-SiteName "Default-First-Site-Name"
-ReplicationSourceDC "server2012.mydomain.com"
-DatabasePath "C:\Windows\NTDS"
-LogPath "C:\Windows\NTDS"
-NoRebootOnCompletion:$true
-SysvolPath "C:\Windows\SYSVOL"
-Force:$true
it fails with error: DCPROMO fails with the error "Access is denied" if the user does the promotion isn't granted the "trusted for delegation" user right
I have checked the Microsoft article => my actions:
https://learn.microsoft.com/cs-CZ/troubleshoot/windows-server/identity/access-denied-error-occurs-dcpromo
the recommendation is the article:
Verify that the default domain controllers policy exists in Active Directory (AD). => yes it exists
Verify that the user account does the DCPROMO operation has been granted the "Enable computer and user accounts to be trusted for delegation" user right in the default domain controllers policy. => User is in Enterprise Administrators, Administrators, Domain Administrators, and Schema Masters groups. I have tried to grant the user right for Administrators and Domain Administrators groups, but it did not help. When I run whoami /all, it shows SeEnableDelegationPrivilege Disabled.
Verify that the default domain controllers policy is linked to the domain controllers OU and that all DC machine accounts stay in that OU.=> there is just one OU - Domain Controllers and the only Windows 2012 R2 Server is there.
Verify that the file system portion of the default domain controllers policy exists in the SYSVOL share of the DC being used to apply policy on the computer being promoted or demoted. => there is just one DC there.
The default domain policy or policy, in general, isn't applying to the logged-on user => it is applied to the user. gpupdate /force applies the changes in domain policy
Both servers have unchecked "Protect object from accidental deletion".
I have not found any other reasonable root cause of the error.
What could be done further or what could be the potential root cause of the issues, please?
When KB5008102 (November 2021) is applied, this error will also occur if a user who is not in the "Domain Admins" global group tries to promote a domain controller. The update blocks the UAC settings up date with a message (on the DC you are replicating from/trying to update the computer object against):
The security account manager blocked a non-administrator from creating an Active Directory account in this domain with mismatched objectClass and userAccountControl account type flags.
Details:
Account name: NEWDCNAME$
Account objectClass: domainDNS
userAccountControl: 8448
Caller address: xx.xx.xx.xx:yyyy
Caller SID: S-1-5-21-YourAccountSID
Microsoft seems to have forgotten that Enterprise Admins should be considered admins in all the domains in a forest.
For instance, if you are trying to promote a new DC in a child domain with an Enterprise Admin account in the parent domain, this will now fail with this update. You have to create an account in the child domain, add it to the domain admins global group, and then do the promotion.
Related
I'm following the tutorial from here: https://community.snowflake.com/s/article/Amplifying-Outcomes-with-Snowflake
In PowerBI Desktop, I'm trying to "Get Data" and receive the following error: Details: "ODBC: ERROR [28000] Role 'POWERBI_ROLE' specified in the connect string is not granted to this user. Contact your local system administrator, or attempt to login with another role, e.g. PUBLIC.
ERROR [28000] Role 'POWERBI_ROLE' specified in the connect string is not granted to this user. Contact your local system administrator, or attempt to login with another role, e.g. PUBLIC."
In snowflake I've added the role to the user by using the query:
ALTER USER POWERBI_USER_ACCOUNT SET DEFAULT_ROLE=POWERBI_ROLE;
I've done this multiple times in snowflake, and did not receive an
error.
I've tried editing the ODBC connection in the "ODBC Data Source
Administrator (64-bit)" WIndows OS pref pane, and used the role
PUBLIC as suggested, but still receive the same error.
Any suggestions?
Also, does snowflake provide technical support, or are users left to post in public forums for technical support? A bit confused.
You need to run the following to grant the role to the user
GRANT ROLE POWERBI_ROLE TO USER POWERBI_USER_ACCOUNT
Looks like the article is missing this step.
Snowflake does provide tech support, you need to work with your account rep to set it up.
I have enabled CTRL+ALT+DELETE secure attention sequence (SAS) for windows logon using local security policy. (secpol.msc , Security Settings->Local Policies->Security Options->Interactive Logon: Do not require CTRL+ALT+DEL -> Disabled )
Currently the machine is using a facial based custom credential provider for login in Windows 10. In the current setup if the custom credential provider fails during authentication, it falls back to normal windows based logon (Password / Pin).
I have disabled the password, pin based mechanism through the group policy ( gpedit.msc, Computer Configuration ->Administrative Templates->System->Logon , Exclude Credential Providers ). This works fine as password and pin cannot be used for authentication. But the login page is still displayed.
How to always go back to Ctrl+Alt+Del logon page if the custom credential provider fails to do any authentication so that the user can retry ?
Is it possible to Control through group policy? Do I have to manage through the credential provider source so the fallback always goes back Ctrl+Alt+Del page.
Additional Info: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc780332(v=ws.10)
Ref section - Winlogon Desktop Dialog Boxes:
In other words it is about switching from "Log On to Windows" desktop "Welcome to Windows" desktop automatically.
Additional Info on the flow:
When Winlogon.exe detects the SAS (Ctrl+Alt+Del), it launches this LogonUI.exe process,which initializes our custom credential provider.
In the normal use case , when our credential provider succeeds , user enters his credentials and the LogonUI.exe process terminates.
Now in the second case, when our custom credential provider fails, desktop becomes blank or if fast user switching is enabled, it displays the switch user button.
In the correct use case , I have to fallback to SAS (Ctrl+Alt+Del)
*pcpgsr = CPGSR_RETURN_NO_CREDENTIAL_FINISHED;
return hr; // return to LogonUI
CPGSR_RETURN_NO_CREDENTIAL_FINISHED will return from your module to windows system without accepting your security structure. Also use unadvise to cleanup while returning from Serialization call.
Do you solve your issue?
I think in the new scenario of credential providers (versus GINA) it is impossible to control this behaviour.
If ctrl+alt+del is enabled there is no legal way to eliminate and/or simulate this secure attention sequence. Have a look at this article.
We migrated few SharePoint 2010 site collections to SharePoint 2013 but had to use classic authentication to preserve the users that were already in groups.
We have 2 AD domains one-way trust.
The problem now is that people picker in these site collections only show, existing users from the trusted domain and for new users, only {trusted domain}{user id} is possible for adding new user from the trusted domain.
So I performed:
STSADM.exe -o setapppassword -password <>
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "forest:Main.local, main\me,myPassword; domain:second.local, main\me,myPassword" -url https://sites.contoso.com/
Now I could not even add users using {trusted domain}{user id}. No way to add any users from the trusted domain
I checked the properties Peoplepicker_peopleeditoronlyresolvewithinsitecollection
and Peoplepicker_onlysearchwithinsitecollection they are either 'No' or do not exist.
What else can I do to support the secondary domain?
couple of pointers
1. For first domain there is no need to specify the password, Appliction pool service account should be part Domain Users and able to query its own domain.
2. As you have one way trust you cannot use account from your main forest to authenticate against one-way trust domain.
So your command should look like:
STSADM.exe -o setproperty -pn peoplepicker-searchadforests -pv "forest:Main.local; domain:second.local, second.local\me,myPassword" -url https://sites.contoso.com/
There is one more thing that may happen and that is lack of the permission on registry keys. Fire up the process monitor from system internals (on all FrontEnds) filter by access denied.
You might see access denied against the
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\15.0\Secure
Add the WSS_WPG with the read permission to that key.
We are developing an application with an internal user accounts system, but would like to be able to use credentials from Active Directory and/or Windows accounts. To that end we store the User SID in a field in the application's users table. Our login mechanism functions like this:
Prompt user for domain, login, password
Call LogonUser(logon, domain, password, logon_type, logon_provider, &hToken)
If successful, get User SID from hToken
Close hToken
Search our application's database for a user with the given SID; if found, we are considered logged in to that account.
The problem that has come up is this: we have been using LOGON32_LOGON_NETWORK for the logon_type, but we have now run into some security configurations where "Access this computer from the network" is denied, meaning the Network logon type is prohibited.
My question is what logon type should we be using for this situation? Interactive? We are not actually using the Logon token for anything other than extracting the user's SID. Our application has its own internal groups and permissions; we do not use Windows groups or permissions in any way. From the perspective of Windows and the domain controller, all we are doing is logging on and quickly logging off.
Or are we looking at this in a completely wrong way, and we should be using some other login method entirely?
Thanks
I also have been surprised to find out that the LogonUser() with the LOGON32_LOGON_NETWORK type fails when user right "Access this computer from the network" is not granted for Everyone on local computer.
I use the following workaround:
First try LogonUser() with the LOGON32_LOGON_NETWORK type.
If it fails with error ERROR_LOGON_TYPE_NOT_GRANTED, call LogonUser() with the LOGON32_LOGON_NEW_CREDENTIALS type and the LOGON32_PROVIDER_WINNT50 logon provider.
You can communicate with the SSPI services to validate a user's credentials and acquire a token, without requiring special privileges. This requires a lot of obscure code and
See http://support.microsoft.com/kb/180548 for an example; the SSPLogonUser function is where the token is acquired.
The convention is to use LOGON32_LOGON_BATCH, as documented:
This logon type is intended for batch servers, where processes may be executing on behalf of a user without their direct intervention. This type is also for higher performance servers that process many plaintext authentication attempts at a time, such as mail or web servers.
(emphasis mine).
The system administrators may still need to reconfigure the server to grant batch logon access to the users in question, but because this does not grant the user access to any Windows functionality (e.g., the ability to use Remote Desktop, to connect to a network share, or to log on interactively if they somehow gain access to the console) this should not be a problem.
BCS Security trimming with an ADFS login to SharePoint 2013 is not working for me with a custom connector. By not working I mean that when logged in via windows authentication, a user that has access to these BCS records can see them in search (this is correct). The same user logged in with ADFS cannot see these same records in search (this is not correct).
The setup I have is SharePoint 2013 on Windows 2012 R2 with ADFS. A SQL server database is being crawled via BCS with a custom .NET connector. The connector provides security trimming at crawl time by adding ACLs. The ACLs are created based on an AD Security Group that has a number of AD users as members (the logged in user is one of these members). The AD Security group is included as part of the claim and shows up as follows:
<saml:Attribute AttributeName="Group"AttributeNamespace="http://schemas.xmlsoap.org/claims">
<saml:AttributeValue>BCSSecurityGroup1</saml:AttributeValue>
</saml:Attribute>
BCSSecurityGroup1 is the AD Security Group that contains the users.
The odd thing is that even if I give everyone access to these records within the ACL (i.e. using WellKnownSidType.WorldSid), the ADFS logins still do not get these items returned in search. Even stranger is that if I go to the url for the BCS profile page for the record(s) in question, the ADFS user does have access.
Here is the question. What do I need to do to have search results reflect the ACL added security at crawl time?
As it turns out, this is actually pretty straightforward to get working. First, the AD Security Group was changed to individual AD users for troubleshooting purposes (domain\username). Looking at how the ACL is built in the connector, the domain account is used to get the SID, and the SID is then used to build the ACL. Ah ha! so the missing link is that with the AD FS claim, the SID is not being mapped. This was determined by using the Fiddler plugin to show claims under the inspector tab - http://identitymodel.codeplex.com/releases/view/52187.
Adding the SID claim in AD FS is done as a claim rule. Add a claim rule from the "Pass Through or Filter an Incoming Claim" template. Give it a name, select "Primary SID" for the Incoming claim type, and ensure that "Pass through all claim values" is selected. Restart the AD FS service for peace of mind. Also, this assumes that the Trusted Identity Token Issuer in SharePoint was created with a SID claims mapping.
In my case, I had to run another crawl on the BCS content source due to changing back to user names from AD security groups. Although I have not yet tested this, AD security groups should work the same way, but by passing through the Group SID. Hope this helps someone in the future. Cheers!