Every developer in my company has one email address. eg: Name#country.domain.com
But they also have a domain address/name Name#country.domain.net(hereby refereed as DN)
This is causing a lot of confusion
One is used as email(.com) while the other is not, even-though they both look like emails
Some applications use DN to provide access, some applications use email address to provide access
Some developers country changed, they decided not to change the email which was okay for network admin. But the DN had to be changed to the correct country they are in. Why is it mandatory for domain address to change the country while email can remain as it is?
Due to the last problem #3, we had to find the applications that use DN and update them all.
Here are some more questions:
Why this is email address and then a DN, why cant there be only one?
What exactly is the purpose of DN?
Does every user need to have this(or just developers)?
The abbreviation "DN" refers to the distinguishedName attribute in AD. It also uniquely identifies the account, but it is not what you're talking about here.
What you're talking about is the userPrincipalName attribute (or UPN). It is usually the "username" (sAMAccountName attribute) followed by # and the DNS domain name of the AD domain. It sounds like that is how your organization is setup. Since the accounts moved domains, the domain portion of the UPN needs to change.
However, technically, the UPN suffix (the domain portion) can be anything, especially any domain that your organization controls. It could even be set the same as the email address, it just doesn't have to be.
So if the UPN in your organization does not match the email address, then either your admins just haven't put the effort into making that happen, or they have a reason for not doing so.
You cannot authenticate to AD directly with an email address. If an application just asks for an email and password and using that to authenticate against AD, then it would have to look up that email address on the domain to find the username and then use the username (either sAMAccountName or userPrincipalName) to authenticate.
There is some more reading here that might help: User Naming Attributes
Related
By default all the User Principle Name and mail for O365 will be same but how to change User Principle Name and also how can we create an user with different User Principle Name and different mail.
To change the User Principal Name, execute the following command,
Set-MsolUserPrincipalName -UserPrincipalName "davidc#contoso.com" -NewUserPrincipalName "davidchew#contoso.com"
The Set-MsolUserPrincipalName cmdlet changes the User Principal Name, or user ID, of a user.
It is not recommended to use different UPN and Mail-id due to the below reasons:
User confusion
Skype for Business Online
Office ProPlus
Mobile Applications
ActiveSync
To know more in detail please refer these links,
Ref1, Ref2.
Currently, I am facing a scenario, where I should differentiate whether a given user belongs to a Gmail account or a G Suite account.
I have the email id of the user. As of now, the only visible difference is that the email address has a different domain name for a G Suite account. For an normal Gmail account the domain name is "gmail.com".
I don't feel safe to rely on this. What is the recommended way to identify the account type of an user?
Thanks in advance.
This is safe to rely on, and many users have already used this technique successfully.
Emails addresses contain only one "#" sign, so in order to verify this you could use a simple function such as:
function isGSuite(email) {
return email.split("#")[1] != 'gmail.com';
}
In fact, there is no API or any other method you can use to check whether the account is actually a GSuite account. Given an e-mail address that is not gmail, there is no public way of determining whether it is part of a GSuite domain, since that could present security and privacy issues.
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.
We are moving user stores from openldap to AD for our wso2 identity server. One problem we've identified is that the default username value, sAMAccountName, is limited to 20 characters.
Based on a bit of googling, most people in AD environments use the UPN value, in the form username#domain. However, this is not an acceptable solution for us. We do not want our users to type in username#domain. We want them to continue typing just 'username' like they are used to.
Is it possible to configure the user-mtg.xml file to append an #domain when users try to log in? Or is there a simpler way to make wso2 identity server aware of the AD domain and just 'know' to append it.
The sAMAccountName is meant to be short because users have to type it in, and the less you have to type to identify yourself, the better.
The userPrincipalName came along later. I think the idea was that it would be the same as the user's email address. That way, people just use their email address to login. Less things to remember. Microsoft does seem to be pushing this method more.
Users can use either/or to login (to a Windows machine anyway). But those are your only options, so you'll have to pick which one to advertise to your users.
I have an application that uses email addresses for user authentication.
I know that some universities use Shibboleth for user authentication, and I was wondering what the process is for being able to read emails from the university database that is used for Shibboleth. Note that I do not care about authentication through Shibboleth, I only need to be able to read the email addresses.
Is it general for all universities that use Shibboleth, or is each a unique case?
Any links to documentation on how to do this process would be greatly appreciated. Thank you.
Shibboleth can be configured (IdP-side) to release user attributes along with authentication data, for example the user's email address. Client-side, assuming you're going though shibd, you'll need a setting in your attribute-map.xml that says "map attribute with OID x.y.z.a to environment variable USERMAIL" and then you get the result in that environment variable. The example config should already contain it.
This would be the same for everybody insofar as the OID for "email" is always the same, but you'd have to negotiate with the IdPs (universities) or their federations so that they will actually release that attribute to you.
Shibboleth is used by many institutions, but by no means all. Many use Athens, proxies or IP recognition, among other things.
As far as I am aware, a user's email address is not tied directly to the Shib system. When a user tries to access a Shibboleth-protected resource they are taken to their institution's login page to authenticate themselves. They might enter their email address to authenticate or they might enter a username, they might be auto logged-in based on their IP address, or something else.
The institution does send back an affiliation through Shib data transfer upon successful login, something like student#brown.ac.uk but this is not necessarily the email address the user used to login. I guess they could send that but it has not been used in system's I've worked on.
Shibboleth is commonly used to check that the user is from an institution that has purchased access to a protected resource rather than identifying a particular user from that institution so the user's email isn't needed.
Not sure if this helps at all: http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonAffiliation