20:00:04 #startmeeting Ansible Windows Working Group 20:00:04 Meeting started Tue Mar 2 20:00:04 2021 UTC. 20:00:04 This meeting is logged and archived in a public location. 20:00:04 The chair is jborean93. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:04 Useful Commands: #action #agreed #halp #info #idea #link #topic. 20:00:04 The meeting name has been set to 'ansible_windows_working_group' 20:00:11 :O 20:00:14 👋 20:00:16 my watch is 4 seconds off 20:00:17 hey 20:00:17 boo 20:00:21 #chair nitzmahone 20:00:21 Current chairs: jborean93 nitzmahone 20:00:43 I even had it ready to go, but got a slack ping 15s before :( 20:00:58 it's a sad day for us all 20:01:09 #topic openfloor 20:01:21 nothing on the agenda, anything we would like to discuss 20:02:27 there was someone who was using your OpenSSH role, may have found a bug in `win_acl` (or something it depends on) 20:02:45 where using a non-qualified username on a DC fails to resolve the name 20:02:46 yea I saw the issue for that, it's a tricky scenario unfortunately 20:03:42 I figured as much :) but if nothing else, documenting the need to qualify names on a DC would be good for `win_acl` and whatever else might use the underlying SID translation 20:03:49 I think I just need to fix up the role to have the domain name part but not sure if we can really fix up win_acl 20:04:50 If there is anything you would like me to test, or if you require any more information, please let me know. I'd be happy to assist. 20:05:08 sure thing, thanks for the bug report. I'll hopefully have something by the end of the week or sometime next week 20:05:43 You're very welcome, and thanks. 20:06:21 I've been mostly trying to work on the proxy work for the new pypsrp changes but have been side tracked as I go along. Created a playbook that builds an environment to test all these niche WSMan scenarios because I keep on forgetting how to set them up https://github.com/jborean93/wsman-environment 20:06:51 jborean93: wanted to ask , what were you working on the other day that you ran into using `Register-PSSession` with ansible? was it that stuff? ^ 20:07:09 yea, was creating a JEA endpoint to test out `ansible_psrp_configuration_name` 20:07:30 I've used that param a bunch with JEA when I was working on all that 20:07:56 I only had to modify the `psrp` plugin slightly to get it to work against a JEA endpoint 20:08:14 still can't believe that the `-NoServiceRestart` does nothing 20:08:22 what did you have to change? 20:08:34 I mean all the other module wrapper stuff didn't work without modification, but to just get `raw:` working it wasn't much at all 20:08:49 ahh you are talking about an actual constrained one 20:09:02 I'll look back and find something concrete, but IIRC it was mostly just to stop using `add_script` (since that's not supported n very restricted runspaces) 20:09:06 ah yeah exactly 20:09:19 the only thing being added by script was some return code stuff 20:09:46 everything else as far as connecting to named runspaces, I never found any issue with 20:10:13 fair enough, I'm just wanting to test that it actually connects to the registered configuration and not proper segmented JEA 20:10:35 yeah makes sense 20:10:47 heh, yeah, getting general modules working under constrained JEA, at least the same way they do today, will probably never be possible 20:10:58 I did get it working :) 20:11:10 *the same way they do today*? 20:11:10 it's just, I started that project before the collection split... 20:12:01 not exactly the same way of course, but kinda sorta basically, (as in you didn't need to change the playbook side of things) but it of course it involves having the modules available on the target already 20:12:03 (ie, zero footprint) 20:12:08 yeah 20:12:21 definitely not zero footprint, there's now way to do that that doesn't break the security model 20:12:26 yeah 20:13:34 but I had some automation that could take the ansible windows content, package it as a powershell module, with the ansible modules becoming functions, and the options becoming parameters, and that let you use purely JEA to define which ansible modules you're allowed to run and with which params, etc. 20:14:02 It still needs curation, if youlet someone run win_shell or win_dsc, they can do anything 20:14:21 probably still possible with collections just needs more tooling to do that packaging 20:15:14 yeah exactly.. my idea was around a way to package the ansible content yourself (as an admin) and distribute as needed (as a powershell module), and to configure sensible JEA policies. Even had ideas for version matching, etc... but with collections, the problem does grow quite a bit 20:15:20 I was wanting to simplify the LDAPS setup for AD as right now you need to copy registry keys to place the cert into the NTDS\My store. When I get time it's not as difficult to just open the cert store for a service https://gist.github.com/jborean93/9758823e0546abf561b07d380bc60c53. Probably something I can add to `win_certificate_store` 20:15:21 just haven't been able to get back into it 20:15:28 Yeah, you'd have to have out-of-band distribution, and the execution side would have to limit itself to constrained-language mode or allow-listed cmdlets with subprocesses 20:16:19 basically the exec wrapper would almost completely go away in that case and you're just running modules like cmdlets 20:16:26 That's the nice thing is the server admin can decide which connecting windows users have which access to the configuration profiles 20:16:33 yeah that's exactly how I was doing it 20:17:03 it was a little inefficient as written because I couldn;t easily work around the module and util packaging, I could only reqrite it and throw it away, but it worked 20:17:23 That part should become more possible eventually ;) 20:17:54 yeah still think it'd be an interestin endeavor.. but any free time I have now is wrapped up in `community.hashi_vault` 20:18:08 welcome to the wonderful time sink :) 20:19:45 jborean93: that's cool, I remember setting up an HAProxy LDAPS load balancer against AD, and having to add certs into that store 20:20:37 that was years ago, but recently we're doing something similar at my current job, and opted instead to terminate TLS at the load balancer (AWS NLB) to avoid the whole thing 20:21:06 that looks like a great addition to `win_certificate_store` though, super useful 20:21:39 hopefully will get to it by the next release, shouldn't be too hard to integrate 20:21:54 Server 2022 is now an official preview https://cloudblogs.microsoft.com/windowsserver/2021/03/02/announcing-windows-server-2022-now-in-preview/. TLS 1.3 support is probably problematic for CredSSP and CBT support so something we need to look out for 20:22:34 woah! 20:23:57 I know I had trouble with CredSSP over TLS 1.3 when trying to integrate it in pyspnego so requests-credssp is probably also affected 20:24:24 I'm honestly not sure what CBT looks like for 1.3 as well, I know there's a draft hanging around somewhere and the current method we use for TLS 1.2 won't work properly 20:25:02 it's just never been an issue because on the newest Windows 10 builds supported it on the server side schannel so it's not something we ever really came across in the wild 20:25:36 ah that sounds sticky 20:27:54 I wonder when MS decides to backport TLS 1.3 to older versions like they did with 1.2 20:30:18 at least in newer .net, it defaults to being able to use new protocols like that right? 20:30:18 anywho that's all the updates I really had 20:30:37 I believe so, or at least hope so 20:30:45 that whole opt into TLS 1.2 is just a farce 20:30:49 bleh, even TLS1.2 is such a mess 20:30:52 exactly 20:31:07 (not the protocol, just the way it doesn't work out of the box) 20:31:33 yeah it's so annoying... before `PowerShellGet 1.6.0` it was awful.. because they didn't do it either, and I couldn't connect repositories, yuck 20:31:51 PSGet is just aweful in general, hoping that 3.0.0 fixes a lot of their problems 20:31:57 I doubt it will straight away though 20:32:32 TLS 1.3 is an interesting protocol, it reports as 1.2 in the hello packet and it's only an extension where you can actually denote it supports 1.3 20:32:33 yeah.. it looks like it'll be good, but I'm also not looking forward to trying to transition, after finally getting everything sorta working on 2.x.x 20:32:43 (^ that's re: psget) 20:32:49 * nitzmahone wonders if they'll even turn on TLS1.3 for the wsman endpoints by default 20:33:06 if you enable it in schannel I'm sure it will just automatically use it 20:33:21 so I'm assuming server 2022 will support it out of the box 20:33:31 It sounds like http.sys has it enabled by default, but I wonder if the default PS endpoints will be configured for backcompat or security 20:34:03 PS itself wouldn't control this would it. This sits on the WSMan layer 20:34:29 Hopefully this also means the clients are 1.3-aware, but yeah, it's how the older OSs deal with it that makes me most nervous 20:34:42 Oh, the CredSSP part, yeah 20:35:07 Although there are probably client knobs for that ... hard to say. 20:35:41 yea I'm not sure, there's a lot of moving parts and I'm sure things like CredSSP and CBT won't work in pywinrm if it's talking to a TLS 1.3 and says it supported 1.3 20:35:58 But I do have a fix for the former, the latter I've never looked into too deeply 20:36:25 maybe I'll create a PR for pywinrm to use the WSMan httpx stuff I'm working on so the codebase is unified 20:37:49 * nitzmahone ducks to another meeting- TTYL! 20:38:10 enjoy 20:38:19 briantist anything else you would like to talk about? 20:38:21 same, I forgot I have to conduct an interview in a few mins! bye all 20:38:26 nope all good, thanks! 20:39:01 awesome, enjoy 20:39:03 #endmeeting