How can we know if an SID(Windows Event security identifier) belongs to a domain account or local account?
There seems no simple general rule to distinguish local account SID and domain account SID. But there are some well-known SIDs you can recognize.
It is sure that all local account SIDs are unique in local scope and all accounts SIDs in the same domain are unique in the domain scope. Otherwise, there will be conflicts.
Domain identifier is used to distinguish the SIDs of one domain from the SIDs for other domain in the same enterprise.
Relative identifier is used to distinguish one SID from the other in the same domain.
More references: Machine SIDs and Domain SIDs, Security identifiers, SID Components.
Related
Can gMSA accounts be used across two trusted domains? Say there is a DomainA which has gMSA account, and security group that is allowed to retrieve password for the gMSA account. And there is a server that belongs to DomainB that is part for DomainA\SecurityGroup.
When running Install-ADServiceAccount, I get:
Install-ADServiceAccount : Cannot install service account. Error Message: 'An unspecified error has occurred'.
I can retrieve the account from DomainA using Get-ADServiceAccount by specifying -Server parameter. Then pipe that into Install-ADServiceAccount and get above error.
When piping the account to Test-ADServiceAccount I get this:
Test-ADServiceAccount : Object reference not set to an instance of an object.
No, at least not that I've found. I think there's something in the API that makes it send the request for the password to only its own domain's DCs.
I have used gMSA accounts across a domain trust. The gMSA principal needs to be a group in the same domain, but as long as the group is type Domain Local, you can add computers from the other domain as members to that group, and they are then able to retrieve the password successfully.
We have an application to which I want to add a feature that grants additional access to domain admins of our corporate domain. The application runs outside of our domain as well. Obviously, I can query what domain the machine is joined to, and if it matches our corporate domain, enable the feature, but I'm concerned that a hypothetical "advanced" hacker might create their own domain at home with exactly the same name. How can I verify the identity of the domain, so that I can enable the feature only for our actual corporate domain, not just any domain whose name matches?
Anyone who know "What's the least privileges of NetLocalGroupAddMembers?"
Appreciate your helps.
MSDN says:
If you call this function on a domain controller that is running
Active Directory, access is allowed or denied based on the access
control list (ACL) for the securable object. The default ACL permits
only Domain Admins and Account Operators to call this function. On a
member server or workstation, only Administrators and Power Users can
call this function.
This is confirmed by Requirements for Network Management Functions on Active Directory Domain Controllers:
For updates, the default ACL permits only Domain Administrators and
Account Operators to write information. One exception is that users
can change their own password and set the usri*_usr_comment field.
Another exception is that Account Operators cannot modify
administration accounts.
and Requirements for Network Management Functions on Servers and Workstations:
By default, only Administrators and Power Users can write information.
I have a PC (Windows 7) that has a domain user. Because of some maintenance issues the PC is not in the company that has the domain user. There is no access to the domain through the internet.
I need to add this domain user into one of the local groups. I tried to to this by means of the Local Users and Groups panel of the Windows. It was not possible of course. Location of the user is only the local PC, domain is not accessible. As the local admin account I have also tried command line
net localgroup "My Group" Domain\user1 /add
However this also did not work. Is there any way to add a domain user into a local group when the domain is not available?
No, not without joining the computer to the domain containing the domain user to add locally or at least to a domain for which a trust exists with the domain containing the user to add locally.
http://technet.microsoft.com/en-us/library/cc739265(v=ws.10).aspx
• If the computer is joined to a domain, you can add user accounts, computer accounts, and group accounts from that domain and from trusted domains to a local group.
I am new to windows services programming. I have confusion about what to set the Account type while writing a windows services.
How to choose or how to determine to which account type we need to set while writing a service?
We generally create special windows (local for local only access or domain account for things that need to authenticate accross the network) accounts to run custom services. This way we can restrict and lock down the permissions to make sure it only has access to what we need. You can also see which specific users are culprits or resource hogging with monitoring on a shared server.
As for the built in accounts...
Local System:
The built-in LocalSystem user account has a high level of access privileges; it is part of the Administrators group.
Network Service:
The built-in Network Service user account has fewer access privileges on the system than the LocalSystem user account, but the Network Service user account is still able to interact throughout the network with the credentials of the computer account.
Local Service:
The built-in Local Service user account has fewer access privileges on the computer than the Network Service user account, and those user privileges are limited to the local computer. Use the Local Service user account if the worker process does not require access outside the server on which it is running.
Source(s):
Microsoft Technet
LocalSystem
The LocalSystem account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function.
It has extensive privileges on the local computer, and acts as the computer on the network. Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects. The name of the account in all locales is .\LocalSystem. The name, LocalSystem or ComputerName\LocalSystem can also be used. This account does not have a password. If you specify the LocalSystem account in a call to the CreateService or ChangeServiceConfig function, any password information you provide is ignored.
NetworkService
The NetworkService account is a predefined local account used by the service control manager. This account is not recognized by the security subsystem, so you cannot specify its name in a call to the LookupAccountName function. It has minimum privileges on the local computer and acts as the computer on the network.
This account can be specified in a call to the CreateService and ChangeServiceConfig functions. Note that this account does not have a password, so any password information that you provide in this call is ignored. While the security subsystem localizes this account name, the SCM does not support localized names. Therefore, you will receive a localized name for this account from the LookupAccountSid function, but the name of the account must be NT AUTHORITY\NetworkService when you call CreateService or ChangeServiceConfig, regardless of the locale, or unexpected results can occur.
A service that runs in the context of the NetworkService account presents the computer's credentials to remote servers. By default, the remote token contains SIDs for the Everyone and Authenticated Users groups. The user SID is created from the SECURITY_NETWORK_SERVICE_RID value.
The NetworkService account has its own subkey under the HKEY_USERS registry key. Therefore, the HKEY_CURRENT_USER registry key is associated with the NetworkService account.