Develop Reference

I'd like to create a program that returns basic AzureAD information without tying it to one tenant

I'm not a C# programmer so forgive the ignorance, but I'm trying to create a program that will use the Graph API to do simple AzureAD commands, such as listing users, groups, etc. All articles that I've read on how to do this says the app first needs to be registered within AzureAD in order to do this, but I'd like this program to not be tied to that tenant. It'd prefer to just have a user authenticate to their tenant and use that access token to access Azure instead. I'd love any resources or where to begin. I tried to follow this article https://www.c-sharpcorner.com/article/write-your-first-program-using-microsoft-graph-sdk/ but it didn't work.

The correct approach is to register the app in your tenant as a multi-tenant app.
https://learn.microsoft.com/en-us/azure/active-directory/develop/single-and-multi-tenant-apps
This will allow the users to login with their tenant.
Your app can define the permissions it requires, which the other tenant users must consent to.

If you want to know Azure AD information, the tenant must be provided.
You can get the tenants for your account by calling
GET https://management.azure.com/tenants?api-version=2019-06-01
Reference:
https://learn.microsoft.com/en-us/rest/api/resources/tenants/list

C# console app AzureAD how to mimic powershell's Get-AzureADUser

Is there a way to mimic powershell's Get-AzureADUser to read AD properties on given users without having to register the C# console app I am trying to build with Azure?
I know you can run powershell in C# but I am wondering if there is a different route I can take to achieve the same thing WITHOUT registering the app?

Short Answer: No. You will need to register an application with Azure AD to be able to authenticate.
Longer Answer:
AFAIK all of the OAuth 2.0 grants for authentication supported by Azure AD will require some information about the client (i.e. registered application) that is being used to make the authentication call. This would be true whether you use ADAL Libraries or directly hit the relevant token/authorization endpoints.
You may already know but it's worth mentioning that the simplest and recommended way to do authentication/query user data with right privileges will be to register your application with Azure AD.
In fact default setup for Azure AD, is such that it promotes the use case of developers being able to register applications and consent to applications on their own behalf. Read here.. Who has permission to add applications to my Azure AD instance? and at the end it mentions that Microsoft itself uses the same configuration internally.
Full Disclosure: I know that some very knowledgeable people (Microsoft MVP's, Microsoft Azure AD team members) follow the azure-active-directory tag. So even though I think this is the right answer, your question is such that it would make sense to wait for more answers/comments to see if there is anything else possible.
Possible workaround if it suits your scenario:
In case you don't want to register your application just because you don't have permissions to a specific Azure Active Directory tenant, there may be a workaround possible.
You would still need to register your application but with a different Azure AD tenant or with Azure AD B2C, and then make your application as a multi-tenant. See this SO post for more details.

Log In to Sharepoint by Creating IE Cookie (Using Graph API)

I am wondering if it is possible to use Microsoft's Graph API in order to create a cookie in IE given the username and password, (preferably using C# or VB.net), so that when the user connects to sharepoint with IE, he/she won't have to log into sharepoint via the login screens.
I'm having difficulty searching for examples because most examples describe how to authenticate a user. I am not looking to authenticate a user though, I am looking to create and store a cookie to force a user login.
Thank you for any advice.

No, and this should never be done. First because cookies are simply not secure. Secondly because you should never be storing any encrypted password anywhere.
I'm really not sure how Graph API fits into the scenario you provided. Microsoft Graph is a REST based API. It doesn't authenticated users on its own, you pass in a valid access token with each call. How you retrieve that token depends on if you're using delegated or application permission scopes.
From the scenario you described, it sounds like you're looking for SharePoint Single Sign-On (SSO). There are a few ways to do this but generally it is done using ADFS and AADSync. There is a walkthrough for setting this up: Step-By-Step: Setting up AD FS and Enabling Single Sign-On to Office 365. Be forewarned however, this is not a trivial process.

Authentication using Azure

I have an Azure account and currently a Mobile Service setup with a SQL Database so that my Windows Store app can communicate with the database.
I have developed sites using ASP.NET WebPages authentication. And I need something similar for my Windows Store app.
I have successfully gone through the documentation and tutorials on the Windows Azure website and implemented ACS (Windows Live ID, Google, Yahoo!, and Facebook) - but the thing is - I don't want Google, Yahoo!, Facebook or even Windows Live ID or Microsoft Account) logins - I want my OWN login but it seems that they don't give you this option (correct me if I am wrong).
I need to allow users to signup from within my application (that means, providing their name, DOB, email, phone, address, etc) and shove it all in my database.
Now, after implementing Microsoft Account login with my Azure service, I found out that you can't even get the most basic information about any user who has logged in to your application - not even an email address.
I have spent hours searching online for something that could possibly help but I am running out of keywords - and have not hit a single related result yet.
Does anyone know if this is possible? How would we go about integrating login and signup with a Windows Store app that set/gets this data into/from a Windows Azure service?
Any code, samples, links, tutorials, documentation, etc would be highly appreciated.

You have gone down the road of hooking up external identity authentication, which in my opinion for an external facing web application is a better approach. Benefits are:
Your application is only responsible for Authorization not Authentication. There is a whole lot of work involved in Authentication and a large number of best practices. Best let those who know best take the burden of this. This doesn't mean you shouldn't try and understand it though.
If your site gets hacked you don't have to tell them that their username / email and password combo has been compromised and they will probably have to change there passwords on other sits.
You are also making sure that your users don't have to remember / manage yet another username / email address password combo
If you really want to do the Authentication then that is fine but you will need to do it yourself. Have a look at examples on Asp.Net Membership. This is not the only way and nor is it the best way but there are lots of examples.
Now if you decide you want to use external authentication I can give you some pointers to help with your current implementation.
First thing to note that the Id you get back from Live, Google, Facebook can only be assumed to be unique for that provider. Therefore if you want to keep a profile in your system for that identity and you want to use more than one provider you will need to implement it in such a way that you can keep the id unique in your system and help you associate it with a provider.
Website Authentication with Social Identity Providers and ACS Part 2 – Integrating ACS with the Universal Profile Provider
As you have found out not all of the Authentication providers return the same "claims". A claim is something that user claims to have, such as an email address, name, date of birth, etc. All the ones you can use by default via the ACS return Uid and some return a name and email address. What you have to do is fill in the gaps. When someone registers you will need to pull the relevant claims and then ask them to fill in the missing ones. You may also want to map the different claims in the ACS to a common name that you can use in your app as one provider might use slightly different names.
Federated Identity with Windows Azure Access Control Service
Just because you do not handle Authentication you still need to be responsible for keeping your application secure. Half of the work has been done for you so your code should be a lot lighter but you will still need to make use of roles.
Windows Azure Role Based authentication (ACS)
The really nice thing about this approach is you can implement your application the same why SO have done with there identity model. You can allow users to associate multiple identities against their profile meaning they can login how they want to.

If you choose not to use the built in providers for ACS you will need to implement your own Identity Provider using SAML, OpenId, etc...
You can look into the Windows Identity Foundation (WIF) for implementing WS-Trust or WS-Federation.
There is also ADFS which has the same set of support but uses Active Directory with WIF and Azure has its own version of AD that can be used.
There is also thinktecture identityserver which can jumpstart your venture into IdP land, but I have not used it myself yet.
If you want to go the OpenId route there is DotNetOpenAuth.

If you're looking to add custom identity to your Mobile Services app, check out Josh's post on custom auth: http://www.thejoyofcode.com/Exploring_custom_identity_in_Mobile_Services_Day_12_.aspx

Providing SSO support for 3rd party systems in our application without another sign in page

We have an application which we need to allow users from our customer's systems to be able to sign in without seeing another log in screen.
What is the best way to provide an SSO type experience for our customers? I have tried to research Azure ACS and Windows Identity Framework but they all seem to be based on this idea of a common log in popup/screen which all sites use. Unless there is another aspect to this federated identity system I don't think that will work for us. Basically our customers are education institution which have students who sign in and use their own web applications/portals. These customers purchase access to our application and want their students to be able to click a link from their portal and automatically sign into our system.
From looking around it seems important to know that these systems are running on completely separate domains. For some legacy systems we have asked our customer to provide simple api endpoints for a very custom sso implementation. What I'm looking for is any information about a more standard approach for SSO.

SAML 2.0 is the standard for single-signon. Your clients would need to have some authentication mechanism on their sites that can be translated into a SAML call to your application.

When they sign the student on, they should make a quick call to your application, passing you the username of whoever is logged in. In return, you generate a token, store it in a DB along with the username, and send them the token. They append that token to any link to your app in GET form, and it "uses up" the token (removes it from the DB) but signs them in to that account.
Upon generating the token, you can also remove one "credit" from that applications allowed requests, or whatever else you want to do there.

Our specific needs required us to roll our own SSO type system using some simple secret token handshakes.