I am working with a Windows Active directory environment. The SID is the combination of Domain ID and RID.
I found that there can be a maximum of 2^32 RID for a domain. However, the Domain ID can be even more than 32 bits. Also it seems that domain ID is unique only within the forest. I wonder why Microsoft allotted so many bits for Domain ID. Is there any other significance for the Domain Identifier part?
To be precise I have only 3 domain in my forest. Why does server the following ID for the user object?
objectSid: S-1-5-21-2999047449-515994586-265227950-1125
In case this ID is Universally Unique then who assigns this Domain ID?
A SID is not a GUID, it is not intended to be huge unique identifier with trillions of unique values, it is an arbitrary length STRING containing various information which includes the domain ID and the relative ID.
For example, S-1-5-7 is the SID for Anonymous users, S-1-5-32-545 is the SID for the local Users group and S-1-5-32-544 is the SID for the local Administrators group. These SIDs are common to all installations and therefore known as well-known SIDs. See: http://support.microsoft.com/kb/243330
As for who assigned your domain ID, it is randomly generated when the domain is created. It is only unique so far as a new domain will not use an ID already in use within the Forest, but there could be hundreds of domains out there with the same ID.
SID (Security Identifier) :- SID is the primary key for any object in an active directory. SID are unique to a domain.
In active directory users refer to accounts by using the account name , but the operating system internally refers to account by their security identifier (SIDs).
Related
I'm going to store root and intermediate certificates (from different CA) into some KVStore.
The problem: I have a leaf certificate (only) that I want to validate based on certificates from my store. The leaf certificate has Authority Key Identifier == Subject Key Identifier of a parent that already must be present in the KVStore.
Question: What should I use as a Key in KVStore?
1.Subject Key Identifier:certificate or it can be the same within single CA or different CAs. what about renewal or keys rotation?
2.Subject Key Identifier + Subject DN: certificate - not sure that there is a difference with first.
3.Subject Key Identifier: list[certificate]
4.Serial Number + Issuer is unique but leaf certificate doesn't contain this date about parent.
The Subject Key Identifier is a hash value over the certified public key. Thus, depending on the CA's key rotation policy this may or may not change during certificate renewal. It is therefore not guaranteed that the mapping SKI:certificate is unique.
A combined index as in option 2 does not change that.
Option 4 should be ruled out since the child certificate does not know the issuer and serial number of its parent.
Option 3 may be a valid solution in most cases, however, the Authority Key Identifier extension is not mandatory for X.509 certificates. So you may have to deal with leaf certificates without the AKI extension.
This typically leads to option 5: Subject DN: list[certificate]. Preferably with a sorted list that has the most likely CA certificate on top.
However, if your application only deals with leaf certificates with an AKI extension and all CA certificates require a key rotation during renewal option 1 may be a tick more performant. In that case I'd also keep an entry Subject DN: list[Subject Key Identifier].
I just started reading/experimenting with the Accounts library yesterday and trying to wrap my head around the participants/signers part in my states.
Let's say I have the following:
1. Mint: A node that issues tokens.
2. Registry: A node that hosts accounts and generates key pairs for them when requested.
3. Wallet: A node that holds tokens on behalf of accounts.
4. I created my own fungible token which basically has an extra field: PublicKey owningAccount
The process:
1. The Registry creates a new account (let's call it Account001), so the Registry is the host of that account.
2. The Mint requests a new key pair for Account001 from Registry
3. The Mint issues a new token to Wallet and sets owningAccount to the key they got for Account001 from Registry, so now Wallet is the holder of the token
So now we have:
1. Registry is the host of Account001
2. Wallet is the holder of the token (on behalf of Account001)
Questions:
1. Is my approach of having those 3 nodes correct? One node controls the supply of tokens, another the users, and last one tracks the "balances" of tokens per user.
2. I want to keep this separation of nodes (assuming it's conceptually correct); and for that reason I don't want to include the owningAccount as part of the participants for the token, so the token will only persist in the vault of Wallet, BUT I will require owningAccount as a signer for various commands (e.g. when moving the token to a new owningAccount; both the holder (i.e. Wallet) and the owner (i.e. Registry on behalf of owningAccount) must sign).
3. In general (let's forget about tokens), if I have a node that manages users and another that manages the state that has owningAccount field, in that state do I need to have owningAccount as a participant? Like I mentioned I'm still trying to figure out the "right" approach (usually things become more clear as I program more), but I would imagine that there should be some decoupling where the owningAccount is just required as a signer for commands related to states that are tied to it, and the participant is mostly just the node to whom that state was issued to.
Roger Willis explained to me on Slack how FungibleToken allows assigning the token to a certain owner (i.e. public key) as opposed to a Party by using the Holder attribute; the process is as follows:
1. The Mint node starts the issue token flow which takes as inputs amount and AccountInfo ref
2. It requests a new public key for the referenced AccountInfo from the Accounts Registry node
3. The received public key is used to get the respective party (i.e. identityService.partyFromKey(receivedPublicKey))
4. The resulting party is assigned as the Holder of the token
5. Remember that a Party is the CordaX500Name (Accounts Registry in our case) and a public key that identifies this entity (in our case it's the public key that mapps to an AccountInfo state (i.e. to a certain user)).
6. So whenever we issue a new token, the holder will always be Accounts Registry party but the same party will have different public keys for different owners/users.
7. With all that being said we no longer need 2 nodes Accounts Registry and Wallets, we will have one node Wallets which holds our AccountInfo states and our tokens where the holder of the tokens is Wallets party but the public key in that party will vary and map to different AccountInfo states depending on who's the owner/user.
Upon deploying a new server and migrating the entire contents of /home using rsync I noticed that the group and user ownership were in fact preserved, despite the fact that the ids differ between the two servers.
Specifically, the command I ran was:
rsync -avz oldserver:/home/ /home
Though I have recreated all of the same users and groups on the new server, most of them have different ids than the old, but somehow this command has magically kept the correct ownership (based on name) and assigned new gid and uid where applicable. I am able to verify this with ls -n /home.
How is this possible? Does rsync do some kind of name lookup?
Yes, by default rsync matches owners and groups by name. Details are in the docs for --numeric-ids.
--numeric-ids
With this option rsync will transfer numeric group and user IDs rather than using user and group names and mapping them at both ends.
By default rsync will use the username and groupname to determine what ownership to give files. The special uid 0 and the special group 0 are never mapped via user/group names even if the --numeric-ids option is not specified.
If a user or group has no name on the source system or it has no match on the destination system, then the numeric ID from the source system is used instead.
rsync presumably uses getpwnam and getgrnam to look up the uid and gid associated with the user and group names.
Given an Azure subscription ID and resource group name, how can I get a list of all provider(s) that make up the resources in that group? E.g. if a RG contains websites and VMs, I'd get ["Microsoft.Website", "Microsoft.Compute"].
Apparently, the only way to do this is by using the List By Resource Group API, then parsing the resource IDs manually.
So I set up SQL Server Session State using SQL Server 2008 and the temp database and today I decided to look into the data in the tables only to find this in the ASPStateTempApplications table:
AppId AppName
538231025 /lm/w3svc/1/root
611758131 /lm/w3svc/3/root
802488340 /lm/w3svc/4/root
-940085065 /lm/w3svc/4/root/webapp
685293685 /lm/w3svc/5/root
1210055478 /lm/w3svc/5/root/webapp
We have 2 load balanced web servers.
When I look into the ids of the web apps of both servers I see that web1 has app1 with id 4 and web2 has app1 with id 5. The same thing happens with the other app. web1 has app2 with id of 1 and web2 has app2 with id of 3.
My common sense tells me that the web servers are not sharing sessions as the session id uses the appid. Am I correct? If so why isn't this minor detailed not so obvious in the documentation? Should I make the ids match on both web servers?
The AppId is used during the creation of the SessionId, to help avoid collisions from one app to another. It's created by computing a hash of the IIS app path.
In your environment, the flow might be something like this:
Server A creates a session ID, sets it in a cookie, and stores some data in the corresponding session (a row in ASPStateTempSessions). The session ID column is created by concatenating the session ID with the AppID.
Server B receives a request with a pre-existing session ID, and uses it to find the associated session data from the ASPStateTempSessions table. If the app ID is different, the generated key will also be different.
The net effect of having multiple servers with different AppIds that are sharing the same sessions is that IDs created by one server won't collide with those from another server, and machines with different AppIds won't see each other's sessions.