It really depends on the specific scenario. You have a wide range of options that will give you different behaviors.
Usually for ID's that become parameters of commands, you would include those as query string parameters when generating the link to convey them between pages. I.e. if you had an admin page for editing users, you might generate a list of links with URL's like:
/Users/Edit.aspx?userID=123
/Users/Edit.aspx?userID=789
For the current user's ID, that should be provided by your authentication mechanism. For example(maybe different for your scenario depending on how you authenticate):
ASP.NET Membership: Where is Current User ID Stored?
From there, any other user level information could be in tables related to the user ID via foreign key.
Session[] is good for temporary storage for the current user. The reason it should be considered temporary is it will expire or be lost if the application pool is recycled. In which case it's usually fine, because the user will have to relogin and start over wherever they were at anyhow. Just don't store anything really important.
You can use static classes+static property to store system wide information.
I would avoid cookies as a last resort. The only cookies involved in any of my apps are the ones that the authentication framework creates automatically, and I never touched them directly. There's a lot of scenarios you have to consider regarding malicious manipulation of cookies, either by the user or by a third party.