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
I *think* we're all on the same page now. My suggestion was adding an additional entry to the UPN Suffixes list, and using that suffix (without "ad.") when creating new users. This Microsoft doc [1] says:> By convention, this should map to the user's email name. The point of > the UPN is to consolidate the email and logon namespaces so that the > user only needs to remember a single name.If this doesn't work in Samba, that would be a major blow to my plans. On Sun, Mar 3, 2019 at 9:11 AM Rowland Penny via samba <samba at lists.samba.org> wrote: [snip]> 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'm not sure what is meant by the phrase "change the UPN". In particular, the use of the word "the" implies that there is only a single UPN to be changed. That doesn't make sense; the UPN is an attribute of the User class, so every user has a UPN which could be changed (but never should).> I think he needs to make it a bit more obvious ;-)I'll assume you're being sarcastic :-) I was very careful when writing that to always say "UPN Suffix" and never just "UPN".> >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.I've tested this with a Windows 7 client machine, and it worked as expected. How can we test this for non-Windows machines? Where can I enter "user at example.com" for a domain named "ad.example.com" and confirm that things work as expected? In other words, how would one go about discovering a potential Samba deficiency (compared to Windows) in this regard? I see one reference to uPNSuffixes in source4 [2], and it appears that the 'net' command even appears to support provide an --add-upn-suffix option [3]. [1] https://docs.microsoft.com/en-us/windows/desktop/AD/naming-properties [2] https://gitlab.com/samba-team/samba/blob/d1c2fe8907/source4/dsdb/common/util_trusts.c#L925 [3] https://gitlab.com/samba-team/samba/blob/d1c2fe8907/python/samba/netcmd/domain.py#L3162
> I *think* we're all on the same page now. My suggestion was adding an > additional entry to the UPN Suffixes list, and using that suffix > (without "ad.") when creating new users. > > This Microsoft doc [1] says: > > > By convention, this should map to the user's email name. The point of > > the UPN is to consolidate the email and logon namespaces so that the > > user only needs to remember a single name. > > If this doesn't work in Samba, that would be a major blow to my plans.I think it would be an even bigger blow to SAMBA's plans ;-)
On Sun, 3 Mar 2019 14:34:55 -0500 Jonathon Reinhart <jonathon.reinhart at gmail.com> wrote:> I *think* we're all on the same page now. My suggestion was adding an > additional entry to the UPN Suffixes list, and using that suffix > (without "ad.") when creating new users. > > This Microsoft doc [1] says: > > > By convention, this should map to the user's email name. The point > > of the UPN is to consolidate the email and logon namespaces so that > > the user only needs to remember a single name. > > If this doesn't work in Samba, that would be a major blow to my plans.I personally have never had a reason to change a users UPN and if you use samba-tool to create a user you will get a UPN in the form of 'username at REALM' where 'REALM' is the dns domain in uppercase. Whilst you will be able to add multiple upnSuffixes attributes and they will very probably work on Windows, I do not know if they will work on a Samba DC or Unix domain member. Only further testing will prove this one way or the other.> > On Sun, Mar 3, 2019 at 9:11 AM Rowland Penny via samba > <samba at lists.samba.org> wrote: > [snip] > > 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'm not sure what is meant by the phrase "change the UPN".As far has I am concerned 'UPN' is shorthand for the userPrincipalName attribute.> In > particular, the use of the word "the" implies that there is only a > single UPN to be changed. That doesn't make sense; the UPN is an > attribute of the User class, so every user has a UPN which could be > changed (but never should).Yes, totally agree the UPN should never be changed and by 'the' I meant 'a users UPN'.> > > I think he needs to make it a bit more obvious ;-) > > I'll assume you're being sarcastic :-) I was very careful when > writing that to always say "UPN Suffix" and never just "UPN".I totally missed it, that is all I can say.> > > >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. > > I've tested this with a Windows 7 client machine, and it worked as > expected. How can we test this for non-Windows machines? Where can I > enter "user at example.com" for a domain named "ad.example.com" and > confirm that things work as expected? In other words, how would one > go about discovering a potential Samba deficiency (compared to > Windows) in this regard? > > I see one reference to uPNSuffixes in source4 [2], and it appears that > the 'net' command even appears to support provide an --add-upn-suffix > option [3].Not sure how to test this either, but I will look into it. Rowland