Smart proxy active directory realm provider; thoughts and rfc

helge000 · February 9, 2016, 1:38pm

Hello Foreman - Team,

since a some time I am toying the idea implementing a realm provider for
active directory.
I think this is not a very hard task as the realm_api implements only a
post and a delete request.

I know little on your plans on the matter, I hope to discuss this
further here.

Please advise, comment on the following thoughts I had:

Extend realm_setup with a case for 'activedirectory'
add the provider in modules/realm/activedirectoy.rb
add a test and a settings.d example

Provider:
I think about implementing an execute method as done in ms_native dhcp,
dnscmd. The main issue is how to proceed with this method, I see two
options:

Run local powershell with AD cmdlets using open3 as done in the other
ms providers. These would basically be {New,Remove,Get}-ADComputer piped
to ConvertTo-Json.
Use WinRM [1]. For starters I would try to keep it simple and only
support localhost endpoints; later on implementing SSL direct connections.

Settings:

Should we let the user define a domain in the settings?
Should we let the user define the Default Computer OU?

Alternatively we could the above figure it out in initialize, running
Get-ADDomain -Current LocalComputer; though setting this is probably the
better idea.

For WinRM, some settings more settings would be needed:

:winrm_endpoint: = 'http://localhost:5985/wsman'
:winrm_user: administrator@domain.com
:winrm_password: password

I much prefer option 2 - and currently see the following issues and
benefits:

Downsides:

Adding a new gem
Users would need to enable remote management. In most practical cases
this would be enabled already and is fairly simple compared to
installing smart-proxy on windows.

Benefits:

I think all MS smart-proxy providers could benefit from WinRM at some
point; the idea here is a Linux smart proxy can handle dnscmd; netshell
or a more modern powershell implementation directly. The realm provider
could be the first of this kind; maybe call it ms_rm_dns; ms_rm_dhcp etc.

[1] https://github.com/WinRb/WinRM

Cheers and looking forward to your thoughts,

···

-- Daniel Helgenberger Schivelbeiner Str. 46 10439 Berlin

stbenjam · February 9, 2016, 11:44pm

Hi!

> Hello Foreman - Team,
>
> since a some time I am toying the idea implementing a realm provider for
> active directory.
> I think this is not a very hard task as the realm_api implements only a
> post and a delete request.

The API is simple, but works so far pretty well with FreeIPA. The POST
allows pre-creating a host record and get a join password from whatever
realm system. The DELETE request cleans up when the host is deleted
from Foreman or rebuilt.

But, I admittedly know very little about AD.

What would the other kinds of requests would you want to make? We can
certainly handle things differently in Foreman for AD than FreeIPA if
it's needed.

> I know little on your plans on the matter, I hope to discuss this
> further here.

No specific plans. A couple people have asked and made some attempts but
no one's opened an actual PR yet. I'd really like to this, it's a very
often requested feature.

> Please advise, comment on the following thoughts I had:
>
> - Extend realm_setup with a case for 'activedirectory'
> - add the provider in modules/realm/activedirectoy.rb
> - add a test and a settings.d example

Yup, this sounds right as the initial steps.

>
> Provider:
> I think about implementing an execute method as done in ms_native dhcp,
> dnscmd. The main issue is how to proceed with this method, I see two
> options:
>
> 1. Run local powershell with AD cmdlets using open3 as done in the other
> ms providers. These would basically be {New,Remove,Get}-ADComputer piped
> to ConvertTo-Json.
>
> 2. Use WinRM [1]. For starters I would try to keep it simple and only
> support localhost endpoints; later on implementing SSL direct connections.
>
> Settings:
> - Should we let the user define a domain in the settings?
> - Should we let the user define the Default Computer OU?
>
> Alternatively we could the above figure it out in initialize, running
> Get-ADDomain -Current LocalComputer; though setting this is probably the
> better idea.
>
> For WinRM, some settings more settings would be needed:
>
> :winrm_endpoint: = 'http://localhost:5985/wsman'
> :winrm_user: administrator@domain.com
> :winrm_password: password
>
> I much prefer option 2 - and currently see the following issues and
> benefits:
>
> Downsides:
> - Adding a new gem
>
> - Users would need to enable remote management. In most practical cases
> this would be enabled already and is fairly simple compared to
> installing smart-proxy on windows.
>
> Benefits:
> - I think all MS smart-proxy providers could benefit from WinRM at some
> point; the idea here is a Linux smart proxy can handle dnscmd; netshell
> or a more modern powershell implementation directly. The realm provider
> could be the first of this kind; maybe call it ms_rm_dns; ms_rm_dhcp etc.
>
> [1] GitHub - WinRb/WinRM: Ruby library for Windows Remote Management

There's an open issue for this where you can see some of the discussions
we had before, Feature #4917: Smart-Proxy Realm Provider for Active Directory - Smart Proxy - Foreman, including
someone who made an initial attempt using 'mskutil'.

When this was originally investgated, we considered 'adcli', and there's
some examples of how it's used here:
Features/AnacondaRealmIntegration - Fedora Project Wiki

Regardless we would have some additional dependency to handle AD, so a
new gem is no problem itself.

I'm no AD guru to say what's best. I think it'd be ideal if we could get
it supported to run remotely eventually as I guess many users would
prefer to run the smart proxy on *nix. But Smart Proxy on windows is
still possible AFAIK.

···

On Tue, Feb 09, 2016 at 02:38:37PM +0100, Daniel Helgenberger wrote:

Cheers and looking forward to your thoughts,

–
Daniel Helgenberger
Schivelbeiner Str. 46
10439 Berlin

–
You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

helge000 · February 10, 2016, 9:56am

> Hi!
Hello Stephen,

>
>> Hello Foreman - Team,
>>
>> since a some time I am toying the idea implementing a realm provider for
>> active directory.
>> I think this is not a very hard task as the realm_api implements only a
>> post and a delete request.
>
> The API is simple, but works so far pretty well with FreeIPA. The POST
> allows pre-creating a host record and get a join password from whatever
> realm system. The DELETE request cleans up when the host is deleted
> from Foreman or rebuilt.
I think the basic functionality is there using only these two requests.
I would very much like to start out reusing the api; at least I think
there are no changes to be done in foreman this way.

>
> But, I admittedly know very little about AD.
>
> What would the other kinds of requests would you want to make? We can
> certainly handle things differently in Foreman for AD than FreeIPA if
> it's needed.
One thing I am thinking about and currently consider quite spcific to my
needs is to 'sync' foreman host groups with AD OU's with a given suffix.
This way I add some things for Windows Hosts I cannot currently manage
with puppet; GPOs and GPPs. But this needs a special api call from
Foreman to the proxy on host group change - I do not know if such a
feature was ever considered. Do you think this might be useful?

>
>> I know little on your plans on the matter, I hope to discuss this
>> further here.
>
> No specific plans. A couple people have asked and made some attempts but
> no one's opened an actual PR yet. I'd really like to this, it's a very
> often requested feature.
>
>> Please advise, comment on the following thoughts I had:
>>
>> - Extend realm_setup with a case for 'activedirectory'
>> - add the provider in modules/realm/activedirectoy.rb
>> - add a test and a settings.d example
>
> Yup, this sounds right as the initial steps.
I think I can just use the new provider on foreman's side once the
realm_setup handles this?

>
>>
>> Provider:
>> I think about implementing an execute method as done in ms_native dhcp,
>> dnscmd. The main issue is how to proceed with this method, I see two
>> options:
>>
>> 1. Run local powershell with AD cmdlets using open3 as done in the other
>> ms providers. These would basically be {New,Remove,Get}-ADComputer piped
>> to ConvertTo-Json.
>>
>> 2. Use WinRM [1]. For starters I would try to keep it simple and only
>> support localhost endpoints; later on implementing SSL direct connections.
>>
>> Settings:
>> - Should we let the user define a domain in the settings?
>> - Should we let the user define the Default Computer OU?
>>
>> Alternatively we could the above figure it out in initialize, running
>> Get-ADDomain -Current LocalComputer; though setting this is probably the
>> better idea.
>>
>> For WinRM, some settings more settings would be needed:
>>
>> :winrm_endpoint: = 'http://localhost:5985/wsman'
>> :winrm_user: administrator@domain.com
>> :winrm_password: password
>>
>> I much prefer option 2 - and currently see the following issues and
>> benefits:
>>
>> Downsides:
>> - Adding a new gem
>>
>> - Users would need to enable remote management. In most practical cases
>> this would be enabled already and is fairly simple compared to
>> installing smart-proxy on windows.
>>
>> Benefits:
>> - I think all MS smart-proxy providers could benefit from WinRM at some
>> point; the idea here is a Linux smart proxy can handle dnscmd; netshell
>> or a more modern powershell implementation directly. The realm provider
>> could be the first of this kind; maybe call it ms_rm_dns; ms_rm_dhcp etc.
>>
>> [1] GitHub - WinRb/WinRM: Ruby library for Windows Remote Management
>
> There's an open issue for this where you can see some of the discussions
> we had before, , including
> someone who made an initial attempt using 'mskutil'.
Thanks! I missed this.

I think it is ok to hijack the ticket for the PR?

>
> When this was originally investgated, we considered 'adcli', and there's
> some examples of how it's used here:
> Features/AnacondaRealmIntegration - Fedora Project Wiki
>
> Regardless we would have some additional dependency to handle AD, so a
> new gem is no problem itself.
Cool, I would try submit the PR using winRm then.

>
> I'm no AD guru to say what's best. I think it'd be ideal if we could get
> it supported to run remotely eventually as I guess many users would
> prefer to run the smart proxy on *nix. But Smart Proxy on windows is
> still possible AFAIK.
My way of thought was to keep the existing providers and migrate them to
powershell and maybe even WinRM on the long run. Though I admit this is
more a feeling than hard evide: Microsoft is deprecating tools like
netsh, adcli, dnscmd in favor for powershell.

···

On 10.02.2016 00:44, Stephen Benjamin wrote: > On Tue, Feb 09, 2016 at 02:38:37PM +0100, Daniel Helgenberger wrote:

Cheers and looking forward to your thoughts,

–
Daniel Helgenberger
Schivelbeiner Str. 46
10439 Berlin

–
You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

–
Daniel Helgenberger
Schivelbeiner Str. 46
10439 Berlin

stbenjam · February 10, 2016, 5:15pm

>
>
> > Hi!
> Hello Stephen,
>
> >
> >> Hello Foreman - Team,
> >>
> >> since a some time I am toying the idea implementing a realm provider for
> >> active directory.
> >> I think this is not a very hard task as the realm_api implements only a
> >> post and a delete request.
> >
> > The API is simple, but works so far pretty well with FreeIPA. The POST
> > allows pre-creating a host record and get a join password from whatever
> > realm system. The DELETE request cleans up when the host is deleted
> > from Foreman or rebuilt.
> I think the basic functionality is there using only these two requests.
> I would very much like to start out reusing the api; at least I think
> there are no changes to be done in foreman this way.
>
> >
> > But, I admittedly know very little about AD.
> >
> > What would the other kinds of requests would you want to make? We can
> > certainly handle things differently in Foreman for AD than FreeIPA if
> > it's needed.
> One thing I am thinking about and currently consider quite spcific to my
> needs is to 'sync' foreman host groups with AD OU's with a given suffix.
> This way I add some things for Windows Hosts I cannot currently manage
> with puppet; GPOs and GPPs. But this needs a special api call from
> Foreman to the proxy on host group change - I do not know if such a
> feature was ever considered. Do you think this might be useful?

Well, we actually do this already! If the Foreman host group changes we
notify via the POST api, and have the update flag set. I guess it
should/could be a different API call, but that's how it works.

This update_realm method is called when the host group is changed:

https://github.com/theforeman/foreman/blob/develop/app/models/concerns/orchestration/realm.rb#L42

By this code:

https://github.com/theforeman/foreman/blob/develop/app/models/concerns/orchestration/realm.rb#L60

So, your realm implementation would get this new information and can do
whatever you'd like with it in the create method by checking the
'update' flag. You also get a 'rebuild' flag in the case of rebuilding
a host, so you don't strictly need to delete a computer and re-create
it.

>
> >
> >> I know little on your plans on the matter, I hope to discuss this
> >> further here.
> >
> > No specific plans. A couple people have asked and made some attempts but
> > no one's opened an actual PR yet. I'd really like to this, it's a very
> > often requested feature.
> >
> >> Please advise, comment on the following thoughts I had:
> >>
> >> - Extend realm_setup with a case for 'activedirectory'
> >> - add the provider in modules/realm/activedirectoy.rb
> >> - add a test and a settings.d example
> >
> > Yup, this sounds right as the initial steps.
> I think I can just use the new provider on foreman's side once the
> realm_setup handles this?

Yes, it would Just Work as long as you don't need any changes on the
Foreman side to handle some special case for active directory.

I would guess we should make sure the templates handle automatic
registration fine. There's some bits already there, but it's never been
used:

https://github.com/theforeman/community-templates/blob/develop/kickstart/provision_rhel.erb#L54

>
> >
> >>
> >> Provider:
> >> I think about implementing an execute method as done in ms_native dhcp,
> >> dnscmd. The main issue is how to proceed with this method, I see two
> >> options:
> >>
> >> 1. Run local powershell with AD cmdlets using open3 as done in the other
> >> ms providers. These would basically be {New,Remove,Get}-ADComputer piped
> >> to ConvertTo-Json.
> >>
> >> 2. Use WinRM [1]. For starters I would try to keep it simple and only
> >> support localhost endpoints; later on implementing SSL direct connections.
> >>
> >> Settings:
> >> - Should we let the user define a domain in the settings?
> >> - Should we let the user define the Default Computer OU?
> >>
> >> Alternatively we could the above figure it out in initialize, running
> >> Get-ADDomain -Current LocalComputer; though setting this is probably the
> >> better idea.
> >>
> >> For WinRM, some settings more settings would be needed:
> >>
> >> :winrm_endpoint: = 'http://localhost:5985/wsman'
> >> :winrm_user: administrator@domain.com
> >> :winrm_password: password
> >>
> >> I much prefer option 2 - and currently see the following issues and
> >> benefits:
> >>
> >> Downsides:
> >> - Adding a new gem
> >>
> >> - Users would need to enable remote management. In most practical cases
> >> this would be enabled already and is fairly simple compared to
> >> installing smart-proxy on windows.
> >>
> >> Benefits:
> >> - I think all MS smart-proxy providers could benefit from WinRM at some
> >> point; the idea here is a Linux smart proxy can handle dnscmd; netshell
> >> or a more modern powershell implementation directly. The realm provider
> >> could be the first of this kind; maybe call it ms_rm_dns; ms_rm_dhcp etc.
> >>
> >> [1] https://github.com/WinRb/WinRM
> >
> > There's an open issue for this where you can see some of the discussions
> > we had before, , including
> > someone who made an initial attempt using 'mskutil'.
> Thanks! I missed this.
>
> I think it is ok to hijack the ticket for the PR?

Definitely

> >
> > When this was originally investgated, we considered 'adcli', and there's
> > some examples of how it's used here:
> > https://fedoraproject.org/wiki/Features/AnacondaRealmIntegration
> >
> > Regardless we would have some additional dependency to handle AD, so a
> > new gem is no problem itself.
> Cool, I would try submit the PR using winRm then.
>
> >
> > I'm no AD guru to say what's best. I think it'd be ideal if we could get
> > it supported to run remotely eventually as I guess many users would
> > prefer to run the smart proxy on *nix. But Smart Proxy on windows is
> > still possible AFAIK.
> My way of thought was to keep the existing providers and migrate them to
> powershell and maybe even WinRM on the long run. Though I admit this is
> more a feeling than hard evide: Microsoft is deprecating tools like
> netsh, adcli, dnscmd in favor for powershell.

Well, adcli isn't from microsoft, and I would think they're not going to
get rid of how it's communicating with AD?

My main point was this makes it more difficult for *nix admins to make
them run a smart proxy on top of windows to get the AD integration,
since there are tools that work in the *nix space. But, we can have that
discussion when there's some code to look at to understand what you're
proposing when you say powershell.

···

On Wed, Feb 10, 2016 at 10:56:48AM +0100, Daniel Helgenberger wrote: > On 10.02.2016 00:44, Stephen Benjamin wrote: > > On Tue, Feb 09, 2016 at 02:38:37PM +0100, Daniel Helgenberger wrote:

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

helge000 · February 10, 2016, 4:57pm

[Test]
sorry for the Spam: Checking - I suspect google groups did not like my
simple signature.

···

On 10.02.2016 17:09, Dominic Cleal wrote: > Hi Daniel, > > As you noticed when you first posted to the list in this thread, your > message didn't get through immediately. It also happened today with > your reply to Stephen. > > For some reason Google's marking your messages as potential spam so they > get held in the moderation queue until the semi-regular reminder is sent > to us, or we happen to see it. I can't see anything wrong in the > headers, it seems to be passing SPF checks etc, so I'm unsure why it's > happening on every post. > > Sorry for any delay! >

helge000 · February 11, 2016, 12:08pm

>>
>>
>>> Hi!
>> Hello Stephen,
>>
>>>
>>>> Hello Foreman - Team,
>>>>
>>>> since a some time I am toying the idea implementing a realm provider for
>>>> active directory.
>>>> I think this is not a very hard task as the realm_api implements only a
>>>> post and a delete request.
>>>
>>> The API is simple, but works so far pretty well with FreeIPA. The POST
>>> allows pre-creating a host record and get a join password from whatever
>>> realm system. The DELETE request cleans up when the host is deleted
>>> from Foreman or rebuilt.
>> I think the basic functionality is there using only these two requests.
>> I would very much like to start out reusing the api; at least I think
>> there are no changes to be done in foreman this way.
>>
>>>
>>> But, I admittedly know very little about AD.
>>>
>>> What would the other kinds of requests would you want to make? We can
>>> certainly handle things differently in Foreman for AD than FreeIPA if
>>> it's needed.
>> One thing I am thinking about and currently consider quite spcific to my
>> needs is to 'sync' foreman host groups with AD OU's with a given suffix.
>> This way I add some things for Windows Hosts I cannot currently manage
>> with puppet; GPOs and GPPs. But this needs a special api call from
>> Foreman to the proxy on host group change - I do not know if such a
>> feature was ever considered. Do you think this might be useful?
>
> Well, we actually do this already! If the Foreman host group changes we
> notify via the POST api, and have the update flag set. I guess it
> should/could be a different API call, but that's how it works.
>
> This update_realm method is called when the host group is changed:
>
> foreman/app/models/concerns/orchestration/realm.rb at develop · theforeman/foreman · GitHub
>
> By this code:
>
> foreman/app/models/concerns/orchestration/realm.rb at develop · theforeman/foreman · GitHub
>
> So, your realm implementation would get this new information and can do
> whatever you'd like with it in the create method by checking the
> 'update' flag. You also get a 'rebuild' flag in the case of rebuilding
> a host, so you don't strictly need to delete a computer and re-create
> it.
Thanks for pointing this out! Can it be the realm API does not implement
such an update ATM?

I think there might be an issue getting the ad provider to work right a
away as set_realm() relies on a OTP; this is a good idea; but have to
investigate how to get it working:

github.com

theforeman/foreman/blob/develop/app/models/concerns/orchestration/realm.rb#L34


      
            logger.info "Delete realm entry for #{name}"
            @realm_api.delete name
          end
          
          # Adds the host to the realm, and sets otp if we get one back
          def set_realm(options = {})
            initialize_realm
            logger.info "#{options[:update] ? 'Update' : 'Add'} realm entry for #{options[:rebuild] ? 'reprovisioned' : 'new'} host #{name}"
            options[:hostname]  = name
            options[:userclass] = hostgroup.title unless hostgroup.nil?
            result = @realm_api.create options
            raise ::Foreman::Exception.new(N_('Realm proxy did not return a one-time password')) unless options[:update] || result.has_key?("randompassword")
            self.otp = result["randompassword"]
            result
          rescue => e
            failure _("Failed to create %{name}'s realm entry: %{e}") % { :name => name, :e => e }, e
          end
          
          def update_realm
            set_realm :update => true
          end

Further, I think best to break the task up and get the provider working
as a fist step and integrate the it later in foreman.

>
>>
>>>
>>>> I know little on your plans on the matter, I hope to discuss this
>>>> further here.
>>>
>>> No specific plans. A couple people have asked and made some attempts but
>>> no one's opened an actual PR yet. I'd really like to this, it's a very
>>> often requested feature.
>>>
>>>> Please advise, comment on the following thoughts I had:
>>>>
>>>> - Extend realm_setup with a case for 'activedirectory'
>>>> - add the provider in modules/realm/activedirectoy.rb
>>>> - add a test and a settings.d example
>>>
>>> Yup, this sounds right as the initial steps.
>> I think I can just use the new provider on foreman's side once the
>> realm_setup handles this?
>
> Yes, it would Just Work as long as you don't need any changes on the
> Foreman side to handle some special case for active directory.
>
> I would guess we should make sure the templates handle automatic
> registration fine. There's some bits already there, but it's never been
> used:
>
> https://github.com/theforeman/community-templates/blob/develop/kickstart/provision_rhel.erb#L54
In case of windows, we need to leverage this on provision template also;
the realm provider is not necessary to do that. I have a working foreman
/ windows; and use this, a user with creds to join the domain:

github.com

helge000/community-templates/blob/wimaging-ng/waik/waik_userdata_joinDomain.ps1.erb

<%#
#kind: user_data
#name: WAIK joinDomain.ps1
#oses:
#- Windows 6.1
#- Windows 6.3
#params:
#- domainJoinAccount: administrator@domain.com # use tthis account to join domain. If set, domain join will run
#- domainJoinAccountPasswd: Password for the domain Admin account
#- computerLdapPath: OU=Computers,CN=domain,CN=com # Place the computer account in specified Organizational Unit
#- computerDomain: domain.com # domain to join, optional
-%>
$user = "<%= @host.params['domainJoinAccount'] -%>"
$passwd = ConvertTo-SecureString -String "<%= @host.params['domainJoinAccountPasswd'] -%>" -AsPlainText -Force
$Credential = New-Object -TypeName System.Management.Automation.PSCredential -ArgumentList $user, $passwd
Add-Computer -DomainName <% if @host.params['computerDomain'] -%><%= @host.params['computerDomain'] -%><% else -%><%= @host.domain -%><% end -%> -Credential $Credential <% if  @host.params['computerLdapPath'] -%>-OUPath "<%= @host.params['computerLdapPath'] -%>"<% elsif snippet('WAIK OU from hostgroup') -%>-OUPath "<%= snippet('WAIK OU from hostgroup') -%>"<% end -%> -PassThru

If the OTP works, it would be even better.
>
>>
>>>
>>>>
>>>> Provider:
>>>> I think about implementing an execute method as done in ms_native dhcp,
>>>> dnscmd. The main issue is how to proceed with this method, I see two
>>>> options:
>>>>
>>>> 1. Run local powershell with AD cmdlets using open3 as done in the other
>>>> ms providers. These would basically be {New,Remove,Get}-ADComputer piped
>>>> to ConvertTo-Json.
>>>>
>>>> 2. Use WinRM [1]. For starters I would try to keep it simple and only
>>>> support localhost endpoints; later on implementing SSL direct connections.
>>>>
>>>> Settings:
>>>> - Should we let the user define a domain in the settings?
>>>> - Should we let the user define the Default Computer OU?
>>>>
>>>> Alternatively we could the above figure it out in initialize, running
>>>> Get-ADDomain -Current LocalComputer; though setting this is probably the
>>>> better idea.
>>>>
>>>> For WinRM, some settings more settings would be needed:
>>>>
>>>> :winrm_endpoint: = 'http://localhost:5985/wsman'
>>>> :winrm_user: administrator@domain.com
>>>> :winrm_password: password
>>>>
>>>> I much prefer option 2 - and currently see the following issues and
>>>> benefits:
>>>>
>>>> Downsides:
>>>> - Adding a new gem
>>>>
>>>> - Users would need to enable remote management. In most practical cases
>>>> this would be enabled already and is fairly simple compared to
>>>> installing smart-proxy on windows.
>>>>
>>>> Benefits:
>>>> - I think all MS smart-proxy providers could benefit from WinRM at some
>>>> point; the idea here is a Linux smart proxy can handle dnscmd; netshell
>>>> or a more modern powershell implementation directly. The realm provider
>>>> could be the first of this kind; maybe call it ms_rm_dns; ms_rm_dhcp etc.
>>>>
>>>> [1] GitHub - WinRb/WinRM: Ruby library for Windows Remote Management
>>>
>>> There's an open issue for this where you can see some of the discussions
>>> we had before, , including
>>> someone who made an initial attempt using 'mskutil'.
>> Thanks! I missed this.
>>
>> I think it is ok to hijack the ticket for the PR?
>
> Definitely
>
>>>
>>> When this was originally investgated, we considered 'adcli', and there's
>>> some examples of how it's used here:
>>> Features/AnacondaRealmIntegration - Fedora Project Wiki
>>>
>>> Regardless we would have some additional dependency to handle AD, so a
>>> new gem is no problem itself.
>> Cool, I would try submit the PR using winRm then.
>>
>>>
>>> I'm no AD guru to say what's best. I think it'd be ideal if we could get
>>> it supported to run remotely eventually as I guess many users would
>>> prefer to run the smart proxy on *nix. But Smart Proxy on windows is
>>> still possible AFAIK.
>> My way of thought was to keep the existing providers and migrate them to
>> powershell and maybe even WinRM on the long run. Though I admit this is
>> more a feeling than hard evide: Microsoft is deprecating tools like
>> netsh, adcli, dnscmd in favor for powershell.
>
> Well, adcli isn't from microsoft, and I would think they're not going to
> get rid of how it's communicating with AD?
Indeed! Sorry, I mixed that up

···

On 10.02.2016 18:15, Stephen Benjamin wrote: > On Wed, Feb 10, 2016 at 10:56:48AM +0100, Daniel Helgenberger wrote: >> On 10.02.2016 00:44, Stephen Benjamin wrote: >>> On Tue, Feb 09, 2016 at 02:38:37PM +0100, Daniel Helgenberger wrote:

My main point was this makes it more difficult for *nix admins to make
them run a smart proxy on top of windows to get the AD integration,
since there are tools that work in the *nix space. But, we can have that
discussion when there’s some code to look at to understand what you’re
proposing when you say powershell.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

–
Daniel Helgenberger (helge000)
daniel@helgenberger.net

stbenjam · February 11, 2016, 1:06pm

>
>
> >>
> >>
> >>> Hi!
> >> Hello Stephen,
> >>
> >>>
> >>>> Hello Foreman - Team,
> >>>>
> >>>> since a some time I am toying the idea implementing a realm provider for
> >>>> active directory.
> >>>> I think this is not a very hard task as the realm_api implements only a
> >>>> post and a delete request.
> >>>
> >>> The API is simple, but works so far pretty well with FreeIPA. The POST
> >>> allows pre-creating a host record and get a join password from whatever
> >>> realm system. The DELETE request cleans up when the host is deleted
> >>> from Foreman or rebuilt.
> >> I think the basic functionality is there using only these two requests.
> >> I would very much like to start out reusing the api; at least I think
> >> there are no changes to be done in foreman this way.
> >>
> >>>
> >>> But, I admittedly know very little about AD.
> >>>
> >>> What would the other kinds of requests would you want to make? We can
> >>> certainly handle things differently in Foreman for AD than FreeIPA if
> >>> it's needed.
> >> One thing I am thinking about and currently consider quite spcific to my
> >> needs is to 'sync' foreman host groups with AD OU's with a given suffix.
> >> This way I add some things for Windows Hosts I cannot currently manage
> >> with puppet; GPOs and GPPs. But this needs a special api call from
> >> Foreman to the proxy on host group change - I do not know if such a
> >> feature was ever considered. Do you think this might be useful?
> >
> > Well, we actually do this already! If the Foreman host group changes we
> > notify via the POST api, and have the update flag set. I guess it
> > should/could be a different API call, but that's how it works.
> >
> > This update_realm method is called when the host group is changed:
> >
> > foreman/app/models/concerns/orchestration/realm.rb at develop · theforeman/foreman · GitHub
> >
> > By this code:
> >
> > foreman/app/models/concerns/orchestration/realm.rb at develop · theforeman/foreman · GitHub
> >
> > So, your realm implementation would get this new information and can do
> > whatever you'd like with it in the create method by checking the
> > 'update' flag. You also get a 'rebuild' flag in the case of rebuilding
> > a host, so you don't strictly need to delete a computer and re-create
> > it.
> Thanks for pointing this out! Can it be the realm API does not implement
> such an update ATM?
>
> I think there might be an issue getting the ad provider to work right a
> away as set_realm() relies on a OTP; this is a good idea; but have to
> investigate how to get it working:
>
> foreman/app/models/concerns/orchestration/realm.rb at develop · theforeman/foreman · GitHub

In general we expect an OTP for a new host, how else would you do
it? AD supports pre-adding computers with a join password AFAIK.

For the update case, it won't get raised if there's no OTP returned
(unless options[:update])

···

On Thu, Feb 11, 2016 at 01:08:13PM +0100, Daniel Helgenberger wrote: > On 10.02.2016 18:15, Stephen Benjamin wrote: > > On Wed, Feb 10, 2016 at 10:56:48AM +0100, Daniel Helgenberger wrote: > >> On 10.02.2016 00:44, Stephen Benjamin wrote: > >>> On Tue, Feb 09, 2016 at 02:38:37PM +0100, Daniel Helgenberger wrote:

Further, I think best to break the task up and get the provider working
as a fist step and integrate the it later in foreman.

I know little on your plans on the matter, I hope to discuss this
further here.

No specific plans. A couple people have asked and made some attempts but
no one’s opened an actual PR yet. I’d really like to this, it’s a very
often requested feature.

Please advise, comment on the following thoughts I had:

Extend realm_setup with a case for ‘activedirectory’

add the provider in modules/realm/activedirectoy.rb

add a test and a settings.d example

Yup, this sounds right as the initial steps.
I think I can just use the new provider on foreman’s side once the
realm_setup handles this?

Yes, it would Just Work as long as you don’t need any changes on the
Foreman side to handle some special case for active directory.

I would guess we should make sure the templates handle automatic
registration fine. There’s some bits already there, but it’s never been
used:

https://github.com/theforeman/community-templates/blob/develop/kickstart/provision_rhel.erb#L54
In case of windows, we need to leverage this on provision template also;
the realm provider is not necessary to do that. I have a working foreman
/ windows; and use this, a user with creds to join the domain:

community-templates/waik/waik_userdata_joinDomain.ps1.erb at wimaging-ng · helge000/community-templates · GitHub

If the OTP works, it would be even better.

Provider:
I think about implementing an execute method as done in ms_native dhcp,
dnscmd. The main issue is how to proceed with this method, I see two
options:

Run local powershell with AD cmdlets using open3 as done in the other
ms providers. These would basically be {New,Remove,Get}-ADComputer piped
to ConvertTo-Json.

Use WinRM [1]. For starters I would try to keep it simple and only
support localhost endpoints; later on implementing SSL direct connections.

Settings:

Should we let the user define a domain in the settings?

Should we let the user define the Default Computer OU?

Alternatively we could the above figure it out in initialize, running
Get-ADDomain -Current LocalComputer; though setting this is probably the
better idea.

For WinRM, some settings more settings would be needed:

:winrm_endpoint: = ‘http://localhost:5985/wsman’
:winrm_user: administrator@domain.com
:winrm_password: password

I much prefer option 2 - and currently see the following issues and
benefits:

Downsides:

Adding a new gem

Users would need to enable remote management. In most practical cases
this would be enabled already and is fairly simple compared to
installing smart-proxy on windows.

Benefits:

I think all MS smart-proxy providers could benefit from WinRM at some
point; the idea here is a Linux smart proxy can handle dnscmd; netshell
or a more modern powershell implementation directly. The realm provider
could be the first of this kind; maybe call it ms_rm_dns; ms_rm_dhcp etc.

[1] GitHub - WinRb/WinRM: Ruby library for Windows Remote Management

There’s an open issue for this where you can see some of the discussions
we had before, , including
someone who made an initial attempt using ‘mskutil’.
Thanks! I missed this.

I think it is ok to hijack the ticket for the PR?

Definitely

When this was originally investgated, we considered ‘adcli’, and there’s
some examples of how it’s used here:
Features/AnacondaRealmIntegration - Fedora Project Wiki

Regardless we would have some additional dependency to handle AD, so a
new gem is no problem itself.
Cool, I would try submit the PR using winRm then.

I’m no AD guru to say what’s best. I think it’d be ideal if we could get
it supported to run remotely eventually as I guess many users would
prefer to run the smart proxy on *nix. But Smart Proxy on windows is
still possible AFAIK.
My way of thought was to keep the existing providers and migrate them to
powershell and maybe even WinRM on the long run. Though I admit this is
more a feeling than hard evide: Microsoft is deprecating tools like
netsh, adcli, dnscmd in favor for powershell.

Well, adcli isn’t from microsoft, and I would think they’re not going to
get rid of how it’s communicating with AD?
Indeed! Sorry, I mixed that up

My main point was this makes it more difficult for *nix admins to make
them run a smart proxy on top of windows to get the AD integration,
since there are tools that work in the *nix space. But, we can have that
discussion when there’s some code to look at to understand what you’re
proposing when you say powershell.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering

–
Daniel Helgenberger (helge000)
daniel@helgenberger.net

–
You received this message because you are subscribed to the Google Groups “foreman-dev” group.
To unsubscribe from this group and stop receiving emails from it, send an email to foreman-dev+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

–
Best Regards,

Stephen Benjamin
Red Hat Engineering