According to this article (https://docs.snowflake.com/en/user-guide/admin-account-identifier.html#), SnowFlake has two different ways for account IDs:
Account name - created by me, for example, my-company.snowflakecomputing.com
Account locator - a more technical name, not as nice and understandable as 1)
Now we are using locator and I don't understand, it is possible to change locator to name or not?
P.S. I read, that account locator can't be changed, but maybe this is only true for changing locator to locator?
It is possible to change the account alias and access your account via a new name, if you are using the Organizations-Feature. Now I assume your account is not part of an organization, so we have to use the "Option 2" of the below link (same as yours).
So... no, it is not possible to change, if you created your account on your own through self-service. Only if a Snowflake representative is creating your account, then this person can change to a name.
Docs: https://docs.snowflake.com/en/user-guide/admin-account-identifier.html
The account locator can not be renamed/modified once the account is created.
https://docs.snowflake.com/en/user-guide/admin-account-identifier.html#option-2-account-locator-in-a-region
Your account name is the alias for your account locator, and it can be renamed (by support). If you want to connect to your Snowflake account, using the account name, you need to use the orgname-accountname.snowflakecomputing.com format.
Btw, all accounts also have a "random" organization name. Support will tell your organization name or rename it if you request.
Changing Account Name:
An organization administrator (i.e. a user granted the ORGADMIN role) can use the ALTER ACCOUNT command to rename an account. For example, the following command renames an account called original_acctname to new_acctname:
use role orgadmin;
alter account original_acctname rename to new_acctname;
By default, Snowflake allows you to access the renamed account with either the original URL or the URL that contains the new account name. To prevent access using the old URL, set the optional SAVE_OLD_URL parameter to FALSE when renaming the account. If the account has already been renamed without this parameter, you can still block the old URL by executing the ALTER ACCOUNT new_acctname DROP OLD URL command.
Related
I create successfully a ServicePrincipal (SP) in AzureAD and able to do a lot of stull like {Connect to Azure, Create resource, etc...}
I need my SP to use command Get-AzNetworkServiceTag but it always return empty values.
When I try command command Get-AzNetworkServiceTag with my own account I get expected result. I believe problem come from permission and your help is very welcome to set least privilege.
My current permissions looks like:
Do you know which one should I use ?
Alternative question is what is best practices to determine permissions based on powershell command ? Although permissions could name to determine there is so many that it's difficult to choose correct one. Thanks you.
The command Get-AzNetworkServiceTag essentially calls the Azure Management REST API - Service Tags - List, it is not related to Azure AD, to solve the issue, you need to assign the Azure RBAC role(not Azure AD admin role) to your service principal.
To solve the issue, the easiest way is to assign the built-in role e.g. Reader, Contributor to your service principal at the subscription scope. But if you want to the
least privilege, your option is to create a custom role then use it, you could follow the steps below.
1.Navigate to your subscription in the portal -> Access control (IAM) -> Add -> Add custom role, follow the screenshots.
Then skip the Permissions, in the JSON, click Edit, add Microsoft.Network/*/read to actions -> Next and create it.
After creating the custom role, wait for a while, navigate to the Access control (IAM) -> add the custom role to your service principal.
In conclusion, the Microsoft.Network/*/read action permission is the least privilege in this case, after giving the role, it will work fine.
Alternative question is what is best practice to determine permissions based on powershell command?
You just need to know what does the command do, then find the operation in the Azure resource provider operations, in this case, there is no such operation like Microsoft.Network/serviceTags/read, so we need to use Microsoft.Network/*/read at least.
You are facing this issue because Powershell cmdlet works differently than compared to MS Graph. Instead of permissions, Powershell require roles to do this operations. Please add Global Administrator role to your service principle and then try the Connect-AzAccount so that, the issue will be fixed.
For more details, you may refer to Assigning administrator roles in Azure Active Directory.
I've been looking for a way to identify a user in Active Directory without fail. I found this article which explains which fields are unique. It's a good starting point, but doesn't identify which fields are non-mutable. Further google queries result in AzureAD results on immutableId, which is what I want, but for regular AD. The case I'm trying to prevent is I use sAMAccountName (which is unique) to identify a user, but an admin decides to change the sAMAccountName for some reason (perhaps for uniformity) and I identify the same old user (with now a new sAMAccountName as a new user.
A few contenders from the article:
DN
UPN
sAMAccountName
ObjectGUID
Is there anything I'm missing? Is there an immutableId equivalent in pure AD (Not AzureAD)?
What you likely want is objectGUID. As "GUID" suggests, it is "globally unique". It doesn't change, even when the account is moved to another domain.
There is also objectSid (SID = Security Identifier), which is what Windows permissions use (the SID is stored in the permissions). It is also globally unique, but part of the SID is the SID of the domain. So if the account is moved to another AD domain, a new SID is generated on that domain, and the old objectSid is put in the sIDHistory of the new account.
There is some extra reading about that here: Security identifiers and globally unique identifiers
The distinguishedName changes whenever the account is renamed or moved to a new OU.
As you noted, both userPrincipalName and sAMAccountName can change too.
I have an Azure Active Directory (AAD) set up in my Azure subscription associated with an email address of mine, which we'll call A.
Some time later, I updated my Microsoft Account to use a new email address B as the primary email address, with A being associated with it still so it can still be used and the two email addresses treated as being one.
In AAD there is one user, whose user Id is A which appears not to be able to be changed as it is greyed-out. Attempting to add B fails with the error: You cannot add yourself.
Is there a way I can force the user name of the AAD user to be B instead of A?
The reason I ask is because I am trying to setup an Azure Key Vault in my subscription as it appears to be failing because whether or not I sign in as A or B in Azure Powershell, I am always signed in as B. This then causes this error message, which I appear to be unable to work around:
New-AzureKeyVault : Cannot find the Active Directory object 'B' in tenant
'{Tenant Id}'. Please make sure that the user or application service principal you are
authorizing is registered in the current subscription's Azure Active directory. The TenantID displayed by the cmdlet
'get-AzureSubscription -current' is the current subscription's Azure Active directory.
Can you check that you are using the latest bits for Key Vault PowerShell?
I talked with some folks internally and we believe that an experience like this may be expected if you are using an older version of the PowerShell CMDLETs, but the lastest version should be update to date and not run into the issue you are having.
If you find that you still hit this issue after upgrading, we may have a bug on our side that we should fix.
In that case, my suggestion is for you to create a new Admin User. Then delete the old Admin Account (you may need to Transfer Onwership of your AAD Subscription to the new Admin), and then recreate your account, which will pull the lastest information from that user.
However, I only reccommend trying this after having updated the PowerShell bits.
Please let us know if either of these methods resolves your issues.
Thanks,
Shawn Tabrizi
Searching for the user michael#mycontoso.com with the objectSid S-1-5-21-1234567890-123465789-123456789-123456, I only find a Foreign Security Principal CN=S-1-5-21-1234567890-123465789-123456789-123456,CN=ForeignSecurityPrincipals,DC=contoso,DC=com.
That foreign security principal does not contain the properties I have to read, so I guess I have to access the "Home AD" of that FSP.
Does a FSP have a property that always contains the LDAP path of the user object?
Is there a standardized/recommended way how to access the Home AD?
Sadly FSP don't contain the LDAP path of the referenced object.
(if it contain one, then it needs to be replicated once the object is rename/moved)
There seems no easy way to get back the containing AD using the SID from foreign forest.
If in local forest you may do it by binding to LDAP://<SID=S-1-xxxxx>.
A not-so-easy way is to build a domain SID to domain map.
Walk through each domain in trusted forests and build the map using the script here (the "The Script Solution" section).
https://learn.microsoft.com/en-us/archive/blogs/ashleymcglone/powershell-sid-walker-texas-ranger-part-3-exporting-domain-sids-and-trusts
SID of security principals are in the form of <domain SID>-<RID>.
e.g. domain SID of S-1-5-21-1234567890-123465789-123456789-123456 is S-1-5-21-1234567890-123465789-123456789.
By extracting the domain SID (if in .NET you can do it by using SecurityIdentifier class and the AccountDomainSid property) and the map then you can find out the containing domain.
You may try to retrieve the msDS-PrincipalName:
ldapsearch <options> -b "CN=ForeignSecurityPrincipals,DC=contoso,DC=com" "CN=S-1-5-21-1234567890-123465789-123456789-123456" msDS-PrincipalName
FOO\michael#mycontoso.com
Otherwise, the approach is as https://stackoverflow.com/a/27038494/10408280 describes:
Retrieve Domain identifier from first part of SID
Perform a lookup against that domain for the SID of the user or by sAMAccountName
[Rewriting my question based on comments]
My DN in Active Directory is "CN=Jesse Barnum,cn=users,dc=360works,dc=com".
I'm writing a web application which attempts to bind to the LDAP server, using the username and password of the active user. When doing the bind, I use the format "CN=$loginName$,cn=users,dc=360works,dc=com". Therefore, my users need to type in their full name (ie. 'Jesse Barnum'), rather than their shorter UID ('jbarnum').
Since users logging in typically expect to type a short name (like 'jbarnum', rather than 'Jesse Barnum'), I'd like for my DN to use my short name, like this: "CN=jbarnum,cn=users,dc=360works,dc=com". Doesn't it seem like that should be the default behavior (Windows Server 2012)?
So my question is: Can I change how the DN is constructed in Active Directory to use the short name instead of the full name?
You can change that behaviour but why should you? As you want to create a login there are much more elegant and more flexible solutions available.
When creating an LDAP based login I'm always doing the following:
bind to the server with a special account that can search the LDAP. Often that can also be done with a so called "anonymous bind".
search the LDAP for the given username in any attribute you like. A filter of (|(uid=username)(mail=username)(cn=username)) would allow your user to either use the uid, mail or cn to log in.
get the dn from the retrieved result and use that DN whic should be the DN of the users record) for a second bind - this time with the provided Password
That way the DN is completely irrellevant for your login as i is retrieved using the provided information based on attributes.
For an example in PHP have a look at https://gist.github.com/heiglandreas/5689592
The CN can be based on anything, really. It comes down to how you provision your users in the directory. If you use the out-of-box AD Users and Computers or AD Administrative Center tools to create users, they default to the full name format. You can change the CN after the fact, or if you are using something programmatic to create users, then you can create them however you like initially.