> > > The 'Nooooo, don't do that is: > > > Don't change the UPN > > > > Why not? It's a recommended best practice to choose a subdomain of > > your primary domain (e.g. "ad.example.com"), and then add alternate > > UPN suffix which allows user logons to match their email addresses. > > > > In fact, this page on the Samba Wiki recommends just that: > > https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ#My_User_Logins_Does_Not_Match_My_Email > > It wont for long ;-) > The UPN is single valued, you can only have one. > It is the logon name for the user and is composed of the users account > name, the '@' sign and a dns domain name. This dns domain must be a > domain in the current domain forest, which means (on a Samba DC, at > least) the same thing. > If you need an email attribute that doesn't match the UPN, use on of the > email attributes that AD provides.Are you sure about making this change to the documentation. The attribute being added is the not single-valued UPN-Suffixes (uPNSuffixes) rather than the single-valued User-Principal-Name (userPrincipalName), despite this thread repeatedly saying "change" the UPN. It appears from the Microsoft documentation that the suffixes (multiple allowed) provide a mapping to the UPN, rather than change it, and one of the named security benefits is to hide the actual UPN. In any case, it also appears that many newer MS products, e.g. Azure, Outlook 2016, etc. _require_ the login name to match the e-mail address. Please look at this again before committing to the documentation change, which seems to diverge from the goal of making SAMBA work like a Windows AD DC. Here are some MS documents (contemporaneous with document linked in documentation prior to this change): https://docs.microsoft.com/en-us/windows/desktop/adschema/a-upnsuffixes https://docs.microsoft.com/en-us/windows/desktop/adschema/a-userprincipalname and in this one, https://docs.microsoft.com/en-us/windows/desktop/AD/naming-properties it is noted that: "A UPN suffix has the following restrictions: It must be the DNS name of a domain, but does not need to be the name of the domain that contains the user. It must be the name of a domain in the current domain forest, or an alternate name listed in the upnSuffixes attribute of the Partitions container within the Configuration container." NOTE the "or" in the last requirement. It does not need to be "a domain in the current domain forest" and it seems that the whole (major) point of the suffix to be able to use a logon name at a higher level in the forest hierarchy than where the AD DC sits.
> > > > The 'Nooooo, don't do that is: > > > > Don't change the UPN > > > > > > Why not? It's a recommended best practice to choose a subdomain of > > > your primary domain (e.g. "ad.example.com"), and then add alternate > > > UPN suffix which allows user logons to match their email addresses. > > > > > > In fact, this page on the Samba Wiki recommends just that: > > > https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ#My_User_Logins_Does_Not_Match_My_Email > > > > It wont for long ;-) > > The UPN is single valued, you can only have one. > > It is the logon name for the user and is composed of the users account > > name, the '@' sign and a dns domain name. This dns domain must be a > > domain in the current domain forest, which means (on a Samba DC, at > > least) the same thing. > > If you need an email attribute that doesn't match the UPN, use on of the > > email attributes that AD provides.> Are you sure about making this change to the documentation. The attribute being added is the not single-valued UPN-Suffixes (uPNSuffixes) rather than the single-valued User-Principal-Name (userPrincipalName), despite this thread repeatedly saying "change" the UPN.... actually, am okay with change to documentation, but not with characterization of what OP is doing. In the blog post he was only setting a upnSuffix, and not trying to change the UPN, and people screamed "Don't change the UPN," seemingly confusing the issue. Isn't he right to ask, "why not?" Are people trying to say that the upnSuffix attribute doesn't work in SAMBA like Microsoft says it should in a Windows AD DC? The suffix should allow a logon of "user at domain.com" even if the AD domain is "abc.domain.com" and the UPN is therefore "user at abc.domain.com"
On Sun, 3 Mar 2019 12:30:51 +0000 (UTC) Billy Bob <billysbobs at yahoo.com> wrote:> > > > > > > The 'Nooooo, don't do that is: > > > > Don't change the UPN > > > > > > Why not? It's a recommended best practice to choose a subdomain of > > > your primary domain (e.g. "ad.example.com"), and then add > > > alternate UPN suffix which allows user logons to match their > > > email addresses. > > > > > > In fact, this page on the Samba Wiki recommends just that: > > > https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ#My_User_Logins_Does_Not_Match_My_Email > > > > It wont for long ;-) > > The UPN is single valued, you can only have one. > > It is the logon name for the user and is composed of the users > > account name, the '@' sign and a dns domain name. This dns domain > > must be a domain in the current domain forest, which means (on a > > Samba DC, at least) the same thing. > > If you need an email attribute that doesn't match the UPN, use on > > of the email attributes that AD provides. > > Are you sure about making this change to the documentation. The > attribute being added is the not single-valued UPN-Suffixes > (uPNSuffixes) rather than the single-valued User-Principal-Name > (userPrincipalName), despite this thread repeatedly saying "change" > the UPN. It appears from the Microsoft documentation that the > suffixes (multiple allowed) provide a mapping to the UPN, rather than > change it, and one of the named security benefits is to hide the > actual UPN. In any case, it also appears that many newer MS products, > e.g. Azure, Outlook 2016, etc. _require_ the login name to match the > e-mail address. Please look at this again before committing to the > documentation change, which seems to diverge from the goal of making > SAMBA work like a Windows AD DC. > > Here are some MS documents (contemporaneous with document linked in > documentation prior to this change): > https://docs.microsoft.com/en-us/windows/desktop/adschema/a-upnsuffixes > > https://docs.microsoft.com/en-us/windows/desktop/adschema/a-userprincipalname > > and in this one, > https://docs.microsoft.com/en-us/windows/desktop/AD/naming-properties > it is noted that: > "A UPN suffix has the following restrictions: > It must be the DNS name of a domain, but does not need to be the name > of the domain that contains the user. It must be the name of a domain > in the current domain forest, or an alternate name listed in the > upnSuffixes attribute of the Partitions container within the > Configuration container." NOTE the "or" in the last requirement. It > does not need to be "a domain in the current domain forest" and it > seems that the whole (major) point of the suffix to be able to use a > logon name at a higher level in the forest hierarchy than where the > AD DC sits.This is basically what it now says, it is also my understanding that there is no need to change the userPrincipalName attribute (which is single valued), you add 'uPNSuffixes' attributes. Now whether Samba will use them is another story, what I do know is that you cannot use subdomains (yet) on a Samba AD domain, so the 'forest' and 'domain' will be the same. Rowland
On Sun, 3 Mar 2019 13:14:35 +0000 (UTC) Billy Bob <billysbobs at yahoo.com> wrote:> > > > > > The 'Nooooo, don't do that is: > > > > > Don't change the UPN > > > > > > > > Why not? It's a recommended best practice to choose a subdomain > > > > of your primary domain (e.g. "ad.example.com"), and then add > > > > alternate UPN suffix which allows user logons to match their > > > > email addresses. > > > > > > > > In fact, this page on the Samba Wiki recommends just that: > > > > https://wiki.samba.org/index.php/Active_Directory_Naming_FAQ#My_User_Logins_Does_Not_Match_My_Email > > > > > > It wont for long ;-) > > > The UPN is single valued, you can only have one. > > > It is the logon name for the user and is composed of the users > > > account name, the '@' sign and a dns domain name. This dns domain > > > must be a domain in the current domain forest, which means (on a > > > Samba DC, at least) the same thing. > > > If you need an email attribute that doesn't match the UPN, use on > > > of the email attributes that AD provides. > > > Are you sure about making this change to the documentation. The > > attribute being added is the not single-valued UPN-Suffixes > > (uPNSuffixes) rather than the single-valued User-Principal-Name > > (userPrincipalName), despite this thread repeatedly saying "change" > > the UPN. > > ... actually, am okay with change to documentation, but not with > characterization of what OP is doing. In the blog post he was only > setting a upnSuffix, and not trying to change the UPN, and people > screamed "Don't change the UPN," seemingly confusing the issue.OK, I will hold my hand up, I misread his blog :-( To be honest I just skimmed it and missed that he was adding a UPN suffix and not changing the UPN. I think he needs to make it a bit more obvious ;-)>Isn't he right to ask, "why not?"Yes.> Are people trying to say that the upnSuffix attribute doesn't work in > SAMBA like Microsoft says it should in a Windows AD DC?I do not know, I have never tried them, but this could be one of those things (from a Samba point of view) where the code doesn't exist for it to work on a Samba DC, they should work on Windows machines.>The suffix should allow a logon of "user at domain.com" even if the AD >domain is "abc.domain.com" and the UPN is therefore "user at abc.domain.com"Well yes, but possibly only on Windows machines. Rowland