20:00:00 <nitzmahone> #startmeeting Ansible Windows Working Group
20:00:00 <zodbot> Meeting started Tue Mar 29 20:00:00 2022 UTC.
20:00:00 <zodbot> This meeting is logged and archived in a public location.
20:00:00 <zodbot> The chair is nitzmahone. Information about MeetBot at https://fedoraproject.org/wiki/Zodbot#Meeting_Functions.
20:00:00 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
20:00:00 <zodbot> The meeting name has been set to 'ansible_windows_working_group'
20:00:07 <nitzmahone> #chair jborean93
20:00:07 <zodbot> Current chairs: jborean93 nitzmahone
20:00:14 <nitzmahone> #info agenda https://github.com/ansible/community/issues/644
20:00:14 <jborean93> hey
20:00:24 <briantist> hey!
20:00:58 <nitzmahone> nothing on the agenda, so
20:01:02 <nitzmahone> #topic open floor
20:01:36 <briantist> I finally got my own (barely) working form of a CCG plugin for domain-less windows container hosts w/ gMSA identities
20:01:37 <briantist> https://github.com/briantist/CcgVault
20:01:45 <briantist> (nothing to read there at the moment)
20:02:22 <jborean93> nice
20:02:33 <jborean93> barely working sounds like it's ready for production :)
20:02:34 <briantist> struggled for a long time as to why the prototype jborean93 linked me to was working and mine didn't, only to find that the interface GUID was not supposed to be generated by the developer (unlike the other 3), and was instead a "well-known" type of ID
20:02:51 <briantist> there are 0 google results for that GUID btw :-/
20:02:57 <nitzmahone> Heh, been there before :D
20:03:53 <jborean93> I've been slowly banging my head against the wall with the new pypsrp CI. Slowly making progress and fixing up the problems that pop up there
20:04:17 <nitzmahone> The one thing I've really enjoyed about the last several years being mostly open-source is that when something isn't behaving the way I like, I can at least go take it apart without resorting to disassemblers et al
20:04:43 <briantist> been seeing a lot of commits there, any issues you're hitting specifically jborean93 ?
20:05:12 <briantist> nitzmahone: yeah.. this was one of those cases where I couldn't do that, the only known plugin the AKS one which is not open source, and neither is the CCG itself
20:05:47 <jborean93> Just general CI teething problems. I've got 3 main ones I need to fix up; 1. figure out why ssh is rejecting the key, 2. why Linux is sometimes hanging/failing on 2 or 3 tests, 3. why WSMan is slow slow on the Windows side
20:06:30 <jborean93> ngrok can't help with 1 as it sets it's own ssh server up, might have to see how to change the port it uses
20:06:50 <jborean93> 3 also wasn't happening when I was using ngrok to test it all out so that's going to be a fun one to play with
20:07:09 <briantist> ugggghh intermittent issues
20:07:10 <jborean93> 2 is annoying because of all the times I'm testing it locally I've never seen that behaviour but I'll eventually figure it out
20:08:33 <briantist> I have a really stupid issue on my laptop right now, we have two AD domains, and I can't do DNS requests to one of those domains from my laptop on UDP (but it works over TCP), but all other UDP DNS requests including ones to the other domain work fine :psyduck:
20:08:53 <briantist> network team tells me the packets are not hitting their firewall so seems to not be leaving my machine..
20:09:08 <briantist> I'm at the point of about to run wireshark so you can tell it's a fun one...
20:09:55 <nitzmahone> bleh
20:10:18 <jborean93> DNS is always so much fun
20:10:45 <briantist> to figure out that this was even happening, it was after spending days trying to figure out why I couldn't run this set of molecule tests
20:10:46 <jborean93> Doesn't help when it's also being fired in some blackbox code
20:11:03 <briantist> because they use the `dig` lookup to look up records directly on that domain's DCs.......
20:11:51 <briantist> so all the while I keep thinking there's something else wrong, descending further into madness, only to eventually find this weird situation
20:12:15 <nitzmahone> so WSL's also in the mix then- oy
20:12:20 <nitzmahone> Is that WSL1 or WSL2?
20:12:50 <briantist> it is (WSL2), but I confirmed the DNS issues are machine wide, nslookup in native windows confirmed UDP fails right away to those DCs, and TCP lookups workl
20:13:47 <nitzmahone> If this ends up being one of those things where Defender or $av_malware_fun is blackholing the traffic... ugh
20:14:20 <jborean93> Probably IPv6 related :)
20:14:39 <jborean93> I've had fun DNS problems resolved by disabling the IPv6 adapter
20:14:46 <briantist> yeah, security software is garbage..
20:15:25 <briantist> oh no... I hope it's not somehow IPv6 related... don't think it would be...
20:16:28 <jborean93> Simple to try out but yea I doubt it is
20:16:58 <jborean93> My problems with IPv6 were my own fault, it had a higher priority and would use that over IPv4 which is where I defined the DNS servers
20:17:57 <briantist> so something actually on topic you both might want to comment on, in the #ansible-aws channel, was someone asking about where to put a module that configures Amazon FSx for Windows
20:18:20 <briantist> that service is basically Windows File Shares/DFS as a service, and underlying it is a real Windows machine, which you can domain join and everything
20:18:55 <briantist> and so the way Amazon allows configuring it is via JEA, connecting to a specific Configuration profile
20:19:16 <briantist> so it's sort of Amazon specific, but doesn't use their AWS REST API or anything like that
20:19:21 <nitzmahone> Sounds like maybe it should be an action plugin
20:19:41 <jborean93> So it would have to be a Python module using pypsrp to send the specific commands or a PowerShell module that runs on a Windows host to do that through PowerShell natively
20:19:56 <jborean93> Weird they would tie themselves in through PSRP that way, it's a very MS thing to do
20:19:57 <nitzmahone> (and somewhere far away from any capital-s-supported collection until it's stable :D )
20:20:09 <briantist> they seem to already have the latter (a pwoershell module)
20:20:37 <briantist> I think the choice of JEA was a good one, not wanting to give customers direct full admin on the underlying host
20:21:02 <jborean93> except that WinRM seems to be at a dead end for Windows
20:21:17 <jborean93> Or at least there is no interest in making it work nicely cross platform as a client
20:21:36 <briantist> nitzmahone: I had a working way to connect to JEA endpoints with a very slightly modified `psrp` plugin; the ability to connect is already there, it just needed a way to run a command instead of use wrappers and push module code. Could be done as is with `psrp` and `raw`
20:21:47 <briantist> jborean93: yeah that's a shame
20:22:21 <jborean93> At least from a plugin point of view if you want to do it from localhost to configure the remote instance then either an action plugin or module that runs on localhost makes more sense
20:22:30 <jborean93> No need for the middle man Windows instance
20:23:06 <briantist> right, action plugin with pypsrp for the connection could be quite nice
20:23:28 <jborean93> Definitely getting into network module territory there :)
20:23:29 <briantist> could probably even re-use a `psrp` connection plugin + `raw` sort of thing in the action itself
20:23:54 <nitzmahone> the connection plugin's a lot of overhead if you don't need to transfer/run code
20:24:21 <nitzmahone> (and a very limiting box to put yourself in to boot :D )
20:24:40 <briantist> I suppose, I like not reinventing wheels though..
20:24:58 <briantist> but yeah maybe it's better not to use the connection for this case
20:25:12 <jborean93> I feel like it will be more difficult trying to shoehorn in the new connection plugin rather than calling pypsrp itself
20:25:53 <briantist> I didn't mean new connection plugin, existing `psrp` can already connect to a configuration profile
20:26:16 <nitzmahone> yeah, was gonna say I thought psrp + raw already worked with JEA
20:26:21 <briantist> yup it does
20:26:23 <jborean93> yea sorry I meant having the action plugin configure the "new" psrp connection plugin class
20:26:38 <briantist> I see, right
20:27:08 <nitzmahone> So you could sorta use it directly from the action if you don't need anything more than the very limited primitives available on ConnectionBase
20:28:06 <briantist> that's what I was thinking initially.. but you both may be right that it's less trouble to use pypsrp directly
20:28:56 <jborean93> The part I'm worried about is whether a "script" can run on a PSRP endpoint rather than doing `add_command("My-Cmdlet")....` as needed
20:29:49 <jborean93> Exchange uses JEA and IIRC you need to run the commands directly rather than using the freeform script parameters
20:30:53 <briantist> ahhh right, that was one of the things I needed to change in my modified version
20:31:16 <briantist> add_script won't work if it's locked down sufficienty, only add_command
20:31:29 <briantist> it's coming back to me now.. it worked with `raw` only with that change
20:31:32 <briantist> I think...
20:31:37 <nitzmahone> that would make sense
20:32:24 <jborean93> JEA is a fun world
20:32:33 <jborean93> They are trying to bring it through the SSH based PSRemoting as well
20:32:38 <jborean93> No idea what that would look like though
20:32:53 <briantist> interesting.. got any links about that?
20:33:18 <briantist> hadn't heard about them adding it to SSH (not that I ehear much about using SSH for psremoting at all)
20:33:47 <jborean93> https://devblogs.microsoft.com/powershell/powershell-and-openssh-team-investments-for-2022/#local-sessionconfiguration-support
20:34:04 <jborean93> I assume it's going to be define a new subsystem and have it call `pwsh -SessionConfiguration ....`
20:34:14 <briantist> ty!
20:34:16 <nitzmahone> `Eventually we'll implement a general hosting model, similar to WinRM, to support endpoint configuration and JEA.` (from https://docs.microsoft.com/en-us/powershell/scripting/learn/remoting/ssh-remoting-in-powershell-core?view=powershell-7.2#overview)
20:35:00 <briantist> ahhh the virtual or group managed account support won't be supported
20:35:09 <briantist> that's kind of the key to making JEA useful imo
20:35:37 <briantist> custom connectioninfo seems interesting though
20:35:42 <nitzmahone> meh, just need Ansible to manage your service accounts :D
20:36:20 <briantist> I wrote DSC to manage gMSAs and use those in Asnible 🤪
20:36:32 <briantist> but managing them isn't the issue
20:37:06 <briantist> being to connect to a session configuration, and run a limited set of commands, who actually run as a privileged virtual account or service account, is where th real value is
20:37:27 <briantist> safe delegation of privileged operations
20:37:35 <jborean93> I still feel having a user connect to a box but only run a certain set of commands under their privileges is still a good thing
20:38:06 <jborean93> But yea not as extensible as what you are saying
20:38:18 <briantist> Right it is a good thing, but far less useful
20:38:43 <briantist> if it were easier to delegate permissions and ACLs in a limited scoped way without pulling your hair out, that would be a different story
20:39:13 <briantist> there are too many things in Windows still where it's just impossible or severely tedious and undocumented
20:39:46 <jborean93> I think the trouble with adding support for gMSA/virtual accounts is that at the point in which the pwsh process is spawned it's running as the connection user which won't necessarily have the permissions to do that work
20:40:11 <nitzmahone> Yeah, the "just make the service account admin" mindset is still pretty pervasive in Windows-land from ISVs
20:40:16 <jborean93> Would require some integration with sshd and PowerShell to expose safely, even then I would be cautious of any security bugs
20:41:05 <briantist> right, but it's already done for winrm/psremoting, wonder why it would be less secure with ssh
20:41:35 <jborean93> At least with WinRM it's the WinRM service that knows about configuration endpoints and how to spawn it as a new process
20:41:44 <briantist> right
20:41:53 <jborean93> With SSH all it sees is a subsystem entry to start a new process as the connection user
20:42:22 <jborean93> To do it safely it would need to have a way to figure out this is a subsystem request for a PowerShell JEA session so read this config somewhere and spawn the new process accordingly
20:42:34 <briantist> yeah I guess that would be a radical shift
20:42:43 <jborean93> It is possible but would require more custom integration in the Windows sshd service focused entirely on PowerShell only
20:43:19 <jborean93> Plus it doesn't really know whether the subsystem request is for PowerShell or some other service. It could technically go by name but that's entirely user configurable
20:43:39 <briantist> well the only thing the requestor passes is the configuration name
20:44:02 <briantist> it's possible to extend that such that configurations could be for powershell, or <other> with different properties
20:44:05 <jborean93> So would require more PowerShell specific features on the service side to say "Hey this is a JEA subsystem, read this config"
20:44:35 <jborean93> Yea definitely possible, just not something that's universal with ssh which is how things work today
20:44:40 <briantist> it could be that sshd only knows how to read a config name and send a request to a dfifferent service for launching, I dunno
20:44:46 <briantist> yeah that's def true
20:44:49 <jborean93> You never know the same team who manages PowerShell manage the Win32 ssh fork
20:44:50 <briantist> it would be a departure
20:44:58 <briantist> hm
20:47:47 <briantist> well nothing else from me.. I'll get back my wireshark adventures 😩
20:48:00 <nitzmahone> Good luck!
20:48:12 <nitzmahone> "Have fun stormin' the router!"
20:48:25 <nitzmahone> Til next week, then...
20:48:28 <nitzmahone> #endmeeting