>
>
> > 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