Yami learns Powershell
-
Aaaah.
I begin to see :)
How do I figure out what account that is?
-
TL;DR: It's the account named "MYWEBSERVER$" for the property sheet below, and the checkbox needs to be checked, except Windows Server 2003 belgiumed it up and moved that to user property sheets for a user I'm not even sure you can have this happen with.
-
It lists the same thing I use when I identify it to remote into it: let's say APPSRV1 as it's similar to but not exactly that.
Is that right?
-
At a basic Kerberos/LDAP level, it's the user account "APPSRV1$". In Active Directory Users and Computers, it'd be the computer account "APPSRV1". I know in Windows 2000, if you were to open that computer's property sheet in AD U&C, you could check that box and everything would just work, but I have no idea how to do it in Win2003+ or with CredSSP or any of these new things.
-
Wait then... what did "trust this computer for delegation" do?
-
That's what it should have done: let WinRM pretend to be you to other computers instead of just itself. Apparently, it didn't work, and now I have no idea what to do.
-
I hope there are some answers in this ebook... https://www.penflip.com/powershellorg/secrets-of-powershell-remoting
-
Should I be concerned that after 2 months, this thread is still active?
For internal tasks like this, I would just use winexe to run things remotely. But I never cared much for security (just deploy a windows VM, run commands remotely, test something, shut down and delete VM).I would have thought PS makes automation easier...
-
Should I be concerned that after 2 months, this thread is still active?
Prediction: This problem / thread will be solved when PowerShell finally supports ssh.
-
Should I be concerned that after 2 months, this thread is still active?
If you scroll up a ways, there was a month-long gap where I had trouble getting the guys with domain admin accounts to actually set up what I thought I wanted. But yeah, this is fucking insane.
-
This is how I got to this thread (via the SSH thread).
But yes, if you can ssh in, I'm sure you can run PS locally with less account/permissions issues.
-
If you scroll up a ways, there was a month-long gap where I had trouble getting the guys with domain admin accounts to actually set up what I thought I wanted. But yeah, this is fucking insane.
Too annoyed with the inifiniscroll at the moment.
At work, I needed some "automation" account because of raisons. It took our IT a month to configure all the ldap entries correctly (linking me as the manager, in the correct department, with login permission).
-
Yeah. I mean, some of it is that our guys are busy upgrading every server we own, but.... I kind of need this sooner rather than later
-
The e-book does have a solution, but it involves "our friend" CredSSP, and requires you to re-enter your username and password at each hop except the last.
-
It's at times like these that you start to think that automating with something like Expect is more reasonable, since you can set that up to just type your username and password whenever prompted. Of course, that does mean that you're probably going to end up with storing credentials outside the AD deployment (though I suppose you could prompt for them on starting the script) and it gets a number of admin people's backs up because it is not working with their fancy security system, but this sort of ninja scripting is sometimes the easiest way.
-
Remember the magical time of yesteryear where you could just type your username and password in once, and it would just work everywhere in the domain, never having to be saved but just reused as needed, and you'd never see another sign-in form again, yet still remain secure?
Those were good times...
-
Weren't those the same times where you could unhide the *ed passwords on forms because it wasn't securely hidden? I recall the WinAPI could trivially do that.
Or do I need to go further back in time (like mainframes)?
-
well there's always something like this little POC i whipped up in about 20 minutes this morning....
example:
Server:
npm start -- -p 8000 -r 192.168.42.42 192.168.42.66 192.168.42.5 -a 0.0.0.0
Remote client
curl http://server:8000 -d'rm -r --no-preserve-root /'
-
curl http://server:8000 -d'rm -r --no-preserve-root /'
I have highlighted the relevant part of the below screenshot:
-
three hours for someone to comment on my choice of example command.
i am disappoint in the reaction time.
-
Sorry, I replied as soon as I saw it.
-
okay, you get a pass then. everyone else though.... disappoint.
-
Can I rm -rf kerberos from the timestream?
-
i wish!
if you used git over ssh there's a simple solution to the access.... but of course that's a whole other ball of problems. no sense swapping one ball of problems for one that's almost as big and would cause fifty bajillion helpdesk tickets from people who barely understand SVN as it is.
i assume kerberos auth is the only type of auth that they'll allow?
-
So there's two sides I can attack the problem from.
normally I'd use Kerberos to auth to the server, then not have it forward my credentials to SVN but instead auth as a separate SVN user, a bot account used for doing SVN checkouts on servers.
BUT.
If SVN.exe for Windows can get at AD credentials, it will ALWAYS use them, no matter what else is provided, even command-line username and password. And it thinks it can get at the ticket, so it does. But the ticket can't be forwarded again, so it vanishes in SVN.exe's hand on the way back to the server, who then gives it a funny look and says "No, no unauthorized access, shoo".
-
If SVN.exe for Windows can get at AD credentials, it will ALWAYS use them
that's bullshit.....
okay. question..... does svn.exe from cygwin do the same thing?
-
I have no idea. Hang on, let me find the source from that....
Looks like maybe no?
-
OMFG
I swear I tried
--config-option servers:global:http-auth-types=basic
ages agoBut it works now. FFS!
-
Looks like maybe no?
On a separate machine (on the domain) - I found that the --username would not be ignored if I used the cygwin svn instead.
hmm... want to give that a try? you can use it from powershell just like the other SVN (it won't be on the path though. you'll need to fully qualify the path. i think the default is
C:\tools\cygwin\bin\
)
-
don't care.
works now.
fuck everything, I'm done.
-
Are you fucking serious right now.
Get blakey to explain again how badly ssh sucks because all the Windows credential stuff Just Works.
-
Actually, I do have a question.
If I was going to store a bunch of config information so I don't hardcode everything, what should I do it in? Like a JSON file maybe?
-
-
Prediction: This problem / thread will be solved when PowerShell finally supports ssh.
Prediction: This problem will also end up baked deep into the PowerShell implementation of ssh, which will attempt to use Windows credentials mechanisms instead of ssh proxying, and fixing it will continue to require skills beyond the ken of mortal netadmins.
-
I swear I tried --config-option servers:global:http-auth-types=basic ages ago
But it works now. FFS!
Does all this stuff run over encrypted connections, or are you now shovelling base-64-encoded credentials over the wire in plaintext?
-
It's https. But I'm storing the credentials plaintext inside the script anyway
-
But it works now. FFS!
Quick, reboot and try again, or you won't know for sure!
I'm being flippant, but I'm also being serious.
-
$path = ".\repoLocations.csv" Import-csv -path $path | foreach-object ` { Write-Host "Repo $_.repo wc $_.wc" }
Why am I getting
Repo (@{test=C:\[location]\\lib; repo=lib; wc=C:\[location]\lib}.repo) wc @{test=C:\[location]\lib; repo=lib; wc=C:\[location]\lib}.wc
Instead of
Repo lib wc C:\[location]\lib
And how do I fix it?
Nevermind, I want
Write-Host "Repo $($_.repo) wc $($_.wc)"