On Sun, 2021-09-19 at 13:16 -0500, Patrick Goetz via samba wrote:> Hi - > > This question is with reference to: > https://wiki.samba.org/index.php/Idmap_config_ad > > I think I know how this works, but there are still points of > confusion. > Given the example smb.conf file provided on the page referenced > above: > > [global] section of smb.conf: > ------------------------------------- > security = ADS > workgroup = SAMDOM > realm = SAMDOM.EXAMPLE.COM > > log file = /var/log/samba/%m.log > log level = 1 > > # Default ID mapping configuration for local BUILTIN accounts > # and groups on a domain member. The default (*) domain: > # - must not overlap with any domain ID mapping configuration! > # - must use a read-write-enabled back end, such as tdb. > idmap config * : backend = tdb > idmap config * : range = 3000-7999 > # - You must set a DOMAIN backend configuration > # idmap config for the SAMDOM domain > idmap config SAMDOM:backend = ad > idmap config SAMDOM:schema_mode = rfc2307 > idmap config SAMDOM:range = 10000-999999 > idmap config SAMDOM:unix_nss_info = yes > > vfs objects = acl_xattr > map acl inherit = yes > store dos attributes = yes > ------------------------------------- > > I believe "Default domain" is a bit of a misnomer referring to > accounts > that are identified by nss before it gets to winbind or sssd;You cannot use sssd with Samba.> i.e. > accounts found in /etc/passwd.No, they are for the AD BUILTIN domain and are not in etc/passwd or /etc/group> So on this system (assuming no other > directory services are configured), UIDs 3000-7999 are available for > use > in /etc/passwd.No, you cannot use that range in /etc/passwd or /etc/group> What I don't understand is why you're assigning a tdb > backend to this when the authentication is going to be handled by > pam_unix rather than pam_windbind. That's the main point of > confusion.That it is where your confusion starts, the ranges set in smb.conf are not handled by pam_unix, they are handled by pam_winbind or pam_krb5> > > Second, I'm assuming these 2 lines: > > idmap config SAMDOM:schema_mode = rfc2307 > idmap config SAMDOM:range = 10000-999999 > > Refer to the values that can be set for the uidNumber attribute in > the > Active Directory database and further that users authenticating on > this > linux system will have the UIDs and GIDs specified in the uidNumber > and > gidNumber attributes associated with their user record.Yes, but whilst the users & groups are authenticated by Samba AD, they are also Unix users & groups> > It seems like you don't necessarily need: > > idmap config SAMDOM:unix_nss_info = yesYou only require this setting if you want to use a specific login shell & home directory per user> > if everyone uses the same default shell and has the same home > directory > path; i.e. if these can be set using a global template. > > Based on the correctness of the above,I think you may need to rethink your ranges etc. Also are you aware that Samba has a way to upgrade an NT4-style domain to an AD domain ?> I"m converting a small NT domain > to Active Directory (by hand). The environment has several linux > machines with local UIDs assigned in the 1001-2000 range (but with > the > UIDs the same across the linux hosts). Since I don't plan to bind > most > of the linux machines to the domain (there is a vague user-driven > business case for this),I would rethink this, it is always better to join machines to the domain.> I would like the authorization to work the same > for Samba shares to AD bound Windows machines and the standalone > linux > workstations,Good luck with that, it is probably impossible to get the same numeric ID's on unjoined machines.> since these systems mount the same remote filesystems via > either SMB or NFS in the case of the linux systems. So my thought is > to > do something like this: > > portion of [global] section of smb.conf > ------------------------------------- > idmap config * : backend = tdb > idmap config * : range = 2000-2999 > # - You must set a DOMAIN backend configuration > # idmap config for the SAMDOM domain > idmap config SAMDOM:backend = ad > idmap config SAMDOM:schema_mode = rfc2307 > idmap config SAMDOM:range = 1001-1999That will allow you ONE local Unix user and 1998 AD Unix users I wouldn't recommended it.> ------------------------------------- > > Again, very unclear why I'm configuring a tdb database for local > accounts, if my understanding of how this works is correct.You aren't and, unfortunately, it appears you do not understand how it works.> This would > reserve the UIDs 2000-2999 for potential local use, while creating an > AD > UID mapping that seamlessly works with the existing linux systems. > Then > if I do end up binding some of these linux machines to the domain, > everything just works with no acl mapping, or anything like this.If you are using the winbind 'ad' backend, then there is no acl mapping.> > Any thoughts? Am I confused about how this works? My understanding > of > how the default domain works is based on this RHEL article: > https://access.redhat.com/solutions/1984483 >Try reading our documentation: https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member https://wiki.samba.org/index.php/Idmap_config_ad If you still do not understand something, please ask. I personally would ignore what you have now and set up a new AD domain and wouldn't use standalone servers, I would join everything to the domain. Rowland
On Sun, Sep 19, 2021 at 2:52 PM Rowland Penny via samba < samba at lists.samba.org> wrote:> On Sun, 2021-09-19 at 13:16 -0500, Patrick Goetz via samba wrote: > > Hi - > > > > This question is with reference to: > > https://wiki.samba.org/index.php/Idmap_config_ad > > > > I think I know how this works, but there are still points of > > confusion. > > Given the example smb.conf file provided on the page referenced > > above: > > > > [global] section of smb.conf: > > ------------------------------------- > > security = ADS > > workgroup = SAMDOM > > realm = SAMDOM.EXAMPLE.COM > > > > log file = /var/log/samba/%m.log > > log level = 1 > > > > # Default ID mapping configuration for local BUILTIN accounts > > # and groups on a domain member. The default (*) domain: > > # - must not overlap with any domain ID mapping configuration! > > # - must use a read-write-enabled back end, such as tdb. > > idmap config * : backend = tdb > > idmap config * : range = 3000-7999 > > # - You must set a DOMAIN backend configuration > > # idmap config for the SAMDOM domain > > idmap config SAMDOM:backend = ad > > idmap config SAMDOM:schema_mode = rfc2307 > > idmap config SAMDOM:range = 10000-999999 > > idmap config SAMDOM:unix_nss_info = yes > > > > vfs objects = acl_xattr > > map acl inherit = yes > > store dos attributes = yes > > ------------------------------------- > > > > I believe "Default domain" is a bit of a misnomer referring to > > accounts > > that are identified by nss before it gets to winbind or sssd; > > You cannot use sssd with Samba. >This may be a side note/topic, or some nuance, but I've seen this stated multiple times on the list in absolute terms like this, and it isn't strictly true, and very much depends on what you mean by "use sssd with Samba." Do the two work together and talk to each other? No. But can they be used side-by-side on the same system? Yes. I run them both on the same system in my environment in a couple of places, and it works perfectly fine. Do I recommend it? Absolutely not. I think in the vast majority of places - 7x9s - it makes more sense to just run winbind with Samba, and adding sssd provides nothing but more headaches - another configuration to maintain, another set of problems to debug, etc. But I've run into situations where I needed sssd on the same system as Samba, and it can be done.> I"m converting a small NT domain > > to Active Directory (by hand). The environment has several linux > > machines with local UIDs assigned in the 1001-2000 range (but with > > the > > UIDs the same across the linux hosts). Since I don't plan to bind > > most > > of the linux machines to the domain (there is a vague user-driven > > business case for this), > > I would rethink this, it is always better to join machines to the > domain. > >Not sure I would agree, but okay. Maybe for Patrick's benefit you could provide some additional detail and reasoning on this?> > I would like the authorization to work the same > > for Samba shares to AD bound Windows machines and the standalone > > linux > > workstations, > > Good luck with that, it is probably impossible to get the same numeric > ID's on unjoined machines. >Actually, it's definitely possible - I can think of at least two ways this can be accomplished: * Use sssd for NSS info instead of Winbind. Again, I'm not saying you _should_, I'm saying you can, and sssd seems to be deterministic in its ID mapping algorithm (similar to Winbind's idmap_autorid backend). * Use sssd's LDAP backend, and have the uid, gid, and shell attributes present for users in your AD schema. Yes, this adds further management and complication that may be undesirable, but it is doable, and is the most deterministic method :-). Again, I know sssd comes with its own challenges, but I see all these absolute statements of "you cannot do this" and "that is impossible" when my real-world experience says it is possible. Whatever I'm doing wrong is working in my environment.> > since these systems mount the same remote filesystems via > > either SMB or NFS in the case of the linux systems. So my thought is > > to > > do something like this: > > > > portion of [global] section of smb.conf > > ------------------------------------- > > idmap config * : backend = tdb > > idmap config * : range = 2000-2999 > > # - You must set a DOMAIN backend configuration > > # idmap config for the SAMDOM domain > > idmap config SAMDOM:backend = ad > > idmap config SAMDOM:schema_mode = rfc2307 > > idmap config SAMDOM:range = 1001-1999 > > That will allow you ONE local Unix user and 1998 AD Unix users > I wouldn't recommended it. >Why one local UNIX user? This doesn't make any sense.> > ------------------------------------- > > > > Again, very unclear why I'm configuring a tdb database for local > > accounts, if my understanding of how this works is correct. >You aren't and, unfortunately, it appears you do not understand how it> works. > >tdb is the default backend that the Samba winbind config recommends or defaults to, but it isn't the only one. You can look at winbind's rid or autorid backends if you prefer something more deterministic and less random (tdb isn't really random, just first-come, first-served on a per-system basis).> > This would > > reserve the UIDs 2000-2999 for potential local use, while creating an > > AD > > UID mapping that seamlessly works with the existing linux systems. > > Then > > if I do end up binding some of these linux machines to the domain, > > everything just works with no acl mapping, or anything like this. > > If you are using the winbind 'ad' backend, then there is no acl > mapping. > > > > > Any thoughts? Am I confused about how this works? My understanding > > of > > how the default domain works is based on this RHEL article: > > https://access.redhat.com/solutions/1984483 > > > > Try reading our documentation: > https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member > https://wiki.samba.org/index.php/Idmap_config_ad > > If you still do not understand something, please ask. > > I personally would ignore what you have now and set up a new AD domain > and wouldn't use standalone servers, I would join everything to the > domain. > >Why? You've stated this multiple times, and you haven't really provided any clear reasoning for the original user as to why you think joining to the domain is the best option. Maybe it is, but could you help him understand? -Nick
Finally getting back to this. On 9/19/21 13:51, Rowland Penny via samba wrote:> On Sun, 2021-09-19 at 13:16 -0500, Patrick Goetz via samba wrote: >> Hi - >> >> This question is with reference to: >> https://wiki.samba.org/index.php/Idmap_config_ad >> >> I think I know how this works, but there are still points of >> confusion. >> Given the example smb.conf file provided on the page referenced >> above: >> >> [global] section of smb.conf: >> ------------------------------------- >> security = ADS >> workgroup = SAMDOM >> realm = SAMDOM.EXAMPLE.COM >> >> log file = /var/log/samba/%m.log >> log level = 1 >> >> # Default ID mapping configuration for local BUILTIN accounts >> # and groups on a domain member. The default (*) domain: >> # - must not overlap with any domain ID mapping configuration! >> # - must use a read-write-enabled back end, such as tdb. >> idmap config * : backend = tdb >> idmap config * : range = 3000-7999 >> # - You must set a DOMAIN backend configuration >> # idmap config for the SAMDOM domain >> idmap config SAMDOM:backend = ad >> idmap config SAMDOM:schema_mode = rfc2307 >> idmap config SAMDOM:range = 10000-999999 >> idmap config SAMDOM:unix_nss_info = yes >> >> vfs objects = acl_xattr >> map acl inherit = yes >> store dos attributes = yes >> ------------------------------------- >> >> I believe "Default domain" is a bit of a misnomer referring to >> accounts >> that are identified by nss before it gets to winbind or sssd; > > You cannot use sssd with Samba. > >> i.e. >> accounts found in /etc/passwd. > > No, they are for the AD BUILTIN domain and are not in etc/passwd or > /etc/group > >> So on this system (assuming no other >> directory services are configured), UIDs 3000-7999 are available for >> use >> in /etc/passwd. > > No, you cannot use that range in /etc/passwd or /etc/group > >> What I don't understand is why you're assigning a tdb >> backend to this when the authentication is going to be handled by >> pam_unix rather than pam_windbind. That's the main point of >> confusion. > > That it is where your confusion starts, the ranges set in smb.conf are > not handled by pam_unix, they are handled by pam_winbind or pam_krb5 >Yes, I'm confused, but mainly because I don't understand the purpose of the default BUILTIN domain. The domain we're configuring in the documentation is SAMDOM -- what is the default domain for?>> >> >> Second, I'm assuming these 2 lines: >> >> idmap config SAMDOM:schema_mode = rfc2307 >> idmap config SAMDOM:range = 10000-999999 >> >> Refer to the values that can be set for the uidNumber attribute in >> the >> Active Directory database and further that users authenticating on >> this >> linux system will have the UIDs and GIDs specified in the uidNumber >> and >> gidNumber attributes associated with their user record. > > Yes, but whilst the users & groups are authenticated by Samba AD, they > are also Unix users & groups > >> >> It seems like you don't necessarily need: >> >> idmap config SAMDOM:unix_nss_info = yes > > You only require this setting if you want to use a specific login shell > & home directory per user > >> >> if everyone uses the same default shell and has the same home >> directory >> path; i.e. if these can be set using a global template. >> >> Based on the correctness of the above, > > I think you may need to rethink your ranges etc. Also are you aware > that Samba has a way to upgrade an NT4-style domain to an AD domain ? > >> I"m converting a small NT domain >> to Active Directory (by hand). The environment has several linux >> machines with local UIDs assigned in the 1001-2000 range (but with >> the >> UIDs the same across the linux hosts). Since I don't plan to bind >> most >> of the linux machines to the domain (there is a vague user-driven >> business case for this), > > I would rethink this, it is always better to join machines to the > domain. > >> I would like the authorization to work the same >> for Samba shares to AD bound Windows machines and the standalone >> linux >> workstations, > > Good luck with that, it is probably impossible to get the same numeric > ID's on unjoined machines.You've convinced me I need to bind all machines (including the linux machines) to the domain, but then I don't really see the point of using RFC 2307 extensions. The AD server will equate the user's SID with their UID regardless of what the UID is, and all users have an assigned UID based on the id mapping, whatever it is. I guess if you already have a large filesystem with legacy POSIX permissions, using RFC 2307 prevents you from having to re-assign all the permissions. In the absence of that concern, and in the case of a single domain with Samba AD I would probably just use UID=RID, which I think is one of the options. However, I'm not seeing why this wouldn't work: User foobar has the UID/GID 1517 on an unaffiliated linux host. So in AD, I set the uidNumber and gidNumber for UserName foobar to 1517. Presumably the owner UID for any files on the Samba file server for AD user foobar would be 1517, so an NFS mount using sec=sys to the linux machine would have the right permissions. If they log in to a Windows client, the SID would be equated to UID 1517 by the DC and permissions on the Samba share to the Windows client would work, too. (Yes, of course this would turn into a maintenance headache, which is why you've convinced me to bind everything to the domain.) I'm pushing back on the "impossible" claim.> >> since these systems mount the same remote filesystems via >> either SMB or NFS in the case of the linux systems. So my thought is >> to >> do something like this: >> >> portion of [global] section of smb.conf >> ------------------------------------- >> idmap config * : backend = tdb >> idmap config * : range = 2000-2999 >> # - You must set a DOMAIN backend configuration >> # idmap config for the SAMDOM domain >> idmap config SAMDOM:backend = ad >> idmap config SAMDOM:schema_mode = rfc2307 >> idmap config SAMDOM:range = 1001-1999 > > That will allow you ONE local Unix user and 1998 AD Unix users > I wouldn't recommended it. >> ------------------------------------- >> >> Again, very unclear why I'm configuring a tdb database for local >> accounts, if my understanding of how this works is correct. > > You aren't and, unfortunately, it appears you do not understand how it > works. > >> This would >> reserve the UIDs 2000-2999 for potential local use, while creating an >> AD >> UID mapping that seamlessly works with the existing linux systems. >> Then >> if I do end up binding some of these linux machines to the domain, >> everything just works with no acl mapping, or anything like this. > > If you are using the winbind 'ad' backend, then there is no acl > mapping. > >> >> Any thoughts? Am I confused about how this works? My understanding >> of >> how the default domain works is based on this RHEL article: >> https://access.redhat.com/solutions/1984483 >> > > Try reading our documentation: > https://wiki.samba.org/index.php/Setting_up_Samba_as_a_Domain_Member > https://wiki.samba.org/index.php/Idmap_config_ad > > If you still do not understand something, please ask. > > I personally would ignore what you have now and set up a new AD domain > and wouldn't use standalone servers, I would join everything to the > domain. > > Rowland > > > >