Hi Greg,
To answer your question directly, the daemon runs on a Linux server (actually a VM) which has limited login access. Root on this VM has access to a domain account credentials with sufficient privilege to create and reset machine accounts.
It certainly isnt perfect, but at least the privileged account credentials are quarantined to one place.
The down side is that the daemon is a locally written script, invoked from xinetd. It logs all operations into syslog for traceability. The level of authentication of the client is weak, merely having an IP number which matches (in DNS) the host name is sufficient. With the fig leaf of an obfuscated, specially formatted, request packet.
PowerShell on Linux wasnt an option when I wrote this system (several years ago). I wonder if that would be better? How would it handle the privileged account credentials?
HTH, Jeremy
p.s. nor was realmd an option then, I originally wrote this system for RHEL/CentOS 5. It also uses a 3rd party utility called msktutil, which I hope will no longer be required in RHEL/CentOS 7.

On 25 Jul 2018, at 12:39 am, greg whynott <greg.whynott@gmail.com> wrote:
I agree having a password in a script isn't the best idea, no dispute there.

Until I can work out a better method of having new machines join during the kick start install unattended, we are ok with the risk. To mitigate the potential of it being exposed to people outside of the group, it sits on a machine without user access and the file is removed as soon as the join happens. Also the account was set up with the minimal required permissions to bind. If someone wanted to query our AD/LDAP I don't think this would be the first stop. Basically they would have to compromise the machine as it was being set up, I think?

Jeremy's method looks interesting but I can't help but think its just moving the problem around. I'd not think I was safer using hostname/ip checks myself but every layer helps. Does that process run on linux Jeremy?

I did not look at powershell for linux, but wouldn't it also want credentials?

-greg


On Tue, Jul 24, 2018 at 3:06 AM, julian firminger <justdigitalfilm@gmail.com> wrote:

He Greg,
I agree with Jeremy, this approach leaves a limited domain admin credential out there in plain text. Have you considered installing PowerShell Core for linux and using PSCredentials? I've never tried this but i imagine you can set execution as signed, encapsulate a PSCrediental and use PS Add-Computer to join the domain.
(I cant wait for the abuse I'm going to get for "poluting a perfectly good OS with M$ infection" remarks. Hi there DY)
https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-linux?view=powershell-6
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/add-computer?view=powershell-5.1

Julian Firminger

Senior Systems Administrator United Broadcast Facilities Amsterdam, The Netherlands

On Tue, Jul 24, 2018 at 2:58 AM, Jeremy Webber <Jeremy.Webber@al.com.au> wrote:

The big disadvantage of all of these approaches is that you must embed the password of an account which is powerful enough to create AD machine accounts into the build process. So be careful the password is not left anywhere on the built machine at the end of the process (and before the end user gets control)!
An approach that we use is that we run a central daemon which can create or renew machine accounts on behalf of a requestor. The daemon verifies that the request has a hostname which matches the source IP of the requestor. The message over the network is obfuscated. This approach is also not perfect, but I am certain that the required AD credentials are limited to the server which runs the daemon, and the password never goes over the network.
In the Windows world, a privileged password is embedded into the sysprep process, which also has similar disadvantages. Id love to hear of more secure and effective ways to manage machine accounts!
Jeremy

p.s. Joining a domain in reality means creating a machine account with a password, stored on the client, for that machine. Machine accounts in AD have limited privilege but they are sufficient to allow the machine to bind (SASL) and perform LDAP queries.

On 24 Jul 2018, at 7:36 am, greg whynott <greg.whynott@gmail.com> wrote:
No I haven't Elavia. What I posted seems to work and is about the same as your example., Not seeing much of an advantage of one over the other but thanks for mentioning it, may help someone else out.
greg



On Mon, Jul 23, 2018 at 5:31 PM, H Elavia <hanozelavia@gmail.com> wrote:

Have you tried the following:
yes <join_pwd> | realm join --user=<join_user> <domain_name>


On Mon, Jul 23, 2018, 13:21 greg whynott, <greg.whynott@gmail.com> wrote:

The reason I'm using SSSD over NSLCD due to its caching behavior more than anything else.. Caching on NSLCD is limited and basically useless in our environment.

Every file you touch, menu you click on, and so on, NSLCD will make a call to the configured authentication source. In our situation that was about 60,000 calls a day, the AD server was busy. Logging into a machine would take up to or longer than a minute before it "let go" and you were able to operate the menus and what not. Switched to SSSD and login's happen in seconds now. A huge difference. doing a packet capture we see only one ldap call instead of a hundred or so during log in.

As an example, doing a packet capture during a GDM GUI log in session would produce much more traffic using NSLCD than SSSD:

nslcd: 3.9 megabytes in LDAP queries. (this is due to a bad base which is due to be changed)
sssd: 188K

Everything feels more snappy with SSSD. . Its what systemd is to initd in a way. Does the same thing but more intelligently.


-g



On Mon, Jul 23, 2018 at 3:31 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:

sssd does seem to be the preferred approach for RHEL these days, this
RedHat blog post (and others in the series) seems to have a fairly
decent breakdown of approaches.

https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/

JF


On Mon, Jul 23, 2018 at 11:29 AM, greg whynott <greg.whynott@gmail.com> wrote:
> Good question. The best I could come up with is that net is part of the
> samba tools and realm is not. lol You can join a kerberos domain which
> isn't M$ AD based, so perhaps that's part of it. AD uses the kerberos
> protocol.
>
> KRB was around before AD, M$ chose to implement it. So I'm assuming net
> has some krb5 libs included as would realm.
>
> -g
>
>
>
>
> On Mon, Jul 23, 2018 at 2:02 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>
>> This begs the question (which I should know the answers to) but what are
>> the differences in the various ways to join a domain?
>>
>> Sent from my iPhone with a soon to be cracked or broken screen.
>>
>> On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:
>>
>> Thanks Rory, we are not using net to join machines but good to know.
>>
>> -g
>>
>>
>>
>> On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>>
>>>
>>> net ads join -Uusername%password also works.
>>>
>>> ________________________________
>>> From: studiosysadmins-discuss-bounces@studiosysadmins.com
>>> <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg
>>> whynott <greg.whynott@gmail.com>
>>> Sent: Monday, July 23, 2018 12:58 PM
>>> To: studiosysadmins-discuss
>>> Subject: [SSA-Discuss] join linux machines to domain without password
>>> prompt.
>>>
>>> If you don't join linux machines to AD bail now,
>>>
>>>
>>>
>>> Should it be helpful...
>>>
>>>
>>> During my move from NSLCD to SSSD one of the challenges was adding
>>> machines to the domain silently without interaction required.
>>>
>>> Both the realm and net command require you to enter your password and
>>> neither (from what I can tell) have a flag to pass the password along on the
>>> command line.
>>>
>>> There are many articles on how to do this as a one off, typically
>>> requiring you to pre-add the machine to the domain, one time pass or
>>> similar. These methods don't scale well beyond 1 machine.
>>>
>>> My intention was to deploy hundreds of machines using kickstart and have
>>> them all 100% done when the installer finished up, unattended.
>>>
>>> After a lot of searching for methods and without much luck, unix itself
>>> provided the method. Should of been obvious but I guess my head was in
>>> windows mode at the time.
>>>
>>> if you type:
>>>
>>> realm join ad01.mydomain.com -U accountname
>>>
>>> It'll ask you for a password. To get around this, instead type:
>>>
>>> echo mypassword | realm join ad01.mydomain.com -U accountname
>>>
>>>
>>> power of the pipe!
>>>
>>>
>>> kinit works the same:
>>>
>>> echo mypassword | kinit -U accountname
>>>
>>>
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>> To unsubscribe from the list send a blank e-mail to
>>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>
>
>
> To unsubscribe from the list send a blank e-mail to
> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

--
Jeremy Webber
Senior Systems Engineer

T: +61 2 9383 4800 (main)
D: +61 2 8310 3577 (direct)
E: Jeremy.Webber@al.com.au

Building 54 / FSA #19, Fox Studios Australia, 38 Driver Avenue
Moore Park, NSW 2021
AUSTRALIA




Check out our awesome NEW website www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

I agree having a password in a script isn't the best idea, no dispute there.

Until I can work out a better method of having new machines join during the kick start install unattended, we are ok with the risk. To mitigate the potential of it being exposed to people outside of the group, it sits on a machine without user access and the file is removed as soon as the join happens. Also the account was set up with the minimal required permissions to bind. If someone wanted to query our AD/LDAP I don't think this would be the first stop. Basically they would have to compromise the machine as it was being set up, I think?

Jeremy's method looks interesting but I can't help but think its just moving the problem around. I'd not think I was safer using hostname/ip checks myself but every layer helps. Does that process run on linux Jeremy?

I did not look at powershell for linux, but wouldn't it also want credentials?

-greg


On Tue, Jul 24, 2018 at 3:06 AM, julian firminger <justdigitalfilm@gmail.com> wrote:

He Greg,
I agree with Jeremy, this approach leaves a limited domain admin credential out there in plain text. Have you considered installing PowerShell Core for linux and using PSCredentials? I've never tried this but i imagine you can set execution as signed, encapsulate a PSCrediental and use PS Add-Computer to join the domain.
(I cant wait for the abuse I'm going to get for "poluting a perfectly good OS with M$ infection" remarks. Hi there DY)
https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-linux?view=powershell-6
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/add-computer?view=powershell-5.1

Julian Firminger

Senior Systems AdministratorUnited Broadcast FacilitiesAmsterdam, The Netherlands

On Tue, Jul 24, 2018 at 2:58 AM, Jeremy Webber <Jeremy.Webber@al.com.au> wrote:

The big disadvantage of all of these approaches is that you must embed the password of an account which is powerful enough to create AD machine accounts into the build process. So be careful the password is not left anywhere on the built machine at the end of the process (and before the end user gets control)!
An approach that we use is that we run a central daemon which can create or renew machine accounts on behalf of a requestor. The daemon verifies that the request has a hostname which matches the source IP of the requestor. The message over the network is obfuscated. This approach is also not perfect, but I am certain that the required AD credentials are limited to the server which runs the daemon, and the password never goes over the network.
In the Windows world, a privileged password is embedded into the sysprep process, which also has similar disadvantages. Id love to hear of more secure and effective ways to manage machine accounts!
Jeremy

p.s. Joining a domain in reality means creating a machine account with a password, stored on the client, for that machine. Machine accounts in AD have limited privilege but they are sufficient to allow the machine to bind (SASL) and perform LDAP queries.

On 24 Jul 2018, at 7:36 am, greg whynott <greg.whynott@gmail.com> wrote:
No I haven't Elavia. What I posted seems to work and is about the same as your example., Not seeing much of an advantage of one over the other but thanks for mentioning it, may help someone else out.
greg



On Mon, Jul 23, 2018 at 5:31 PM, H Elavia <hanozelavia@gmail.com> wrote:

Have you tried the following:
yes <join_pwd> | realm join --user=<join_user> <domain_name>


On Mon, Jul 23, 2018, 13:21 greg whynott, <greg.whynott@gmail.com> wrote:

The reason I'm using SSSD over NSLCD due to its caching behavior more than anything else.. Caching on NSLCD is limited and basically useless in our environment.

Every file you touch, menu you click on, and so on, NSLCD will make a call to the configured authentication source. In our situation that was about 60,000 calls a day, the AD server was busy. Logging into a machine would take up to or longer than a minute before it "let go" and you were able to operate the menus and what not. Switched to SSSD and login's happen in seconds now. A huge difference. doing a packet capture we see only one ldap call instead of a hundred or so during log in.

As an example, doing a packet capture during a GDM GUI log in session would produce much more traffic using NSLCD than SSSD:

nslcd: 3.9 megabytes in LDAP queries. (this is due to a bad base which is due to be changed)
sssd: 188K

Everything feels more snappy with SSSD. . Its what systemd is to initd in a way. Does the same thing but more intelligently.


-g



On Mon, Jul 23, 2018 at 3:31 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:

sssd does seem to be the preferred approach for RHEL these days, this
RedHat blog post (and others in the series) seems to have a fairly
decent breakdown of approaches.

https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/

JF


On Mon, Jul 23, 2018 at 11:29 AM, greg whynott <greg.whynott@gmail.com> wrote:
> Good question. The best I could come up with is that net is part of the
> samba tools and realm is not. lol You can join a kerberos domain which
> isn't M$ AD based, so perhaps that's part of it. AD uses the kerberos
> protocol.
>
> KRB was around before AD, M$ chose to implement it. So I'm assuming net
> has some krb5 libs included as would realm.
>
> -g
>
>
>
>
> On Mon, Jul 23, 2018 at 2:02 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>
>> This begs the question (which I should know the answers to) but what are
>> the differences in the various ways to join a domain?
>>
>> Sent from my iPhone with a soon to be cracked or broken screen.
>>
>> On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:
>>
>> Thanks Rory, we are not using net to join machines but good to know.
>>
>> -g
>>
>>
>>
>> On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>>
>>>
>>> net ads join -Uusername%password also works.
>>>
>>> ________________________________
>>> From: studiosysadmins-discuss-bounces@studiosysadmins.com
>>> <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg
>>> whynott <greg.whynott@gmail.com>
>>> Sent: Monday, July 23, 2018 12:58 PM
>>> To: studiosysadmins-discuss
>>> Subject: [SSA-Discuss] join linux machines to domain without password
>>> prompt.
>>>
>>> If you don't join linux machines to AD bail now,
>>>
>>>
>>>
>>> Should it be helpful...
>>>
>>>
>>> During my move from NSLCD to SSSD one of the challenges was adding
>>> machines to the domain silently without interaction required.
>>>
>>> Both the realm and net command require you to enter your password and
>>> neither (from what I can tell) have a flag to pass the password along on the
>>> command line.
>>>
>>> There are many articles on how to do this as a one off, typically
>>> requiring you to pre-add the machine to the domain, one time pass or
>>> similar. These methods don't scale well beyond 1 machine.
>>>
>>> My intention was to deploy hundreds of machines using kickstart and have
>>> them all 100% done when the installer finished up, unattended.
>>>
>>> After a lot of searching for methods and without much luck, unix itself
>>> provided the method. Should of been obvious but I guess my head was in
>>> windows mode at the time.
>>>
>>> if you type:
>>>
>>> realm join ad01.mydomain.com -U accountname
>>>
>>> It'll ask you for a password. To get around this, instead type:
>>>
>>> echo mypassword | realm join ad01.mydomain.com -U accountname
>>>
>>>
>>> power of the pipe!
>>>
>>>
>>> kinit works the same:
>>>
>>> echo mypassword | kinit -U accountname
>>>
>>>
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>> To unsubscribe from the list send a blank e-mail to
>>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>
>
>
> To unsubscribe from the list send a blank e-mail to
> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

--
Jeremy Webber
Senior Systems Engineer

T: +61 2 9383 4800 (main)
D: +61 2 8310 3577 (direct)
E: Jeremy.Webber@al.com.au

Building 54 / FSA #19, Fox Studios Australia, 38 Driver Avenue
Moore Park, NSW 2021
AUSTRALIA




Check out our awesome NEW website www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

He Greg,
I agree with Jeremy, this approach leaves a limited domain admin credential out there in plain text. Have you considered installing PowerShell Core for linux and using PSCredentials? I've never tried this but i imagine you can set execution as signed, encapsulate a PSCrediental and use PS Add-Computer to join the domain.
(I cant wait for the abuse I'm going to get for "poluting a perfectly good OS with M$ infection" remarks. Hi there DY)
https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-linux?view=powershell-6
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/add-computer?view=powershell-5.1

Julian Firminger

Senior Systems AdministratorUnited Broadcast FacilitiesAmsterdam, The Netherlands

On Tue, Jul 24, 2018 at 2:58 AM, Jeremy Webber <Jeremy.Webber@al.com.au> wrote:

The big disadvantage of all of these approaches is that you must embed the password of an account which is powerful enough to create AD machine accounts into the build process. So be careful the password is not left anywhere on the built machine at the end of the process (and before the end user gets control)!
An approach that we use is that we run a central daemon which can create or renew machine accounts on behalf of a requestor. The daemon verifies that the request has a hostname which matches the source IP of the requestor. The message over the network is obfuscated. This approach is also not perfect, but I am certain that the required AD credentials are limited to the server which runs the daemon, and the password never goes over the network.
In the Windows world, a privileged password is embedded into the sysprep process, which also has similar disadvantages. Id love to hear of more secure and effective ways to manage machine accounts!
Jeremy

p.s. Joining a domain in reality means creating a machine account with a password, stored on the client, for that machine. Machine accounts in AD have limited privilege but they are sufficient to allow the machine to bind (SASL) and perform LDAP queries.

On 24 Jul 2018, at 7:36 am, greg whynott <greg.whynott@gmail.com> wrote:
No I haven't Elavia. What I posted seems to work and is about the same as your example., Not seeing much of an advantage of one over the other but thanks for mentioning it, may help someone else out.
greg



On Mon, Jul 23, 2018 at 5:31 PM, H Elavia <hanozelavia@gmail.com> wrote:

Have you tried the following:
yes <join_pwd> | realm join --user=<join_user> <domain_name>


On Mon, Jul 23, 2018, 13:21 greg whynott, <greg.whynott@gmail.com> wrote:

The reason I'm using SSSD over NSLCD due to its caching behavior more than anything else.. Caching on NSLCD is limited and basically useless in our environment.

Every file you touch, menu you click on, and so on, NSLCD will make a call to the configured authentication source. In our situation that was about 60,000 calls a day, the AD server was busy. Logging into a machine would take up to or longer than a minute before it "let go" and you were able to operate the menus and what not. Switched to SSSD and login's happen in seconds now. A huge difference. doing a packet capture we see only one ldap call instead of a hundred or so during log in.

As an example, doing a packet capture during a GDM GUI log in session would produce much more traffic using NSLCD than SSSD:

nslcd: 3.9 megabytes in LDAP queries. (this is due to a bad base which is due to be changed)
sssd: 188K

Everything feels more snappy with SSSD. . Its what systemd is to initd in a way. Does the same thing but more intelligently.


-g



On Mon, Jul 23, 2018 at 3:31 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:

sssd does seem to be the preferred approach for RHEL these days, this
RedHat blog post (and others in the series) seems to have a fairly
decent breakdown of approaches.

https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/

JF


On Mon, Jul 23, 2018 at 11:29 AM, greg whynott <greg.whynott@gmail.com> wrote:
> Good question. The best I could come up with is that net is part of the
> samba tools and realm is not. lol You can join a kerberos domain which
> isn't M$ AD based, so perhaps that's part of it. AD uses the kerberos
> protocol.
>
> KRB was around before AD, M$ chose to implement it. So I'm assuming net
> has some krb5 libs included as would realm.
>
> -g
>
>
>
>
> On Mon, Jul 23, 2018 at 2:02 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>
>> This begs the question (which I should know the answers to) but what are
>> the differences in the various ways to join a domain?
>>
>> Sent from my iPhone with a soon to be cracked or broken screen.
>>
>> On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:
>>
>> Thanks Rory, we are not using net to join machines but good to know.
>>
>> -g
>>
>>
>>
>> On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>>
>>>
>>> net ads join -Uusername%password also works.
>>>
>>> ________________________________
>>> From: studiosysadmins-discuss-bounces@studiosysadmins.com
>>> <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg
>>> whynott <greg.whynott@gmail.com>
>>> Sent: Monday, July 23, 2018 12:58 PM
>>> To: studiosysadmins-discuss
>>> Subject: [SSA-Discuss] join linux machines to domain without password
>>> prompt.
>>>
>>> If you don't join linux machines to AD bail now,
>>>
>>>
>>>
>>> Should it be helpful...
>>>
>>>
>>> During my move from NSLCD to SSSD one of the challenges was adding
>>> machines to the domain silently without interaction required.
>>>
>>> Both the realm and net command require you to enter your password and
>>> neither (from what I can tell) have a flag to pass the password along on the
>>> command line.
>>>
>>> There are many articles on how to do this as a one off, typically
>>> requiring you to pre-add the machine to the domain, one time pass or
>>> similar. These methods don't scale well beyond 1 machine.
>>>
>>> My intention was to deploy hundreds of machines using kickstart and have
>>> them all 100% done when the installer finished up, unattended.
>>>
>>> After a lot of searching for methods and without much luck, unix itself
>>> provided the method. Should of been obvious but I guess my head was in
>>> windows mode at the time.
>>>
>>> if you type:
>>>
>>> realm join ad01.mydomain.com -U accountname
>>>
>>> It'll ask you for a password. To get around this, instead type:
>>>
>>> echo mypassword | realm join ad01.mydomain.com -U accountname
>>>
>>>
>>> power of the pipe!
>>>
>>>
>>> kinit works the same:
>>>
>>> echo mypassword | kinit -U accountname
>>>
>>>
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>> To unsubscribe from the list send a blank e-mail to
>>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>
>
>
> To unsubscribe from the list send a blank e-mail to
> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

--
Jeremy Webber
Senior Systems Engineer

T: +61 2 9383 4800 (main)
D: +61 2 8310 3577 (direct)
E: Jeremy.Webber@al.com.au

Building 54 / FSA #19, Fox Studios Australia, 38 Driver Avenue
Moore Park, NSW 2021
AUSTRALIA




Check out our awesome NEW website www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

He Greg,
I agree with Jeremy, this approach leaves a limited domain admin credential out there in plain text.  Have you considered installing PowerShell Core for linux and using PSCredentials?  I've never tried this but i imagine you can set execution as signed, encapsulate a PSCrediental and use PS Add-Computer to join the domain.    
(I cant wait for the abuse I'm going to get for "poluting a perfectly good OS with M$ infection" remarks.  Hi there DY)
https://docs.microsoft.com/en-us/powershell/scripting/setup/installing-powershell-core-on-linux?view=powershell-6
https://docs.microsoft.com/en-us/powershell/module/microsoft.powershell.management/add-computer?view=powershell-5.1

Julian Firminger

Senior Systems AdministratorUnited Broadcast FacilitiesAmsterdam, The Netherlands

On Tue, Jul 24, 2018 at 2:58 AM, Jeremy Webber <Jeremy.Webber@al.com.au> wrote:

The big disadvantage of all of these approaches is that you must embed the password of an account which is powerful enough to create AD machine accounts into the build process. So be careful the password is not left anywhere on the built machine at the end of the process (and before the end user gets control)!
An approach that we use is that we run a central daemon which can create or renew machine accounts on behalf of a requestor. The daemon verifies that the request has a hostname which matches the source IP of the requestor. The message over the network is obfuscated. This approach is also not perfect, but I am certain that the required AD credentials are limited to the server which runs the daemon, and the password never goes over the network.
In the Windows world, a privileged password is embedded into the sysprep process, which also has similar disadvantages. Id love to hear of more secure and effective ways to manage machine accounts!
  Jeremy

p.s. Joining a domain in reality means creating a machine account with a password, stored on the client, for that machine. Machine accounts in AD have limited privilege but they are sufficient to allow the machine to bind (SASL) and perform LDAP queries.

On 24 Jul 2018, at 7:36 am, greg whynott <greg.whynott@gmail.com> wrote:
No I haven't Elavia.  What I posted seems to work and is about the same as your example., Not seeing much of an advantage of one over the other but thanks for mentioning it,  may help someone else out.
greg



On Mon, Jul 23, 2018 at 5:31 PM, H Elavia <hanozelavia@gmail.com> wrote:

Have you tried the following:
yes <join_pwd> | realm join --user=<join_user> <domain_name>


On Mon, Jul 23, 2018, 13:21 greg whynott, <greg.whynott@gmail.com> wrote:

The reason I'm using SSSD over NSLCD due to its caching behavior more than anything else..   Caching on NSLCD is limited and basically useless in our environment.

Every file you touch,  menu you click on,  and so on,  NSLCD will make a call to the configured authentication source.  In our situation that was about 60,000 calls a day,  the AD server was busy.       Logging into a machine would take up to or longer than a minute before it "let go" and you were able to operate the menus and what not.    Switched to SSSD and login's happen in seconds now.   A huge difference.   doing a packet capture we see only one ldap call instead of a hundred or so during log in.  

As an example,  doing a packet capture during a  GDM GUI log in session would produce much more traffic using NSLCD than SSSD: 

nslcd: 3.9 megabytes in LDAP queries.  (this is due to a bad base which is due to be changed)
sssd: 188K

Everything feels more snappy with SSSD. .  Its what systemd is to initd in a way.  Does the same thing but more intelligently.


-g



On Mon, Jul 23, 2018 at 3:31 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:

sssd does seem to be the preferred approach for RHEL these days, this
RedHat blog post (and others in the series) seems to have a fairly
decent breakdown of approaches.

https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/

JF


On Mon, Jul 23, 2018 at 11:29 AM, greg whynott <greg.whynott@gmail.com> wrote:
> Good question.   The best I could come up with is that net is part of the
> samba tools and realm is not.  lol     You can join a kerberos domain which
> isn't M$ AD based,  so perhaps that's part of it.   AD uses the kerberos
> protocol.
>
> KRB was around before AD,  M$ chose to implement it.   So I'm assuming net
> has some krb5 libs included as would realm.
>
> -g
>
>
>
>
> On Mon, Jul 23, 2018 at 2:02 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>
>> This begs the question (which I should know the answers to) but what are
>> the differences in the various ways to join a domain?
>>
>> Sent from my iPhone with a soon to be cracked or broken screen.
>>
>> On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:
>>
>> Thanks Rory,  we are not using net to join machines but good to know.
>>
>> -g
>>
>>
>>
>> On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>>
>>>
>>> net ads join -Uusername%password also works.
>>>
>>> ________________________________
>>> From: studiosysadmins-discuss-bounces@studiosysadmins.com
>>> <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg
>>> whynott <greg.whynott@gmail.com>
>>> Sent: Monday, July 23, 2018 12:58 PM
>>> To: studiosysadmins-discuss
>>> Subject: [SSA-Discuss] join linux machines to domain without password
>>> prompt.
>>>
>>> If you don't join linux machines to AD bail now,
>>>
>>>
>>>
>>> Should it be helpful...
>>>
>>>
>>> During my move from NSLCD to SSSD one of the challenges was adding
>>> machines to the domain silently without interaction required.
>>>
>>> Both the realm and net command require you to enter your password and
>>> neither (from what I can tell) have a flag to pass the password along on the
>>> command line.
>>>
>>> There are many articles on how to do this as a one off,  typically
>>> requiring you to pre-add the machine to the domain, one time pass or
>>> similar.  These methods don't scale well beyond 1 machine.
>>>
>>> My intention was to deploy hundreds of machines using kickstart and have
>>> them all 100% done when the installer finished up,  unattended.
>>>
>>> After a lot of searching for methods and without much luck,  unix itself
>>> provided the method.  Should of been obvious but I guess my head was in
>>> windows mode at the time.
>>>
>>> if you type:
>>>
>>> realm join ad01.mydomain.com -U accountname
>>>
>>> It'll ask you for a password.  To get around this,  instead type:
>>>
>>> echo mypassword | realm join ad01.mydomain.com -U accountname
>>>
>>>
>>> power of the pipe!
>>>
>>>
>>> kinit works the same:
>>>
>>> echo mypassword | kinit -U accountname
>>>
>>>
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>> To unsubscribe from the list send a blank e-mail to
>>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>
>
>
> To unsubscribe from the list send a blank e-mail to
> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

--
Jeremy Webber
Senior Systems Engineer

T: +61 2 9383 4800 (main)
D: +61 2 8310 3577 (direct)
E: Jeremy.Webber@al.com.au

Building 54 / FSA #19, Fox Studios Australia, 38 Driver Avenue
Moore Park, NSW 2021
AUSTRALIA

       


Check out our awesome NEW website www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

Julian Firminger

The big disadvantage of all of these approaches is that you must embed the password of an account which is powerful enough to create AD machine accounts into the build process. So be careful the password is not left anywhere on the built machine at the end of the process (and before the end user gets control)!
An approach that we use is that we run a central daemon which can create or renew machine accounts on behalf of a requestor. The daemon verifies that the request has a hostname which matches the source IP of the requestor. The message over the network is obfuscated. This approach is also not perfect, but I am certain that the required AD credentials are limited to the server which runs the daemon, and the password never goes over the network.
In the Windows world, a privileged password is embedded into the sysprep process, which also has similar disadvantages. Id love to hear of more secure and effective ways to manage machine accounts!
Jeremy

p.s. Joining a domain in reality means creating a machine account with a password, stored on the client, for that machine. Machine accounts in AD have limited privilege but they are sufficient to allow the machine to bind (SASL) and perform LDAP queries.

On 24 Jul 2018, at 7:36 am, greg whynott <greg.whynott@gmail.com> wrote:
No I haven't Elavia. What I posted seems to work and is about the same as your example., Not seeing much of an advantage of one over the other but thanks for mentioning it, may help someone else out.
greg



On Mon, Jul 23, 2018 at 5:31 PM, H Elavia <hanozelavia@gmail.com> wrote:

Have you tried the following:
yes <join_pwd> | realm join --user=<join_user> <domain_name>


On Mon, Jul 23, 2018, 13:21 greg whynott, <greg.whynott@gmail.com> wrote:

The reason I'm using SSSD over NSLCD due to its caching behavior more than anything else.. Caching on NSLCD is limited and basically useless in our environment.

Every file you touch, menu you click on, and so on, NSLCD will make a call to the configured authentication source. In our situation that was about 60,000 calls a day, the AD server was busy. Logging into a machine would take up to or longer than a minute before it "let go" and you were able to operate the menus and what not. Switched to SSSD and login's happen in seconds now. A huge difference. doing a packet capture we see only one ldap call instead of a hundred or so during log in.

As an example, doing a packet capture during a GDM GUI log in session would produce much more traffic using NSLCD than SSSD:

nslcd: 3.9 megabytes in LDAP queries. (this is due to a bad base which is due to be changed)
sssd: 188K

Everything feels more snappy with SSSD. . Its what systemd is to initd in a way. Does the same thing but more intelligently.


-g



On Mon, Jul 23, 2018 at 3:31 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:

sssd does seem to be the preferred approach for RHEL these days, this
RedHat blog post (and others in the series) seems to have a fairly
decent breakdown of approaches.

https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/

JF


On Mon, Jul 23, 2018 at 11:29 AM, greg whynott <greg.whynott@gmail.com> wrote:
> Good question. The best I could come up with is that net is part of the
> samba tools and realm is not. lol You can join a kerberos domain which
> isn't M$ AD based, so perhaps that's part of it. AD uses the kerberos
> protocol.
>
> KRB was around before AD, M$ chose to implement it. So I'm assuming net
> has some krb5 libs included as would realm.
>
> -g
>
>
>
>
> On Mon, Jul 23, 2018 at 2:02 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>
>> This begs the question (which I should know the answers to) but what are
>> the differences in the various ways to join a domain?
>>
>> Sent from my iPhone with a soon to be cracked or broken screen.
>>
>> On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:
>>
>> Thanks Rory, we are not using net to join machines but good to know.
>>
>> -g
>>
>>
>>
>> On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>>
>>>
>>> net ads join -Uusername%password also works.
>>>
>>> ________________________________
>>> From: studiosysadmins-discuss-bounces@studiosysadmins.com
>>> <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg
>>> whynott <greg.whynott@gmail.com>
>>> Sent: Monday, July 23, 2018 12:58 PM
>>> To: studiosysadmins-discuss
>>> Subject: [SSA-Discuss] join linux machines to domain without password
>>> prompt.
>>>
>>> If you don't join linux machines to AD bail now,
>>>
>>>
>>>
>>> Should it be helpful...
>>>
>>>
>>> During my move from NSLCD to SSSD one of the challenges was adding
>>> machines to the domain silently without interaction required.
>>>
>>> Both the realm and net command require you to enter your password and
>>> neither (from what I can tell) have a flag to pass the password along on the
>>> command line.
>>>
>>> There are many articles on how to do this as a one off, typically
>>> requiring you to pre-add the machine to the domain, one time pass or
>>> similar. These methods don't scale well beyond 1 machine.
>>>
>>> My intention was to deploy hundreds of machines using kickstart and have
>>> them all 100% done when the installer finished up, unattended.
>>>
>>> After a lot of searching for methods and without much luck, unix itself
>>> provided the method. Should of been obvious but I guess my head was in
>>> windows mode at the time.
>>>
>>> if you type:
>>>
>>> realm join ad01.mydomain.com -U accountname
>>>
>>> It'll ask you for a password. To get around this, instead type:
>>>
>>> echo mypassword | realm join ad01.mydomain.com -U accountname
>>>
>>>
>>> power of the pipe!
>>>
>>>
>>> kinit works the same:
>>>
>>> echo mypassword | kinit -U accountname
>>>
>>>
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>> To unsubscribe from the list send a blank e-mail to
>>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>
>
>
> To unsubscribe from the list send a blank e-mail to
> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

--
Jeremy Webber
Senior Systems Engineer

T: +61 2 9383 4800 (main)
D: +61 2 8310 3577 (direct)
E: Jeremy.Webber@al.com.au

Building 54 / FSA #19, Fox Studios Australia, 38 Driver Avenue
Moore Park, NSW 2021
AUSTRALIA




Check out our awesome NEW website www.animallogic.com

CONFIDENTIALITY AND PRIVILEGE NOTICE
This email is intended only to be read or used by the addressee. It is confidential and may contain privileged information. If you are not the intended recipient, any use, distribution, disclosure or copying of this email is strictly prohibited. Confidentiality and legal privilege attached to this communication are not waived or lost by reason of the mistaken delivery to you. If you have received this email in error, please delete it and notify us immediately by telephone or email.
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

Have you tried the following:
yes <join_pwd> | realm join --user=<join_user> <domain_name>


On Mon, Jul 23, 2018, 13:21 greg whynott, <greg.whynott@gmail.com> wrote:

The reason I'm using SSSD over NSLCD due to its caching behavior more than anything else.. Caching on NSLCD is limited and basically useless in our environment.

Every file you touch, menu you click on, and so on, NSLCD will make a call to the configured authentication source. In our situation that was about 60,000 calls a day, the AD server was busy. Logging into a machine would take up to or longer than a minute before it "let go" and you were able to operate the menus and what not. Switched to SSSD and login's happen in seconds now. A huge difference. doing a packet capture we see only one ldap call instead of a hundred or so during log in.

As an example, doing a packet capture during a GDM GUI log in session would produce much more traffic using NSLCD than SSSD:

nslcd: 3.9 megabytes in LDAP queries. (this is due to a bad base which is due to be changed)
sssd: 188K

Everything feels more snappy with SSSD. . Its what systemd is to initd in a way. Does the same thing but more intelligently.


-g



On Mon, Jul 23, 2018 at 3:31 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:

sssd does seem to be the preferred approach for RHEL these days, this
RedHat blog post (and others in the series) seems to have a fairly
decent breakdown of approaches.

https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/

JF


On Mon, Jul 23, 2018 at 11:29 AM, greg whynott <greg.whynott@gmail.com> wrote:
> Good question. The best I could come up with is that net is part of the
> samba tools and realm is not. lol You can join a kerberos domain which
> isn't M$ AD based, so perhaps that's part of it. AD uses the kerberos
> protocol.
>
> KRB was around before AD, M$ chose to implement it. So I'm assuming net
> has some krb5 libs included as would realm.
>
> -g
>
>
>
>
> On Mon, Jul 23, 2018 at 2:02 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>
>> This begs the question (which I should know the answers to) but what are
>> the differences in the various ways to join a domain?
>>
>> Sent from my iPhone with a soon to be cracked or broken screen.
>>
>> On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:
>>
>> Thanks Rory, we are not using net to join machines but good to know.
>>
>> -g
>>
>>
>>
>> On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>>
>>>
>>> net ads join -Uusername%password also works.
>>>
>>> ________________________________
>>> From: studiosysadmins-discuss-bounces@studiosysadmins.com
>>> <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg
>>> whynott <greg.whynott@gmail.com>
>>> Sent: Monday, July 23, 2018 12:58 PM
>>> To: studiosysadmins-discuss
>>> Subject: [SSA-Discuss] join linux machines to domain without password
>>> prompt.
>>>
>>> If you don't join linux machines to AD bail now,
>>>
>>>
>>>
>>> Should it be helpful...
>>>
>>>
>>> During my move from NSLCD to SSSD one of the challenges was adding
>>> machines to the domain silently without interaction required.
>>>
>>> Both the realm and net command require you to enter your password and
>>> neither (from what I can tell) have a flag to pass the password along on the
>>> command line.
>>>
>>> There are many articles on how to do this as a one off, typically
>>> requiring you to pre-add the machine to the domain, one time pass or
>>> similar. These methods don't scale well beyond 1 machine.
>>>
>>> My intention was to deploy hundreds of machines using kickstart and have
>>> them all 100% done when the installer finished up, unattended.
>>>
>>> After a lot of searching for methods and without much luck, unix itself
>>> provided the method. Should of been obvious but I guess my head was in
>>> windows mode at the time.
>>>
>>> if you type:
>>>
>>> realm join ad01.mydomain.com -U accountname
>>>
>>> It'll ask you for a password. To get around this, instead type:
>>>
>>> echo mypassword | realm join ad01.mydomain.com -U accountname
>>>
>>>
>>> power of the pipe!
>>>
>>>
>>> kinit works the same:
>>>
>>> echo mypassword | kinit -U accountname
>>>
>>>
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>> To unsubscribe from the list send a blank e-mail to
>>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>
>
>
> To unsubscribe from the list send a blank e-mail to
> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

The reason I'm using SSSD over NSLCD due to its caching behavior more than anything else.. Caching on NSLCD is limited and basically useless in our environment.

Every file you touch, menu you click on, and so on, NSLCD will make a call to the configured authentication source. In our situation that was about 60,000 calls a day, the AD server was busy. Logging into a machine would take up to or longer than a minute before it "let go" and you were able to operate the menus and what not. Switched to SSSD and login's happen in seconds now. A huge difference. doing a packet capture we see only one ldap call instead of a hundred or so during log in.

As an example, doing a packet capture during a GDM GUI log in session would produce much more traffic using NSLCD than SSSD:

nslcd: 3.9 megabytes in LDAP queries. (this is due to a bad base which is due to be changed)
sssd: 188K

Everything feels more snappy with SSSD. . Its what systemd is to initd in a way. Does the same thing but more intelligently.


-g



On Mon, Jul 23, 2018 at 3:31 PM, Jean-Francois Panisset <panisset@gmail.com> wrote:

sssd does seem to be the preferred approach for RHEL these days, this
RedHat blog post (and others in the series) seems to have a fairly
decent breakdown of approaches.

https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/

JF


On Mon, Jul 23, 2018 at 11:29 AM, greg whynott <greg.whynott@gmail.com> wrote:
> Good question. The best I could come up with is that net is part of the
> samba tools and realm is not. lol You can join a kerberos domain which
> isn't M$ AD based, so perhaps that's part of it. AD uses the kerberos
> protocol.
>
> KRB was around before AD, M$ chose to implement it. So I'm assuming net
> has some krb5 libs included as would realm.
>
> -g
>
>
>
>
> On Mon, Jul 23, 2018 at 2:02 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>
>> This begs the question (which I should know the answers to) but what are
>> the differences in the various ways to join a domain?
>>
>> Sent from my iPhone with a soon to be cracked or broken screen.
>>
>> On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:
>>
>> Thanks Rory, we are not using net to join machines but good to know.
>>
>> -g
>>
>>
>>
>> On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>>
>>>
>>> net ads join -Uusername%password also works.
>>>
>>> ________________________________
>>> From: studiosysadmins-discuss-bounces@studiosysadmins.com
>>> <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg
>>> whynott <greg.whynott@gmail.com>
>>> Sent: Monday, July 23, 2018 12:58 PM
>>> To: studiosysadmins-discuss
>>> Subject: [SSA-Discuss] join linux machines to domain without password
>>> prompt.
>>>
>>> If you don't join linux machines to AD bail now,
>>>
>>>
>>>
>>> Should it be helpful...
>>>
>>>
>>> During my move from NSLCD to SSSD one of the challenges was adding
>>> machines to the domain silently without interaction required.
>>>
>>> Both the realm and net command require you to enter your password and
>>> neither (from what I can tell) have a flag to pass the password along on the
>>> command line.
>>>
>>> There are many articles on how to do this as a one off, typically
>>> requiring you to pre-add the machine to the domain, one time pass or
>>> similar. These methods don't scale well beyond 1 machine.
>>>
>>> My intention was to deploy hundreds of machines using kickstart and have
>>> them all 100% done when the installer finished up, unattended.
>>>
>>> After a lot of searching for methods and without much luck, unix itself
>>> provided the method. Should of been obvious but I guess my head was in
>>> windows mode at the time.
>>>
>>> if you type:
>>>
>>> realm join ad01.mydomain.com -U accountname
>>>
>>> It'll ask you for a password. To get around this, instead type:
>>>
>>> echo mypassword | realm join ad01.mydomain.com -U accountname
>>>
>>>
>>> power of the pipe!
>>>
>>>
>>> kinit works the same:
>>>
>>> echo mypassword | kinit -U accountname
>>>
>>>
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>> To unsubscribe from the list send a blank e-mail to
>>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>
>
>
> To unsubscribe from the list send a blank e-mail to
> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

sssd does seem to be the preferred approach for RHEL these days, this
RedHat blog post (and others in the series) seems to have a fairly
decent breakdown of approaches.

https://rhelblog.redhat.com/2015/02/04/overview-of-direct-integration-options/

JF


On Mon, Jul 23, 2018 at 11:29 AM, greg whynott <greg.whynott@gmail.com> wrote:
> Good question. The best I could come up with is that net is part of the
> samba tools and realm is not. lol You can join a kerberos domain which
> isn't M$ AD based, so perhaps that's part of it. AD uses the kerberos
> protocol.
>
> KRB was around before AD, M$ chose to implement it. So I'm assuming net
> has some krb5 libs included as would realm.
>
> -g
>
>
>
>
> On Mon, Jul 23, 2018 at 2:02 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>
>> This begs the question (which I should know the answers to) but what are
>> the differences in the various ways to join a domain?
>>
>> Sent from my iPhone with a soon to be cracked or broken screen.
>>
>> On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:
>>
>> Thanks Rory, we are not using net to join machines but good to know.
>>
>> -g
>>
>>
>>
>> On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:
>>>
>>>
>>> net ads join -Uusername%password also works.
>>>
>>> ________________________________
>>> From: studiosysadmins-discuss-bounces@studiosysadmins.com
>>> <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg
>>> whynott <greg.whynott@gmail.com>
>>> Sent: Monday, July 23, 2018 12:58 PM
>>> To: studiosysadmins-discuss
>>> Subject: [SSA-Discuss] join linux machines to domain without password
>>> prompt.
>>>
>>> If you don't join linux machines to AD bail now,
>>>
>>>
>>>
>>> Should it be helpful...
>>>
>>>
>>> During my move from NSLCD to SSSD one of the challenges was adding
>>> machines to the domain silently without interaction required.
>>>
>>> Both the realm and net command require you to enter your password and
>>> neither (from what I can tell) have a flag to pass the password along on the
>>> command line.
>>>
>>> There are many articles on how to do this as a one off, typically
>>> requiring you to pre-add the machine to the domain, one time pass or
>>> similar. These methods don't scale well beyond 1 machine.
>>>
>>> My intention was to deploy hundreds of machines using kickstart and have
>>> them all 100% done when the installer finished up, unattended.
>>>
>>> After a lot of searching for methods and without much luck, unix itself
>>> provided the method. Should of been obvious but I guess my head was in
>>> windows mode at the time.
>>>
>>> if you type:
>>>
>>> realm join ad01.mydomain.com -U accountname
>>>
>>> It'll ask you for a password. To get around this, instead type:
>>>
>>> echo mypassword | realm join ad01.mydomain.com -U accountname
>>>
>>>
>>> power of the pipe!
>>>
>>>
>>> kinit works the same:
>>>
>>> echo mypassword | kinit -U accountname
>>>
>>>
>>> greg
>>>
>>>
>>>
>>>
>>>
>>>
>>> To unsubscribe from the list send a blank e-mail to
>>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>>
>>
>> To unsubscribe from the list send a blank e-mail to
>> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
>
>
>
> To unsubscribe from the list send a blank e-mail to
> mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe
To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

This begs the question (which I should know the answers to) but what are the differences in the various ways to join a domain?

Sent from my iPhone with a soon to be cracked or broken screen.
On Jul 23, 2018, at 13:59, greg whynott <greg.whynott@gmail.com> wrote:

Thanks Rory, we are not using net to join machines but good to know.

-g


On Mon, Jul 23, 2018 at 1:00 PM, Rory Falloon <rory@mrxfx.com> wrote:

net ads join -Uusername%password also works.

---

From: studiosysadmins-discuss-bounces@studiosysadmins.com <studiosysadmins-discuss-bounces@studiosysadmins.com> on behalf of greg whynott <greg.whynott@gmail.com>
Sent: Monday, July 23, 2018 12:58 PM
To: studiosysadmins-discuss
Subject: [SSA-Discuss] join linux machines to domain without password prompt. If you don't join linux machines to AD bail now,


Should it be helpful...

During my move from NSLCD to SSSD one of the challenges was adding machines to the domain silently without interaction required.
Both the realm and net command require you to enter your password and neither (from what I can tell) have a flag to pass the password along on the command line.

There are many articles on how to do this as a one off, typically requiring you to pre-add the machine to the domain, one time pass or similar. These methods don't scale well beyond 1 machine.
My intention was to deploy hundreds of machines using kickstart and have them all 100% done when the installer finished up, unattended.

After a lot of searching for methods and without much luck, unix itself provided the method. Should of been obvious but I guess my head was in windows mode at the time.
if you type:
realm join ad01.mydomain.com -U accountname

It'll ask you for a password. To get around this, instead type:
echo mypassword | realm join ad01.mydomain.com -U accountname


power of the pipe!

kinit works the same:
echo mypassword | kinit -U accountname

greg





To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe

To unsubscribe from the list send a blank e-mail to mailto:studiosysadmins-discuss-request@studiosysadmins.com?subject=unsubscribe