On 20/10/15 11:43, mathias dufresne wrote:> 2015-10-20 11:10 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: > >> On 20/10/15 09:05, mathias dufresne wrote: >> >>> 2015-10-19 18:08 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com >>> <mailto:rowlandpenny241155 at gmail.com>>: >>> >>> >>> On 19/10/15 16:46, mathias dufresne wrote: >>> >>> AD from Samba or Microsoft is mainly a database for storing >>> users (and >>> associated stuffs). It comes also with stuffs (protocols) to >>> connect and >>> retrieve information. >>> >>> How the client uses these information is, as always, a choice >>> from that >>> specific client. >>> >>> Your AD client is your Squid/Squidguard(ian) server. Its job >>> as AD client >>> is to get some users information from AD to build system >>> users. I insist on >>> the fact system users are forged. Purely. >>> >>> What is responsible of that forging process? What you declared in >>> /etc/nsswitch.conf. >>> Generally it is winbind, sssd or nlscd. >>> >>> Each one of these tools comes with its own set of option, >>> tweak and >>> configuration files to define how to forge users from local >>> system point of >>> view. >>> >>> Each one except for Winbind which forge users as it decide to, >>> no matter >>> the desires of local system admin. At least this is how I >>> understood >>> winbind behaviour (which has no configuration file for what I >>> know). >>> >>> >>> Well, apart from idmap.ldb on a DC and the idmap_config lines in >>> smb.conf on a domain member, there are no configuration files. :-D >>> >>> >>> idmap.ldb -> TDB database version 6, little-endian hash size 10000 bytes >>> idmap_config lines in smb.conf -> how would you set them to configure >>> Winbind to not add domain to user? >>> >> Well, I will give you this one, on DC you cannot, but on a domain member >> you can: winbind use default domain = yes >> However, it is not recommended to use the DC as a fileserver > > OK for that option I didn't knew which is effectively to remove domain part > of user name. > Not OK with your remark regarding file server: why changing the way system > users are created means to share files?I never mentioned how users are created in relation to how to share files, you seem to be wanting to use the DC to server files, I was just pointing out that this is not recommended.> >> >> To use gidNumber rather than 100 which seems to reflect "primaryGroupID: >>> 513", >>> >> Give the users unique uidNumbers and Domain Users a gidNumber > > What gidNumber is given to system user? Is it gidNumber attribute content > or something else? > What I mean is simple: if I configure gidNumber for all my users, don't you > think I do that for my system users have this gidNumber in use rather gid > set to 100? > Are you telling me I'm stupid to want users with different GID? Isn't it a > common UNIX practice? Are you telling me all others admins doing that are > also stupid?Well in the context of AD *YES*, in AD, every users primary group is 'Domain Users' and there is no concept of a private group. You control access by using NTFS ACLs, either by setting these from windows or with 'setfacl'. To change a users primary group, you will need to change the users PrimaryGidNumber attribute to contain the RID of the new group, it is possible but has to be done in a certain way. I would not suggest doing this, windows expects every user to be a member of 'Domain Users'.> > >> >> to set up home directory to unixHomeDirectory or to homeDirectory rather >>> than /home/<short domain name>/ sAMAccountName? >>> >> template homedir = /home/%U > > False. Here you gave me an option to force one kind of home directory for > all users. This is not what I was asking. Can't you imagine that some users > could need some other home directory? What if some applicative user is > named "toto" and this user needs to have a home directory set to > /home/toto_applicative_folder?No, you never asked that, you just said it couldn't be done and I also said using the DC as a fileserver is not recommended, on a domain member, the 'unixHomeDirectory' attribute is available and winbind will use it.> Should I modify this user .bashrc or .profile to force an export of HOME > variable? Is it a nice way to proceed when using the right tool I can set > this different home directory directly in AD?No, just use Samba in AD mode as recommended.> > >> >> Is it possible to use CN or userPrincipalName rather SAMAccountName when >>> building the system user? >>> >> No, you have lost me again, what do you mean by 'building the system user' > > OK, here we going further. > AD is a database. When we want to use users from AD into Linux or UNIX > systems, we retrieve some information from AD (Login, UID, GID, Gecos, Home > directory, Shell) and we use these information to generate lines looking > like lines from /etc/passwd. This process is the fact of building system > user.Ah, you mean extracting the users info from AD like this: rowland at debnet:~$ getent passwd rowland rowland:*:10000:10000::/home/rowland:/bin/bash This is on a domain member (in fact it is on the netbook, I am typing this on)> Using the very same AD and changing what attribute is used to fill some > field of these user lines will result in different user. > > Example: > uid:x:uidNumber:gidNumber:gecos:homeDirectory:loginShell > or > sAMAccountName:x:uidNumber:gidNumber:displayName:unixHomeDirectory:loginShell > > These are two ways to use AD content to generate system users. Different > users. > > I'm not telling one way is better than the other, I'm telling AD can be > used in several ways. And using winbind is minimizing this number of ways > as it is lacking configuration options.No, you are confusing the ways that info can be extracted from AD with what the OS actually needs, winbind can and will supply this info, but only fully on a domain member.> >> >> >>> So it is not configurable. >>> >> Yes it is, fully on a domain member, partially on a DC > > Show me. Stop telling it is possible without example as it has no value. > I gave two different user lines, show me how with winbind I can obtain both.You are using nlscd and as such to tell it to extract certain info, some of this info is not really required, but I have added the 'gecos' attribute to my AD object and now get this: rowland at debnet:~$ getent passwd rowland rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash So, I get the username, the users UID, their primary GID, gecos, Unix home directory and what shell the user will use, all obtained from AD, what else does the OS need?> > >> >> >>> >>> Perhaps you are using winbind, in that case winbind is >>> responsible to add >>> domain and backslashes when forging your users. >>> >>> I don't know at all nlscd but some are using it on that >>> mailing list. So I >>> expect it does its job too. >>> >>> I tried SSSD for the company I'm working these days and it >>> comes with lot >>> of configuration options. I expect it can force addition of AD >>> domain to >>> username but it is not the default behaviour. >>> >>> On some DC where it uses winbind to forge users: >>> >>> >>> No, sorry, I cannot understand what you mean by forge, in English >>> this word is used for creating your own banknotes or a thing used >>> by a blacksmith. >>> >>> >>> In fact a blacksmith forges items using blacksmith tools. He creates >>> these items. These items can be something else than his own tools. In fact >>> if a blacksmith was only able to craft its own tools and nothing else for >>> other peoples, this kind of job would have quickly disappeared... >>> >> So what you meant was 'create a user', please don't try to get creative >> with the English language, just say what you mean. >> As for forge and a blacksmith, the word can mean the place a blacksmith >> works, the 'action' of the blacksmith doing something i.e. a blacksmith >> forges horseshoes (technical note: no, this actually done by a farrier) >> (further note: blacksmiths have virtually disappeared) >> Have we played enough with *my* language yet? > > In fact what I meant was "using some tool to retrieve some information from > AD to create a system user using these information". I just thought forging > was clear enough, my bad.Very bad, forging has nothing to with retrieving, extracting, pulling, obtaining (I could go on) info from AD.> > >> >> >>> Anyway you get the point, forging, crafting, building, assembling >>> elements to obtain something else, they are same concept. >>> >> Same basic concept, but they all mean totally different things. > > Perhaps, I'm not English native. In my own language, French, all these > words have a similar background described by "assembling elements to obtain > something else". Which is what winbind and consort are doing. Assembling > elements from AD.They do not really mean that in English.> >> >> >>> >>> If you add a Uidnumber to user a user in AD, then it should show >>> on a DC, even if you are not using winbind. >>> >>> >>> Here you should have meant "if you are using winbind" which is true for >>> UID and wrong for GID which is not reflecting gidNumber configured into AD. >>> >> Ah, that is because you think that giving a user a gidNumber, this becomes >> the users main GID, it doesn't. The users primary gid number is obtained >> from what is set in the aptly named 'PrimaryGidNumber' attribute, AD >> obtains this and then uses whatever gidNumber that groups object contains. > > False. In system point of view user primary group is the one declared in > user line (the equivalent of line from /etc/passwd) and this can be changed > using "sg" command for example. > > And what attribute is used to generate that line is a choice. Samba team > has chosen to use 'PrimaryGidNumber' attribute,Yes, but what else would you use for a users primary group number (the clue is in the attribute name)> well, that's their choiceYes and it was a good choice with relevance to AD and as I said it really doesn't need to be changed, you just need to use windows permissions instead of Unix permissions.> and it is most certainly relevant in certain conditions. Not all. And > that's so obvious other tools used to generate system users from AD have > this configurable. >This is because they are trying to force AD to work with Unix, instead of Unix working with windows.>> >> >> Should I speak again about home dir ? Shell ? Gecos ? login attribute ?... >> >> No, because I have already dealt with that. > > I still don't see where you dealt with that : )Well I did :-)> > >> >> >>> SSSD grant sys admin possibility to chose all that, forging users as >>> sysadmin wants to (which is most generally what his bosses asked to him). >>> Winbind can't. >>> And here the question is "how can the user have username using <username> >>> syntax rather than <domainname>\<username>. Is it possible to remove domain >>> part from username when using winbind? With the idmap_config lines perhaps >>> ? :p >>> >> Anything that sssd can do, winbind can do, but, as I have admitted, only >> fully on a domain member. > > Wrong. Very wrong. One thing to push us a bit outside of the current > subject: SSSD can connect on several domains and several LDAP trees which > are not domains at same time. Can winbind do that? Just for fun : )You can get winbind to know about different domains, but why would you bother, do it the windows way, have one domain and use 'sites'. Rowland> > I know you were speaking about generating user lines from one and only one > AD domain. Once more: show me how to generate different user lines for the > same user into the same AD, without changing anything into that AD. Then > I'll start to accept winbind is configurable. Until now, for me it is not. > > >> >> >>> And more: how system is configured to retrieve users from AD! AD seems >>> well configured: it works. The question is about how to obtain system users >>> according to what this user needs and not according to what winbind thinks >>> it is the right way. >>> >> As I said, winbind will do what sssd does, in fact winbind is that good, >> the later versions of sssd implements a lot of the winbind code. > > I never say winbind is not well coded, useless or anything like that. I say > winbind is not as configurable as SSSD which makes SSSD more suitable for > some needs. > > And once again, show me how to generate different user lines with winbind > when using the AD DB, just changing what attribute is used for parts of > these lines (gecos, username, home dir, all of them). > > >> >> Rowland >> >> >> -- >> To unsubscribe from this list go to the following URL and read the >> instructions: https://lists.samba.org/mailman/options/samba >>
2015-10-20 13:39 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>:> On 20/10/15 11:43, mathias dufresne wrote: > >> 2015-10-20 11:10 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: >> >> On 20/10/15 09:05, mathias dufresne wrote: >>> >>> 2015-10-19 18:08 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com >>>> <mailto:rowlandpenny241155 at gmail.com>>: >>>> >>>> >>>> On 19/10/15 16:46, mathias dufresne wrote: >>>> >>>> AD from Samba or Microsoft is mainly a database for storing >>>> users (and >>>> associated stuffs). It comes also with stuffs (protocols) to >>>> connect and >>>> retrieve information. >>>> >>>> How the client uses these information is, as always, a choice >>>> from that >>>> specific client. >>>> >>>> Your AD client is your Squid/Squidguard(ian) server. Its job >>>> as AD client >>>> is to get some users information from AD to build system >>>> users. I insist on >>>> the fact system users are forged. Purely. >>>> >>>> What is responsible of that forging process? What you declared >>>> in >>>> /etc/nsswitch.conf. >>>> Generally it is winbind, sssd or nlscd. >>>> >>>> Each one of these tools comes with its own set of option, >>>> tweak and >>>> configuration files to define how to forge users from local >>>> system point of >>>> view. >>>> >>>> Each one except for Winbind which forge users as it decide to, >>>> no matter >>>> the desires of local system admin. At least this is how I >>>> understood >>>> winbind behaviour (which has no configuration file for what I >>>> know). >>>> >>>> >>>> Well, apart from idmap.ldb on a DC and the idmap_config lines in >>>> smb.conf on a domain member, there are no configuration files. :-D >>>> >>>> >>>> idmap.ldb -> TDB database version 6, little-endian hash size 10000 bytes >>>> idmap_config lines in smb.conf -> how would you set them to configure >>>> Winbind to not add domain to user? >>>> >>>> Well, I will give you this one, on DC you cannot, but on a domain member >>> you can: winbind use default domain = yes >>> However, it is not recommended to use the DC as a fileserver >>> >> >> OK for that option I didn't knew which is effectively to remove domain >> part >> of user name. >> Not OK with your remark regarding file server: why changing the way system >> users are created means to share files? >> > > I never mentioned how users are created in relation to how to share files, > you seem to be wanting to use the DC to server files, I was just pointing > out that this is not recommended.I don't meant using DC as file server. In fact, as advised in the Wiki, I try to discourage users to do that. I'm now building an AD infrastructure for a very large company. This company has needs and restrictions. As they all have when they are big enough. All that I say is without stuff to configure what attribute is used for each field of system user lines, it is possible I can't fill the need of this company. Anyway, once more you tried to make me say something I did not say.> > > >> >>> To use gidNumber rather than 100 which seems to reflect "primaryGroupID: >>> >>>> 513", >>>> >>>> Give the users unique uidNumbers and Domain Users a gidNumber >>> >> >> What gidNumber is given to system user? Is it gidNumber attribute content >> or something else? >> What I mean is simple: if I configure gidNumber for all my users, don't >> you >> think I do that for my system users have this gidNumber in use rather gid >> set to 100? >> Are you telling me I'm stupid to want users with different GID? Isn't it a >> common UNIX practice? Are you telling me all others admins doing that are >> also stupid? >> > > Well in the context of AD *YES*, in AD, every users primary group is > 'Domain Users' and there is no concept of a private group. You control > access by using NTFS ACLs, either by setting these from windows or with > 'setfacl'. To change a users primary group, you will need to change the > users PrimaryGidNumber attribute to contain the RID of the new group, it is > possible but has to be done in a certain way. I would not suggest doing > this, windows expects every user to be a member of 'Domain Users'. > >Sorry, but that's wrong. You are speaking about Windows users retrieved from AD (you are speaking about NTFS which is not a too-much-UNIXlike FS). AD is a database, yes I insist, which can be used by Windows clients and UNIX-like clients. Windows systems needs are most generally different than UNIX-like systems needs. There is the rfc2307 which is here to define a common way to proceed for UNIX-like systems. This RFC is not The Truth. It is a try to make thing more generic. If some of us wants to use non-rfc2307 field to build system users, this person must be able to do it.> >> >> >>> to set up home directory to unixHomeDirectory or to homeDirectory rather >>> >>>> than /home/<short domain name>/ sAMAccountName? >>>> >>>> template homedir = /home/%U >>> >> >> False. Here you gave me an option to force one kind of home directory for >> all users. This is not what I was asking. Can't you imagine that some >> users >> could need some other home directory? What if some applicative user is >> named "toto" and this user needs to have a home directory set to >> /home/toto_applicative_folder? >> > > No, you never asked that, you just said it couldn't be done and I also > said using the DC as a fileserver is not recommended, on a domain member, > the 'unixHomeDirectory' attribute is available and winbind will use it.Once more, the choice of used attribute to set an information is forced by Winbind. What if I have to homeDirectory? What if I have some other field? What if I'm forced to set a telephone number in unixHomeDirectory?> > > Should I modify this user .bashrc or .profile to force an export of HOME >> variable? Is it a nice way to proceed when using the right tool I can set >> this different home directory directly in AD? >> > > No, just use Samba in AD mode as recommended.As recommanded. Only as recommanded. Always follow the path and never go walk in grass. Don't think, some do that for you... That's to avoid that way of mind I left Microsoft world or I refuse to enter the Apple World.> > > >> >> >>> Is it possible to use CN or userPrincipalName rather SAMAccountName when >>> >>>> building the system user? >>>> >>>> No, you have lost me again, what do you mean by 'building the system >>> user' >>> >> >> OK, here we going further. >> AD is a database. When we want to use users from AD into Linux or UNIX >> systems, we retrieve some information from AD (Login, UID, GID, Gecos, >> Home >> directory, Shell) and we use these information to generate lines looking >> like lines from /etc/passwd. This process is the fact of building system >> user. >> > > Ah, you mean extracting the users info from AD like this: > > rowland at debnet:~$ getent passwd rowland > rowland:*:10000:10000::/home/rowland:/bin/bash > > This is on a domain member (in fact it is on the netbook, I am typing this > on)OK, that's better. You show a line. What about the configuration you are using to get it?> > > Using the very same AD and changing what attribute is used to fill some >> field of these user lines will result in different user. >> >> Example: >> uid:x:uidNumber:gidNumber:gecos:homeDirectory:loginShell >> or >> >> sAMAccountName:x:uidNumber:gidNumber:displayName:unixHomeDirectory:loginShell >> >> These are two ways to use AD content to generate system users. Different >> users. >> >> I'm not telling one way is better than the other, I'm telling AD can be >> used in several ways. And using winbind is minimizing this number of ways >> as it is lacking configuration options. >> > > No, you are confusing the ways that info can be extracted from AD with > what the OS actually needs, winbind can and will supply this info, but only > fully on a domain member.Explain please. I don't understand in what I'm confused. I'm showing two ways to build user lines using different attributes from AD. Two possible ways when using a tool which can be configured (even vastool should be able to let sysadmin decide what attribute will be used). You tell I don't understand, I'm confused... when the next part of of your comment has no meaning: how the very some tool with the very same configuration would produce these two different lines for the same user? Would it be a reliable tool? Note I don't say winbind is not reliable.> > > >> >>> >>> So it is not configurable. >>>> >>>> Yes it is, fully on a domain member, partially on a DC >>> >> >> Show me. Stop telling it is possible without example as it has no value. >> I gave two different user lines, show me how with winbind I can obtain >> both. >> > > You are using nlscd and as such to tell it to extract certain info, some > of this info is not really required, but I have added the 'gecos' attribute > to my AD object and now get this: > > rowland at debnet:~$ getent passwd rowland > rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash > > So, I get the username, the users UID, their primary GID, gecos, Unix home > directory and what shell the user will use, all obtained from AD, what else > does the OS need?Glad to read that: to achieve that you don't use winbind only, so you use another layer to get needed configuration options.> > > >> >> >>> >>> >>>> Perhaps you are using winbind, in that case winbind is >>>> responsible to add >>>> domain and backslashes when forging your users. >>>> >>>> I don't know at all nlscd but some are using it on that >>>> mailing list. So I >>>> expect it does its job too. >>>> >>>> I tried SSSD for the company I'm working these days and it >>>> comes with lot >>>> of configuration options. I expect it can force addition of AD >>>> domain to >>>> username but it is not the default behaviour. >>>> >>>> On some DC where it uses winbind to forge users: >>>> >>>> >>>> No, sorry, I cannot understand what you mean by forge, in English >>>> this word is used for creating your own banknotes or a thing used >>>> by a blacksmith. >>>> >>>> >>>> In fact a blacksmith forges items using blacksmith tools. He creates >>>> these items. These items can be something else than his own tools. In >>>> fact >>>> if a blacksmith was only able to craft its own tools and nothing else >>>> for >>>> other peoples, this kind of job would have quickly disappeared... >>>> >>>> So what you meant was 'create a user', please don't try to get creative >>> with the English language, just say what you mean. >>> As for forge and a blacksmith, the word can mean the place a blacksmith >>> works, the 'action' of the blacksmith doing something i.e. a blacksmith >>> forges horseshoes (technical note: no, this actually done by a farrier) >>> (further note: blacksmiths have virtually disappeared) >>> Have we played enough with *my* language yet? >>> >> >> In fact what I meant was "using some tool to retrieve some information >> from >> AD to create a system user using these information". I just thought >> forging >> was clear enough, my bad. >> > > Very bad, forging has nothing to with retrieving, extracting, pulling, > obtaining (I could go on) info from AD.Blabla, nothing else.> > > >> >> >>> >>> Anyway you get the point, forging, crafting, building, assembling >>>> elements to obtain something else, they are same concept. >>>> >>>> Same basic concept, but they all mean totally different things. >>> >> >> Perhaps, I'm not English native. In my own language, French, all these >> words have a similar background described by "assembling elements to >> obtain >> something else". Which is what winbind and consort are doing. Assembling >> elements from AD. >> > > They do not really mean that in English.I'm still learning : )> > > >> >>> >>> >>>> If you add a Uidnumber to user a user in AD, then it should show >>>> on a DC, even if you are not using winbind. >>>> >>>> >>>> Here you should have meant "if you are using winbind" which is true for >>>> UID and wrong for GID which is not reflecting gidNumber configured into >>>> AD. >>>> >>>> Ah, that is because you think that giving a user a gidNumber, this >>> becomes >>> the users main GID, it doesn't. The users primary gid number is obtained >>> from what is set in the aptly named 'PrimaryGidNumber' attribute, AD >>> obtains this and then uses whatever gidNumber that groups object >>> contains. >>> >> >> False. In system point of view user primary group is the one declared in >> user line (the equivalent of line from /etc/passwd) and this can be >> changed >> using "sg" command for example. >> >> And what attribute is used to generate that line is a choice. Samba team >> has chosen to use 'PrimaryGidNumber' attribute, >> > > Yes, but what else would you use for a users primary group number (the > clue is in the attribute name)gidNumber? To put that differently: in your mind, what is the purpose of RFC2307 attribute named gidNumber? when from https://www.ietf.org/rfc/rfc2307.txt ( nisSchema.1.1 NAME 'gidNumber' DESC 'An integer uniquely identifying a group in an administrative domain' EQUALITY integerMatch SYNTAX 'INTEGER' *SINGLE-VALUE *)> > > well, that's their choice >> > > Yes and it was a good choice with relevance to AD and as I said it really > doesn't need to be changed, you just need to use windows permissions > instead of Unix permissions. > > and it is most certainly relevant in certain conditions. Not all. And >> that's so obvious other tools used to generate system users from AD have >> this configurable. >> >> > This is because they are trying to force AD to work with Unix, instead of > Unix working with windows.Yep. Totally true. And why would I do that? Because it is possible and because UNIX-like are not meant to work as Microsoft systems. I use AD as a user database. Nothing else. What is done with information retrieved from a database is the choice of who retrieve the info. No one else.> > > >>> >>> Should I speak again about home dir ? Shell ? Gecos ? login attribute >>> ?... >>> >>> No, because I have already dealt with that. >>> >> >> I still don't see where you dealt with that : ) >> > > Well I did :-)And you don't show it. Nice way of mind.> > > >> >> >>> >>> SSSD grant sys admin possibility to chose all that, forging users as >>>> sysadmin wants to (which is most generally what his bosses asked to >>>> him). >>>> Winbind can't. >>>> And here the question is "how can the user have username using >>>> <username> >>>> syntax rather than <domainname>\<username>. Is it possible to remove >>>> domain >>>> part from username when using winbind? With the idmap_config lines >>>> perhaps >>>> ? :p >>>> >>>> Anything that sssd can do, winbind can do, but, as I have admitted, only >>> fully on a domain member. >>> >> >> Wrong. Very wrong. One thing to push us a bit outside of the current >> subject: SSSD can connect on several domains and several LDAP trees which >> are not domains at same time. Can winbind do that? Just for fun : ) >> > > You can get winbind to know about different domains, but why would you > bother, do it the windows way, have one domain and use 'sites'.No, you misunderstood me. You claimed "Anything that sssd can do, winbind can do" which is false, to not say it is a lie. I'm still waiting for an example of Winbind configuration use any LDAP attribute I want for any field of a system user. And you told Winbind can also be configured to access several domains at same time without anything to demonstrate that affirmation. You could have told me your Winbind prepare your coffee in the morning, I won't have trusted you more nor less.> > > Rowland > > > >> I know you were speaking about generating user lines from one and only one >> AD domain. Once more: show me how to generate different user lines for the >> same user into the same AD, without changing anything into that AD. Then >> I'll start to accept winbind is configurable. Until now, for me it is not. >> >> >> >>> >>> And more: how system is configured to retrieve users from AD! AD seems >>>> well configured: it works. The question is about how to obtain system >>>> users >>>> according to what this user needs and not according to what winbind >>>> thinks >>>> it is the right way. >>>> >>>> As I said, winbind will do what sssd does, in fact winbind is that good, >>> the later versions of sssd implements a lot of the winbind code. >>> >> >> I never say winbind is not well coded, useless or anything like that. I >> say >> winbind is not as configurable as SSSD which makes SSSD more suitable for >> some needs. >> >> And once again, show me how to generate different user lines with winbind >> when using the AD DB, just changing what attribute is used for parts of >> these lines (gecos, username, home dir, all of them). >> >> >> >>> Rowland >>> >>> >>> -- >>> To unsubscribe from this list go to the following URL and read the >>> instructions: https://lists.samba.org/mailman/options/samba >>> >>> > > -- > To unsubscribe from this list go to the following URL and read the > instructions: https://lists.samba.org/mailman/options/samba >
2015-10-20 15:43 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>:> On 20/10/15 14:03, mathias dufresne wrote: > >> 2015-10-20 13:39 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: >> >> On 20/10/15 11:43, mathias dufresne wrote: >>> >>> 2015-10-20 11:10 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: >>>> >>>> On 20/10/15 09:05, mathias dufresne wrote: >>>> >>>>> 2015-10-19 18:08 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com >>>>> >>>>>> <mailto:rowlandpenny241155 at gmail.com>>: >>>>>> >>>>>> >>>>>> On 19/10/15 16:46, mathias dufresne wrote: >>>>>> >>>>>> AD from Samba or Microsoft is mainly a database for storing >>>>>> users (and >>>>>> associated stuffs). It comes also with stuffs (protocols) to >>>>>> connect and >>>>>> retrieve information. >>>>>> >>>>>> How the client uses these information is, as always, a >>>>>> choice >>>>>> from that >>>>>> specific client. >>>>>> >>>>>> Your AD client is your Squid/Squidguard(ian) server. Its job >>>>>> as AD client >>>>>> is to get some users information from AD to build system >>>>>> users. I insist on >>>>>> the fact system users are forged. Purely. >>>>>> >>>>>> What is responsible of that forging process? What you >>>>>> declared >>>>>> in >>>>>> /etc/nsswitch.conf. >>>>>> Generally it is winbind, sssd or nlscd. >>>>>> >>>>>> Each one of these tools comes with its own set of option, >>>>>> tweak and >>>>>> configuration files to define how to forge users from local >>>>>> system point of >>>>>> view. >>>>>> >>>>>> Each one except for Winbind which forge users as it decide >>>>>> to, >>>>>> no matter >>>>>> the desires of local system admin. At least this is how I >>>>>> understood >>>>>> winbind behaviour (which has no configuration file for what >>>>>> I >>>>>> know). >>>>>> >>>>>> >>>>>> Well, apart from idmap.ldb on a DC and the idmap_config lines in >>>>>> smb.conf on a domain member, there are no configuration files. >>>>>> :-D >>>>>> >>>>>> >>>>>> idmap.ldb -> TDB database version 6, little-endian hash size 10000 >>>>>> bytes >>>>>> idmap_config lines in smb.conf -> how would you set them to configure >>>>>> Winbind to not add domain to user? >>>>>> >>>>>> Well, I will give you this one, on DC you cannot, but on a domain >>>>>> member >>>>>> >>>>> you can: winbind use default domain = yes >>>>> However, it is not recommended to use the DC as a fileserver >>>>> >>>>> OK for that option I didn't knew which is effectively to remove domain >>>> part >>>> of user name. >>>> Not OK with your remark regarding file server: why changing the way >>>> system >>>> users are created means to share files? >>>> >>>> I never mentioned how users are created in relation to how to share >>> files, >>> you seem to be wanting to use the DC to server files, I was just pointing >>> out that this is not recommended. >>> >> >> I don't meant using DC as file server. In fact, as advised in the Wiki, I >> try to discourage users to do that. >> I'm now building an AD infrastructure for a very large company. This >> company has needs and restrictions. As they all have when they are big >> enough. >> All that I say is without stuff to configure what attribute is used for >> each field of system user lines, it is possible I can't fill the need of >> this company. >> Anyway, once more you tried to make me say something I did not say. >> >> >> >>> >>> To use gidNumber rather than 100 which seems to reflect "primaryGroupID: >>>>> >>>>> 513", >>>>>> >>>>>> Give the users unique uidNumbers and Domain Users a gidNumber >>>>>> >>>>> What gidNumber is given to system user? Is it gidNumber attribute >>>> content >>>> or something else? >>>> What I mean is simple: if I configure gidNumber for all my users, don't >>>> you >>>> think I do that for my system users have this gidNumber in use rather >>>> gid >>>> set to 100? >>>> Are you telling me I'm stupid to want users with different GID? Isn't >>>> it a >>>> common UNIX practice? Are you telling me all others admins doing that >>>> are >>>> also stupid? >>>> >>>> Well in the context of AD *YES*, in AD, every users primary group is >>> 'Domain Users' and there is no concept of a private group. You control >>> access by using NTFS ACLs, either by setting these from windows or with >>> 'setfacl'. To change a users primary group, you will need to change the >>> users PrimaryGidNumber attribute to contain the RID of the new group, it >>> is >>> possible but has to be done in a certain way. I would not suggest doing >>> this, windows expects every user to be a member of 'Domain Users'. >>> >>> >>> Sorry, but that's wrong. You are speaking about Windows users retrieved >> from AD (you are speaking about NTFS which is not a too-much-UNIXlike FS). >> AD is a database, yes I insist, which can be used by Windows clients and >> UNIX-like clients. Windows systems needs are most generally different than >> UNIX-like systems needs. >> There is the rfc2307 which is here to define a common way to proceed for >> UNIX-like systems. This RFC is not The Truth. It is a try to make thing >> more generic. If some of us wants to use non-rfc2307 field to build system >> users, this person must be able to do it. >> >> >> >>>> to set up home directory to unixHomeDirectory or to homeDirectory rather >>>>> >>>>> than /home/<short domain name>/ sAMAccountName? >>>>>> >>>>>> template homedir = /home/%U >>>>>> >>>>> False. Here you gave me an option to force one kind of home directory >>>> for >>>> all users. This is not what I was asking. Can't you imagine that some >>>> users >>>> could need some other home directory? What if some applicative user is >>>> named "toto" and this user needs to have a home directory set to >>>> /home/toto_applicative_folder? >>>> >>>> No, you never asked that, you just said it couldn't be done and I also >>> said using the DC as a fileserver is not recommended, on a domain member, >>> the 'unixHomeDirectory' attribute is available and winbind will use it. >>> >> >> Once more, the choice of used attribute to set an information is forced by >> Winbind. What if I have to homeDirectory? What if I have some other field? >> What if I'm forced to set a telephone number in unixHomeDirectory? >> >> >> >>> Should I modify this user .bashrc or .profile to force an export of HOME >>> >>>> variable? Is it a nice way to proceed when using the right tool I can >>>> set >>>> this different home directory directly in AD? >>>> >>>> No, just use Samba in AD mode as recommended. >>> >> >> As recommanded. Only as recommanded. Always follow the path and never go >> walk in grass. Don't think, some do that for you... >> That's to avoid that way of mind I left Microsoft world or I refuse to >> enter the Apple World. >> >> >> >>> >>> >>>> Is it possible to use CN or userPrincipalName rather SAMAccountName when >>>>> >>>>> building the system user? >>>>>> >>>>>> No, you have lost me again, what do you mean by 'building the system >>>>>> >>>>> user' >>>>> >>>>> OK, here we going further. >>>> AD is a database. When we want to use users from AD into Linux or UNIX >>>> systems, we retrieve some information from AD (Login, UID, GID, Gecos, >>>> Home >>>> directory, Shell) and we use these information to generate lines looking >>>> like lines from /etc/passwd. This process is the fact of building system >>>> user. >>>> >>>> Ah, you mean extracting the users info from AD like this: >>> >>> rowland at debnet:~$ getent passwd rowland >>> rowland:*:10000:10000::/home/rowland:/bin/bash >>> >>> This is on a domain member (in fact it is on the netbook, I am typing >>> this >>> on) >>> >> >> OK, that's better. You show a line. What about the configuration you are >> using to get it? >> >> >> >>> Using the very same AD and changing what attribute is used to fill some >>> >>>> field of these user lines will result in different user. >>>> >>>> Example: >>>> uid:x:uidNumber:gidNumber:gecos:homeDirectory:loginShell >>>> or >>>> >>>> >>>> sAMAccountName:x:uidNumber:gidNumber:displayName:unixHomeDirectory:loginShell >>>> >>>> These are two ways to use AD content to generate system users. Different >>>> users. >>>> >>>> I'm not telling one way is better than the other, I'm telling AD can be >>>> used in several ways. And using winbind is minimizing this number of >>>> ways >>>> as it is lacking configuration options. >>>> >>>> No, you are confusing the ways that info can be extracted from AD with >>> what the OS actually needs, winbind can and will supply this info, but >>> only >>> fully on a domain member. >>> >> >> Explain please. I don't understand in what I'm confused. >> >> I'm showing two ways to build user lines using different attributes from >> AD. Two possible ways when using a tool which can be configured (even >> vastool should be able to let sysadmin decide what attribute will be >> used). >> You tell I don't understand, I'm confused... when the next part of of your >> comment has no meaning: how the very some tool with the very same >> configuration would produce these two different lines for the same user? >> Would it be a reliable tool? >> Note I don't say winbind is not reliable. >> >> >> >>> >>> So it is not configurable. >>>>> >>>>>> Yes it is, fully on a domain member, partially on a DC >>>>>> >>>>> Show me. Stop telling it is possible without example as it has no >>>> value. >>>> I gave two different user lines, show me how with winbind I can obtain >>>> both. >>>> >>>> You are using nlscd and as such to tell it to extract certain info, some >>> of this info is not really required, but I have added the 'gecos' >>> attribute >>> to my AD object and now get this: >>> >>> rowland at debnet:~$ getent passwd rowland >>> rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash >>> >>> So, I get the username, the users UID, their primary GID, gecos, Unix >>> home >>> directory and what shell the user will use, all obtained from AD, what >>> else >>> does the OS need? >>> >> >> Glad to read that: to achieve that you don't use winbind only, so you use >> another layer to get needed configuration options. >> >> >> >>> >>> >>>> >>>>> Perhaps you are using winbind, in that case winbind is >>>>>> responsible to add >>>>>> domain and backslashes when forging your users. >>>>>> >>>>>> I don't know at all nlscd but some are using it on that >>>>>> mailing list. So I >>>>>> expect it does its job too. >>>>>> >>>>>> I tried SSSD for the company I'm working these days and it >>>>>> comes with lot >>>>>> of configuration options. I expect it can force addition of >>>>>> AD >>>>>> domain to >>>>>> username but it is not the default behaviour. >>>>>> >>>>>> On some DC where it uses winbind to forge users: >>>>>> >>>>>> >>>>>> No, sorry, I cannot understand what you mean by forge, in >>>>>> English >>>>>> this word is used for creating your own banknotes or a thing >>>>>> used >>>>>> by a blacksmith. >>>>>> >>>>>> >>>>>> In fact a blacksmith forges items using blacksmith tools. He creates >>>>>> these items. These items can be something else than his own tools. In >>>>>> fact >>>>>> if a blacksmith was only able to craft its own tools and nothing else >>>>>> for >>>>>> other peoples, this kind of job would have quickly disappeared... >>>>>> >>>>>> So what you meant was 'create a user', please don't try to get >>>>>> creative >>>>>> >>>>> with the English language, just say what you mean. >>>>> As for forge and a blacksmith, the word can mean the place a blacksmith >>>>> works, the 'action' of the blacksmith doing something i.e. a blacksmith >>>>> forges horseshoes (technical note: no, this actually done by a farrier) >>>>> (further note: blacksmiths have virtually disappeared) >>>>> Have we played enough with *my* language yet? >>>>> >>>>> In fact what I meant was "using some tool to retrieve some information >>>> from >>>> AD to create a system user using these information". I just thought >>>> forging >>>> was clear enough, my bad. >>>> >>>> Very bad, forging has nothing to with retrieving, extracting, pulling, >>> obtaining (I could go on) info from AD. >>> >> >> Blabla, nothing else. >> >> >> >>> >>> >>>> Anyway you get the point, forging, crafting, building, assembling >>>>> >>>>>> elements to obtain something else, they are same concept. >>>>>> >>>>>> Same basic concept, but they all mean totally different things. >>>>>> >>>>> Perhaps, I'm not English native. In my own language, French, all these >>>> words have a similar background described by "assembling elements to >>>> obtain >>>> something else". Which is what winbind and consort are doing. Assembling >>>> elements from AD. >>>> >>>> They do not really mean that in English. >>> >> >> I'm still learning : ) >> >> >> >>> >>> >>>>> If you add a Uidnumber to user a user in AD, then it should show >>>>>> on a DC, even if you are not using winbind. >>>>>> >>>>>> >>>>>> Here you should have meant "if you are using winbind" which is true >>>>>> for >>>>>> UID and wrong for GID which is not reflecting gidNumber configured >>>>>> into >>>>>> AD. >>>>>> >>>>>> Ah, that is because you think that giving a user a gidNumber, this >>>>>> >>>>> becomes >>>>> the users main GID, it doesn't. The users primary gid number is >>>>> obtained >>>>> from what is set in the aptly named 'PrimaryGidNumber' attribute, AD >>>>> obtains this and then uses whatever gidNumber that groups object >>>>> contains. >>>>> >>>>> False. In system point of view user primary group is the one declared >>>> in >>>> user line (the equivalent of line from /etc/passwd) and this can be >>>> changed >>>> using "sg" command for example. >>>> >>>> And what attribute is used to generate that line is a choice. Samba team >>>> has chosen to use 'PrimaryGidNumber' attribute, >>>> >>>> Yes, but what else would you use for a users primary group number (the >>> clue is in the attribute name) >>> >> >> gidNumber? >> >> To put that differently: in your mind, what is the purpose of RFC2307 >> attribute named gidNumber? >> >> when from https://www.ietf.org/rfc/rfc2307.txt >> ( nisSchema.1.1 NAME 'gidNumber' >> DESC 'An integer uniquely identifying a group in an >> administrative domain' >> EQUALITY integerMatch SYNTAX 'INTEGER' *SINGLE-VALUE *) >> >> >> >> >> >>> well, that's their choice >>> Yes and it was a good choice with relevance to AD and as I said it really >>> doesn't need to be changed, you just need to use windows permissions >>> instead of Unix permissions. >>> >>> and it is most certainly relevant in certain conditions. Not all. And >>> >>>> that's so obvious other tools used to generate system users from AD have >>>> this configurable. >>>> >>>> >>>> This is because they are trying to force AD to work with Unix, instead >>> of >>> Unix working with windows. >>> >> >> Yep. Totally true. And why would I do that? Because it is possible and >> because UNIX-like are not meant to work as Microsoft systems. >> >> I use AD as a user database. Nothing else. What is done with information >> retrieved from a database is the choice of who retrieve the info. No one >> else. >> >> >> >>> >>> Should I speak again about home dir ? Shell ? Gecos ? login attribute >>>>> ?... >>>>> >>>>> No, because I have already dealt with that. >>>>> >>>>> I still don't see where you dealt with that : ) >>>> >>>> Well I did :-) >>> >> >> And you don't show it. Nice way of mind. >> >> >> >>> >>> >>>> SSSD grant sys admin possibility to chose all that, forging users as >>>>> >>>>>> sysadmin wants to (which is most generally what his bosses asked to >>>>>> him). >>>>>> Winbind can't. >>>>>> And here the question is "how can the user have username using >>>>>> <username> >>>>>> syntax rather than <domainname>\<username>. Is it possible to remove >>>>>> domain >>>>>> part from username when using winbind? With the idmap_config lines >>>>>> perhaps >>>>>> ? :p >>>>>> >>>>>> Anything that sssd can do, winbind can do, but, as I have admitted, >>>>>> only >>>>>> >>>>> fully on a domain member. >>>>> >>>>> Wrong. Very wrong. One thing to push us a bit outside of the current >>>> subject: SSSD can connect on several domains and several LDAP trees >>>> which >>>> are not domains at same time. Can winbind do that? Just for fun : ) >>>> >>>> You can get winbind to know about different domains, but why would you >>> bother, do it the windows way, have one domain and use 'sites'. >>> >> >> No, you misunderstood me. You claimed "Anything that sssd can do, winbind >> can do" which is false, to not say it is a lie. I'm still waiting for an >> example of Winbind configuration use any LDAP attribute I want for any >> field of a system user. >> And you told Winbind can also be configured to access several domains at >> same time without anything to demonstrate that affirmation. You could have >> told me your Winbind prepare your coffee in the morning, I won't have >> trusted you more nor less. >> >> >> >>> Rowland >>> >>> >>> >>> I know you were speaking about generating user lines from one and only >>>> one >>>> AD domain. Once more: show me how to generate different user lines for >>>> the >>>> same user into the same AD, without changing anything into that AD. Then >>>> I'll start to accept winbind is configurable. Until now, for me it is >>>> not. >>>> >>>> >>>> >>>> And more: how system is configured to retrieve users from AD! AD seems >>>>> >>>>>> well configured: it works. The question is about how to obtain system >>>>>> users >>>>>> according to what this user needs and not according to what winbind >>>>>> thinks >>>>>> it is the right way. >>>>>> >>>>>> As I said, winbind will do what sssd does, in fact winbind is that >>>>>> good, >>>>>> >>>>> the later versions of sssd implements a lot of the winbind code. >>>>> >>>>> I never say winbind is not well coded, useless or anything like that. I >>>> say >>>> winbind is not as configurable as SSSD which makes SSSD more suitable >>>> for >>>> some needs. >>>> >>>> And once again, show me how to generate different user lines with >>>> winbind >>>> when using the AD DB, just changing what attribute is used for parts of >>>> these lines (gecos, username, home dir, all of them). >>>> >>>> >>>> > OK, lets go back to something you posted earlier: > > Example: > uid:x:uidNumber:gidNumber:gecos:homeDirectory:loginShell > or > > sAMAccountName:x:uidNumber:gidNumber:displayName:unixHomeDirectory:loginShell > > Lets take them one by one. > uid is the users login and so is sAMAccountName >Since when they must be the same? That's a wrong affirmation you posted. These are two different LDAP attributes with, I agree, same meaning. But in no case they must be identical. As they can be different we must think them as different. I could have used CN and sAMAccountName in my lines examples. Your answer could have been the same with these two attributes as they could contain the same value. CN length is 64 characters max. SAMAccountName is 20 characters max. For uid attribute I'm not sure about its max length, more than 20 char. I expect... According to the length, they are almost the same but not exactly. So there is a real meaning not to use one and prefer the other: one is so short you can't fill it with anything you want. That's just given as example, to show they are not the same. the next two are the same attributes> gecos is usually used for the users full name and so is displayName >Same: two fields, two possible information. They can be the same, they must not be the same. In my flat I can do whatever I want. At work I can't. At work if some boss tells me "we will 'telephoneNumber' for user login" and if it is technically possible, they will log using the content of that attribute. Because that's their company, not mine, I don't give orders, I only find solution to their desires and issues.> We now come to a problem, if you are extracting homeDirectory from AD then > you will get something like this: //computername/username i.e. it is where > the users windows home directory is stored. The users Unix home directory > is in unixHomeDirectory >https://msdn.microsoft.com/en-us/library/ms676190%28v=vs.85%29.aspx says this LDAP attribute is a string encoded in unicode. It also speecify that this field must contains UNC path or a fully qualified local path including the drive letter. This has meaning only if you intend to use that attribute for Windows systems. This is a string so we can set any string into that field. Including a NFS path if we want to. I agree this is not meant to, but who cares? It's possible, humans are numerous ans someone will do that one day or another. And once you would have to manage such an AD, what would you prefer: changing each users or changing one configuration file (which can be used by lots of servers, I agree)? In my little experience, as modifying all users in AD is quiet critical, nobody would give a "go" to such a change. Changing servers configuration file is a server-by-server task, finding a boss to give a "go" to such a task is easy.> the last one is the same attribute > > As I have shown, winbind will extract the required info, without having to > manually setup a config file to select which attribute to map. There is no > reason to use sssd or nlscd with Samba unless you need to use the DC as a > fileserver and this is not recommended.Winbind retrieves some information which can be the right ones. For any reason, good or bad, if these retrieved information are not the right ones, how to deal with that using winbind?> > > Rowland > >
On 20/10/15 15:12, mathias dufresne wrote:> 2015-10-20 15:43 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: > >> On 20/10/15 14:03, mathias dufresne wrote: >> >>> 2015-10-20 13:39 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: >>> >>> On 20/10/15 11:43, mathias dufresne wrote: >>>> 2015-10-20 11:10 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com>: >>>>> On 20/10/15 09:05, mathias dufresne wrote: >>>>> >>>>>> 2015-10-19 18:08 GMT+02:00 Rowland Penny <rowlandpenny241155 at gmail.com >>>>>> >>>>>>> <mailto:rowlandpenny241155 at gmail.com>>: >>>>>>> >>>>>>> >>>>>>> On 19/10/15 16:46, mathias dufresne wrote: >>>>>>> >>>>>>> AD from Samba or Microsoft is mainly a database for storing >>>>>>> users (and >>>>>>> associated stuffs). It comes also with stuffs (protocols) to >>>>>>> connect and >>>>>>> retrieve information. >>>>>>> >>>>>>> How the client uses these information is, as always, a >>>>>>> choice >>>>>>> from that >>>>>>> specific client. >>>>>>> >>>>>>> Your AD client is your Squid/Squidguard(ian) server. Its job >>>>>>> as AD client >>>>>>> is to get some users information from AD to build system >>>>>>> users. I insist on >>>>>>> the fact system users are forged. Purely. >>>>>>> >>>>>>> What is responsible of that forging process? What you >>>>>>> declared >>>>>>> in >>>>>>> /etc/nsswitch.conf. >>>>>>> Generally it is winbind, sssd or nlscd. >>>>>>> >>>>>>> Each one of these tools comes with its own set of option, >>>>>>> tweak and >>>>>>> configuration files to define how to forge users from local >>>>>>> system point of >>>>>>> view. >>>>>>> >>>>>>> Each one except for Winbind which forge users as it decide >>>>>>> to, >>>>>>> no matter >>>>>>> the desires of local system admin. At least this is how I >>>>>>> understood >>>>>>> winbind behaviour (which has no configuration file for what >>>>>>> I >>>>>>> know). >>>>>>> >>>>>>> >>>>>>> Well, apart from idmap.ldb on a DC and the idmap_config lines in >>>>>>> smb.conf on a domain member, there are no configuration files. >>>>>>> :-D >>>>>>> >>>>>>> >>>>>>> idmap.ldb -> TDB database version 6, little-endian hash size 10000 >>>>>>> bytes >>>>>>> idmap_config lines in smb.conf -> how would you set them to configure >>>>>>> Winbind to not add domain to user? >>>>>>> >>>>>>> Well, I will give you this one, on DC you cannot, but on a domain >>>>>>> member >>>>>>> >>>>>> you can: winbind use default domain = yes >>>>>> However, it is not recommended to use the DC as a fileserver >>>>>> >>>>>> OK for that option I didn't knew which is effectively to remove domain >>>>> part >>>>> of user name. >>>>> Not OK with your remark regarding file server: why changing the way >>>>> system >>>>> users are created means to share files? >>>>> >>>>> I never mentioned how users are created in relation to how to share >>>> files, >>>> you seem to be wanting to use the DC to server files, I was just pointing >>>> out that this is not recommended. >>>> >>> I don't meant using DC as file server. In fact, as advised in the Wiki, I >>> try to discourage users to do that. >>> I'm now building an AD infrastructure for a very large company. This >>> company has needs and restrictions. As they all have when they are big >>> enough. >>> All that I say is without stuff to configure what attribute is used for >>> each field of system user lines, it is possible I can't fill the need of >>> this company. >>> Anyway, once more you tried to make me say something I did not say. >>> >>> >>> >>>> To use gidNumber rather than 100 which seems to reflect "primaryGroupID: >>>>>> 513", >>>>>>> Give the users unique uidNumbers and Domain Users a gidNumber >>>>>>> >>>>>> What gidNumber is given to system user? Is it gidNumber attribute >>>>> content >>>>> or something else? >>>>> What I mean is simple: if I configure gidNumber for all my users, don't >>>>> you >>>>> think I do that for my system users have this gidNumber in use rather >>>>> gid >>>>> set to 100? >>>>> Are you telling me I'm stupid to want users with different GID? Isn't >>>>> it a >>>>> common UNIX practice? Are you telling me all others admins doing that >>>>> are >>>>> also stupid? >>>>> >>>>> Well in the context of AD *YES*, in AD, every users primary group is >>>> 'Domain Users' and there is no concept of a private group. You control >>>> access by using NTFS ACLs, either by setting these from windows or with >>>> 'setfacl'. To change a users primary group, you will need to change the >>>> users PrimaryGidNumber attribute to contain the RID of the new group, it >>>> is >>>> possible but has to be done in a certain way. I would not suggest doing >>>> this, windows expects every user to be a member of 'Domain Users'. >>>> >>>> >>>> Sorry, but that's wrong. You are speaking about Windows users retrieved >>> from AD (you are speaking about NTFS which is not a too-much-UNIXlike FS). >>> AD is a database, yes I insist, which can be used by Windows clients and >>> UNIX-like clients. Windows systems needs are most generally different than >>> UNIX-like systems needs. >>> There is the rfc2307 which is here to define a common way to proceed for >>> UNIX-like systems. This RFC is not The Truth. It is a try to make thing >>> more generic. If some of us wants to use non-rfc2307 field to build system >>> users, this person must be able to do it. >>> >>> >>> >>>>> to set up home directory to unixHomeDirectory or to homeDirectory rather >>>>>> than /home/<short domain name>/ sAMAccountName? >>>>>>> template homedir = /home/%U >>>>>>> >>>>>> False. Here you gave me an option to force one kind of home directory >>>>> for >>>>> all users. This is not what I was asking. Can't you imagine that some >>>>> users >>>>> could need some other home directory? What if some applicative user is >>>>> named "toto" and this user needs to have a home directory set to >>>>> /home/toto_applicative_folder? >>>>> >>>>> No, you never asked that, you just said it couldn't be done and I also >>>> said using the DC as a fileserver is not recommended, on a domain member, >>>> the 'unixHomeDirectory' attribute is available and winbind will use it. >>>> >>> Once more, the choice of used attribute to set an information is forced by >>> Winbind. What if I have to homeDirectory? What if I have some other field? >>> What if I'm forced to set a telephone number in unixHomeDirectory? >>> >>> >>> >>>> Should I modify this user .bashrc or .profile to force an export of HOME >>>> >>>>> variable? Is it a nice way to proceed when using the right tool I can >>>>> set >>>>> this different home directory directly in AD? >>>>> >>>>> No, just use Samba in AD mode as recommended. >>> As recommanded. Only as recommanded. Always follow the path and never go >>> walk in grass. Don't think, some do that for you... >>> That's to avoid that way of mind I left Microsoft world or I refuse to >>> enter the Apple World. >>> >>> >>> >>>> >>>>> Is it possible to use CN or userPrincipalName rather SAMAccountName when >>>>>> building the system user? >>>>>>> No, you have lost me again, what do you mean by 'building the system >>>>>>> >>>>>> user' >>>>>> >>>>>> OK, here we going further. >>>>> AD is a database. When we want to use users from AD into Linux or UNIX >>>>> systems, we retrieve some information from AD (Login, UID, GID, Gecos, >>>>> Home >>>>> directory, Shell) and we use these information to generate lines looking >>>>> like lines from /etc/passwd. This process is the fact of building system >>>>> user. >>>>> >>>>> Ah, you mean extracting the users info from AD like this: >>>> rowland at debnet:~$ getent passwd rowland >>>> rowland:*:10000:10000::/home/rowland:/bin/bash >>>> >>>> This is on a domain member (in fact it is on the netbook, I am typing >>>> this >>>> on) >>>> >>> OK, that's better. You show a line. What about the configuration you are >>> using to get it? >>> >>> >>> >>>> Using the very same AD and changing what attribute is used to fill some >>>> >>>>> field of these user lines will result in different user. >>>>> >>>>> Example: >>>>> uid:x:uidNumber:gidNumber:gecos:homeDirectory:loginShell >>>>> or >>>>> >>>>> >>>>> sAMAccountName:x:uidNumber:gidNumber:displayName:unixHomeDirectory:loginShell >>>>> >>>>> These are two ways to use AD content to generate system users. Different >>>>> users. >>>>> >>>>> I'm not telling one way is better than the other, I'm telling AD can be >>>>> used in several ways. And using winbind is minimizing this number of >>>>> ways >>>>> as it is lacking configuration options. >>>>> >>>>> No, you are confusing the ways that info can be extracted from AD with >>>> what the OS actually needs, winbind can and will supply this info, but >>>> only >>>> fully on a domain member. >>>> >>> Explain please. I don't understand in what I'm confused. >>> >>> I'm showing two ways to build user lines using different attributes from >>> AD. Two possible ways when using a tool which can be configured (even >>> vastool should be able to let sysadmin decide what attribute will be >>> used). >>> You tell I don't understand, I'm confused... when the next part of of your >>> comment has no meaning: how the very some tool with the very same >>> configuration would produce these two different lines for the same user? >>> Would it be a reliable tool? >>> Note I don't say winbind is not reliable. >>> >>> >>> >>>> So it is not configurable. >>>>>>> Yes it is, fully on a domain member, partially on a DC >>>>>>> >>>>>> Show me. Stop telling it is possible without example as it has no >>>>> value. >>>>> I gave two different user lines, show me how with winbind I can obtain >>>>> both. >>>>> >>>>> You are using nlscd and as such to tell it to extract certain info, some >>>> of this info is not really required, but I have added the 'gecos' >>>> attribute >>>> to my AD object and now get this: >>>> >>>> rowland at debnet:~$ getent passwd rowland >>>> rowland:*:10000:10000:Rowland Penny:/home/rowland:/bin/bash >>>> >>>> So, I get the username, the users UID, their primary GID, gecos, Unix >>>> home >>>> directory and what shell the user will use, all obtained from AD, what >>>> else >>>> does the OS need? >>>> >>> Glad to read that: to achieve that you don't use winbind only, so you use >>> another layer to get needed configuration options. >>> >>> >>> >>>> >>>>>> Perhaps you are using winbind, in that case winbind is >>>>>>> responsible to add >>>>>>> domain and backslashes when forging your users. >>>>>>> >>>>>>> I don't know at all nlscd but some are using it on that >>>>>>> mailing list. So I >>>>>>> expect it does its job too. >>>>>>> >>>>>>> I tried SSSD for the company I'm working these days and it >>>>>>> comes with lot >>>>>>> of configuration options. I expect it can force addition of >>>>>>> AD >>>>>>> domain to >>>>>>> username but it is not the default behaviour. >>>>>>> >>>>>>> On some DC where it uses winbind to forge users: >>>>>>> >>>>>>> >>>>>>> No, sorry, I cannot understand what you mean by forge, in >>>>>>> English >>>>>>> this word is used for creating your own banknotes or a thing >>>>>>> used >>>>>>> by a blacksmith. >>>>>>> >>>>>>> >>>>>>> In fact a blacksmith forges items using blacksmith tools. He creates >>>>>>> these items. These items can be something else than his own tools. In >>>>>>> fact >>>>>>> if a blacksmith was only able to craft its own tools and nothing else >>>>>>> for >>>>>>> other peoples, this kind of job would have quickly disappeared... >>>>>>> >>>>>>> So what you meant was 'create a user', please don't try to get >>>>>>> creative >>>>>>> >>>>>> with the English language, just say what you mean. >>>>>> As for forge and a blacksmith, the word can mean the place a blacksmith >>>>>> works, the 'action' of the blacksmith doing something i.e. a blacksmith >>>>>> forges horseshoes (technical note: no, this actually done by a farrier) >>>>>> (further note: blacksmiths have virtually disappeared) >>>>>> Have we played enough with *my* language yet? >>>>>> >>>>>> In fact what I meant was "using some tool to retrieve some information >>>>> from >>>>> AD to create a system user using these information". I just thought >>>>> forging >>>>> was clear enough, my bad. >>>>> >>>>> Very bad, forging has nothing to with retrieving, extracting, pulling, >>>> obtaining (I could go on) info from AD. >>>> >>> Blabla, nothing else. >>> >>> >>> >>>> >>>>> Anyway you get the point, forging, crafting, building, assembling >>>>>>> elements to obtain something else, they are same concept. >>>>>>> >>>>>>> Same basic concept, but they all mean totally different things. >>>>>>> >>>>>> Perhaps, I'm not English native. In my own language, French, all these >>>>> words have a similar background described by "assembling elements to >>>>> obtain >>>>> something else". Which is what winbind and consort are doing. Assembling >>>>> elements from AD. >>>>> >>>>> They do not really mean that in English. >>> I'm still learning : ) >>> >>> >>> >>>> >>>>>> If you add a Uidnumber to user a user in AD, then it should show >>>>>>> on a DC, even if you are not using winbind. >>>>>>> >>>>>>> >>>>>>> Here you should have meant "if you are using winbind" which is true >>>>>>> for >>>>>>> UID and wrong for GID which is not reflecting gidNumber configured >>>>>>> into >>>>>>> AD. >>>>>>> >>>>>>> Ah, that is because you think that giving a user a gidNumber, this >>>>>>> >>>>>> becomes >>>>>> the users main GID, it doesn't. The users primary gid number is >>>>>> obtained >>>>>> from what is set in the aptly named 'PrimaryGidNumber' attribute, AD >>>>>> obtains this and then uses whatever gidNumber that groups object >>>>>> contains. >>>>>> >>>>>> False. In system point of view user primary group is the one declared >>>>> in >>>>> user line (the equivalent of line from /etc/passwd) and this can be >>>>> changed >>>>> using "sg" command for example. >>>>> >>>>> And what attribute is used to generate that line is a choice. Samba team >>>>> has chosen to use 'PrimaryGidNumber' attribute, >>>>> >>>>> Yes, but what else would you use for a users primary group number (the >>>> clue is in the attribute name) >>>> >>> gidNumber? >>> >>> To put that differently: in your mind, what is the purpose of RFC2307 >>> attribute named gidNumber? >>> >>> when from https://www.ietf.org/rfc/rfc2307.txt >>> ( nisSchema.1.1 NAME 'gidNumber' >>> DESC 'An integer uniquely identifying a group in an >>> administrative domain' >>> EQUALITY integerMatch SYNTAX 'INTEGER' *SINGLE-VALUE *) >>> >>> >>> >>> >>> >>>> well, that's their choice >>>> Yes and it was a good choice with relevance to AD and as I said it really >>>> doesn't need to be changed, you just need to use windows permissions >>>> instead of Unix permissions. >>>> >>>> and it is most certainly relevant in certain conditions. Not all. And >>>> >>>>> that's so obvious other tools used to generate system users from AD have >>>>> this configurable. >>>>> >>>>> >>>>> This is because they are trying to force AD to work with Unix, instead >>>> of >>>> Unix working with windows. >>>> >>> Yep. Totally true. And why would I do that? Because it is possible and >>> because UNIX-like are not meant to work as Microsoft systems. >>> >>> I use AD as a user database. Nothing else. What is done with information >>> retrieved from a database is the choice of who retrieve the info. No one >>> else. >>> >>> >>> >>>> Should I speak again about home dir ? Shell ? Gecos ? login attribute >>>>>> ?... >>>>>> >>>>>> No, because I have already dealt with that. >>>>>> >>>>>> I still don't see where you dealt with that : ) >>>>> Well I did :-) >>> And you don't show it. Nice way of mind. >>> >>> >>> >>>> >>>>> SSSD grant sys admin possibility to chose all that, forging users as >>>>>>> sysadmin wants to (which is most generally what his bosses asked to >>>>>>> him). >>>>>>> Winbind can't. >>>>>>> And here the question is "how can the user have username using >>>>>>> <username> >>>>>>> syntax rather than <domainname>\<username>. Is it possible to remove >>>>>>> domain >>>>>>> part from username when using winbind? With the idmap_config lines >>>>>>> perhaps >>>>>>> ? :p >>>>>>> >>>>>>> Anything that sssd can do, winbind can do, but, as I have admitted, >>>>>>> only >>>>>>> >>>>>> fully on a domain member. >>>>>> >>>>>> Wrong. Very wrong. One thing to push us a bit outside of the current >>>>> subject: SSSD can connect on several domains and several LDAP trees >>>>> which >>>>> are not domains at same time. Can winbind do that? Just for fun : ) >>>>> >>>>> You can get winbind to know about different domains, but why would you >>>> bother, do it the windows way, have one domain and use 'sites'. >>>> >>> No, you misunderstood me. You claimed "Anything that sssd can do, winbind >>> can do" which is false, to not say it is a lie. I'm still waiting for an >>> example of Winbind configuration use any LDAP attribute I want for any >>> field of a system user. >>> And you told Winbind can also be configured to access several domains at >>> same time without anything to demonstrate that affirmation. You could have >>> told me your Winbind prepare your coffee in the morning, I won't have >>> trusted you more nor less. >>> >>> >>> >>>> Rowland >>>> >>>> >>>> >>>> I know you were speaking about generating user lines from one and only >>>>> one >>>>> AD domain. Once more: show me how to generate different user lines for >>>>> the >>>>> same user into the same AD, without changing anything into that AD. Then >>>>> I'll start to accept winbind is configurable. Until now, for me it is >>>>> not. >>>>> >>>>> >>>>> >>>>> And more: how system is configured to retrieve users from AD! AD seems >>>>>>> well configured: it works. The question is about how to obtain system >>>>>>> users >>>>>>> according to what this user needs and not according to what winbind >>>>>>> thinks >>>>>>> it is the right way. >>>>>>> >>>>>>> As I said, winbind will do what sssd does, in fact winbind is that >>>>>>> good, >>>>>>> >>>>>> the later versions of sssd implements a lot of the winbind code. >>>>>> >>>>>> I never say winbind is not well coded, useless or anything like that. I >>>>> say >>>>> winbind is not as configurable as SSSD which makes SSSD more suitable >>>>> for >>>>> some needs. >>>>> >>>>> And once again, show me how to generate different user lines with >>>>> winbind >>>>> when using the AD DB, just changing what attribute is used for parts of >>>>> these lines (gecos, username, home dir, all of them). >>>>> >>>>> >>>>> >> OK, lets go back to something you posted earlier: >> >> Example: >> uid:x:uidNumber:gidNumber:gecos:homeDirectory:loginShell >> or >> >> sAMAccountName:x:uidNumber:gidNumber:displayName:unixHomeDirectory:loginShell >> >> Lets take them one by one. >> uid is the users login and so is sAMAccountName >> > Since when they must be the same? > That's a wrong affirmation you posted. These are two different LDAP > attributes with, I agree, same meaning. But in no case they must be > identical. > As they can be different we must think them as different. > > I could have used CN and sAMAccountName in my lines examples. Your answer > could have been the same with these two attributes as they could contain > the same value. > CN length is 64 characters max. SAMAccountName is 20 characters max. For > uid attribute I'm not sure about its max length, more than 20 char. I > expect... > > According to the length, they are almost the same but not exactly. So there > is a real meaning not to use one and prefer the other: one is so short you > can't fill it with anything you want. That's just given as example, to show > they are not the same. > > > the next two are the same attributes >> gecos is usually used for the users full name and so is displayName >> > Same: two fields, two possible information. They can be the same, they must > not be the same. > In my flat I can do whatever I want. At work I can't. At work if some boss > tells me "we will 'telephoneNumber' for user login" and if it is > technically possible, they will log using the content of that attribute. > Because that's their company, not mine, I don't give orders, I only find > solution to their desires and issues. > > >> We now come to a problem, if you are extracting homeDirectory from AD then >> you will get something like this: //computername/username i.e. it is where >> the users windows home directory is stored. The users Unix home directory >> is in unixHomeDirectory >> > https://msdn.microsoft.com/en-us/library/ms676190%28v=vs.85%29.aspx says > this LDAP attribute is a string encoded in unicode. It also speecify that > this field must contains UNC path or a fully qualified local path including > the drive letter. This has meaning only if you intend to use that attribute > for Windows systems. > This is a string so we can set any string into that field. Including a NFS > path if we want to. > I agree this is not meant to, but who cares? It's possible, humans are > numerous ans someone will do that one day or another. > And once you would have to manage such an AD, what would you prefer: > changing each users or changing one configuration file (which can be used > by lots of servers, I agree)? In my little experience, as modifying all > users in AD is quiet critical, nobody would give a "go" to such a change. > Changing servers configuration file is a server-by-server task, finding a > boss to give a "go" to such a task is easy. > > >> the last one is the same attribute >> >> As I have shown, winbind will extract the required info, without having to >> manually setup a config file to select which attribute to map. There is no >> reason to use sssd or nlscd with Samba unless you need to use the DC as a >> fileserver and this is not recommended. > > Winbind retrieves some information which can be the right ones. > For any reason, good or bad, if these retrieved information are not the > right ones, how to deal with that using winbind? > > >No, winbind retrieves the correct attributes, it sounds like the contents of your attributes are incorrect, there is an old saying (well old when it comes to computers), 'garbage in, garbage out' The correct cure would be to repair your attributes contents, not work around them using nlscd or similar. I honestly don't think this discussion is going anywhere and is well away from the OP, so I suggest we stop now. Rowland