Yami learns Powershell
-
$executable = "C:\Program Files\TortoiseSVN\bin\svn.exe"
$arguments = "https://[url redacted] C:\webfiles\inspections --username [redacted] --password [redacted] --no-auth-cache --non-interactive --trust-server-cert"& $executable $arguments
Something like that maybe? The nesting of quotes to get it to work is a nightmare, I'm pretty sure I did something like that to get around it.
Edit: Misread the error, you might want to break the arguments into their own variables individually instead.
-
Quote the URL?
Shouldn't be necessary. Unlike filenames, URLs mustn't contain spaces. (You have to encode them as
%20
or+
.)
-
I grow desparate:
-
I grow desparate:
At this point, I'm guessing that SVN not checking the user credentials in a way that's made available over PowerShell.
It's a hack, but you can always force your user to supply their username and password. Or you could use a worker account to perform the changes and store the credential information in a text file on the server that hosts the batch script.
$creds = Get-Credential $env::currentuser $pass = $creds.GetNetworkCredential().Password
-
you can always force your user to supply their username and password
The thing is, I was explicitly specifying a bot account that has permissions with the --username and --password flags, and it STILL didn't work! I even tried plugging in my AD credentials using those flags, and nothing.
I'm not going into all the details on SO though, I'm hoping someone can make the credential forwarding work, but it's bizarre at this point.
-
@rad131304 said:
you can always force your user to supply their username and password
The thing is, I was explicitly specifying a bot account that has permissions with the --username and --password flags, and it STILL didn't work! I even tried plugging in my AD credentials using those flags, and nothing.
I'm not going into all the details on SO though, I'm hoping someone can make the credential forwarding work, but it's bizarre at this point.
Well, I'm completely out of ideas at this point; it doesn't seem to make any sense. Did you try @Soy's recommendation of:
& $executable $arguments
-
I think so. Yesterday is kind of a blur.
-
I think so. Yesterday is kind of a blur.
I get that way too when I end up in the "monkey poo flinging" mode of trying to find fixes.
-
I'm going to note that
+
is only allowed in the query string part of the URL. In the path, it must be%20
-
you might need to accept the certificate of the SVN server from all the machines that command runs on?
I had this problem with MSBuild CI scripts some time ago, they specified --username and --password but this wasn't enough, even with --force-accept-cert (not the real flag, I can't remember what it is) it didnt work properly. Had to remote into the machine on the AD user that executes the command, execute the command and then permanently accept the cert when prompted.
possibly totally unrelated.
-
I can't remember what it is
You mean
--trust-server-cert
? Got that. I'm also using--no-auth-cache --non-interactive
when I use the username and password flag.Had to remote into the machine on the AD user that executes the command, execute the command and then permanently accept the cert when prompted.
Hrm. I can try.... nope, wasn't prompted.
-
OK, new plan!
I found Tortoise's svn logs, and they have no mention of any of the powershell activities. Where can I find a log for svn.exe?
-
Oh look, an answer!
I only had to offer a bounty to get it.
Basically apparently this is the "Kerberos double-hop" issue: while I can forward the credentials from machine A to machine B, I can't then pass machine A's credentials on to machine C, which is the SVN server. Because raisins.
-
-
Basically apparently this is the "Kerberos double-hop" issue
Credential delegation? Ugh. That's one of the biggest cans of worms in the whole of security, and it's all made worse by the way that some security people are working very hard to make it possible (in the most annoying way possible) and others are working very hard to make it impossible (in the most uninformative way possible). I hate dealing with this sort of thing.
-
Apparently, since 1.8, svn prefers Kerberos over.... everything, including supplied credentials. I'm not seeing a spec that indicates that, but it's clearly true, and I'm seeing that it prefers Kerberos over other methods like NTLM new for 1.8.
So how can I override that?
-
Have you seen this?
take a look at the accepted answer, about the protocol used.
-
That's not even the error I'm getting.
svn: E175013: Unable to connect to a repository at URL '[snipped]' + CategoryInfo : NotSpecified: (svn: E175013: U...eases/20150620':String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError svn: E175013: Access to '[snipped]' forbidden
Snipped is an https url.
-
suggests using an http instead of https URL. I don't know if that's feasible for you.
-
This is the issue I think:
-
--config-option servers:global:http-auth-types=basic;digest
didn't work :(
-
OKAY SO
The server guys finally got around to updating the server I'm using to test
It is now trusted for delegation to all services, Kerberos only.
AND YET.
svn: E175013: Unable to connect to a repository at URL '[snipped]' + CategoryInfo : NotSpecified: (svn: E175013: U...eases/20150718':String) [], RemoteException + FullyQualifiedErrorId : NativeCommandError svn: E175013: Access to '/svn/lib/branches/[snipped]' forbidden
Switch-server.js has some parameter checking then:
$branchName = $matches[0]; Write-Host "Switching $computerName to $branchName"; $Session = New-PSSession -ComputerName $computerName Invoke-Command -Session $Session -FilePath './switchAllRepositories.ps1' -ArgumentList $branchName; Remove-PSSession $Session;
SwitchAllRepositories.ps1 does:
Write-Host "Switching to branch $branchURL"; If(Test-Path "C:\webfiles\lib") { Write-Host "Switching lib" SwitchRepo "lib" ($branchURL) "C:\webfiles\lib"; } Function SwitchRepo ($repoName, $branchPath, $workingCopy) { $to = ("https://[snipped]/" + $repoName + $branchPath); Write-Host "to $to"; #debug $user = [Environment]::UserName Write-Host "as $user"; $exe = "C:\Program Files\TortoiseSVN\bin\svn.exe"; &$exe switch "$to" "$WorkingCopy" --no-auth-cache --non-interactive --trust-server-cert if ($process.ExitCode -ne 0) { #$wshell = New-Object -ComObject Wscript.Shell #$wshell.Popup("Error switching " + $repoName,0,"Done",0x1) Write-Host "Error detected!" } }
What now? U_U
-
Is there a reason not to take the error at face-value? Try logging on with the same account those scripts are running under and see if you can manually do the task.
-
It's my own account, and I know I can do it. I was getting this error when it was a kerberos double-hop issue, so I suspect it's the same issue not resolved.
As a refresher, the credentials are forwarded:
My laptop --> Web server (authorized as delegate now) --> SVN server
If I RDP into the central box, I can switch anything I like, I have rights on the SVN server to do so
-
Are you sure the path is pointing where you think it is? It's a relative path, maybe it's not anchored where you think it should be. Powershell might be misreporting "path doesn't exist" as "access denied", God knows I've seen that hundreds of times before.
Other than that, I'm out of ideas. Sorry.
-
Tried the exact path it's already pointing at, same error
@TwelveBaud is helping me in chat, I think this might be a credentials caching thing. They JUST authorized the server for delegation less than an hour ago. I bet you I have to log off and back on or something like that?
-
Kerberos tickets are a very tricky beast and I'm muddling my way through the sparse documentation and output from arcane CLI commands as best as I can. As far as I can determine, either Yami isn't being given a delegable ticket (meaning she has to personally log herself in at most one hop away from the SVN server) or the build server's computer account isn't trusted for delegation (meaning it can't be used as a hop and must be logged into personally).
Next step, reboot EVERYTHING and hope it works.
-
or the build server's computer account isn't trusted for delegation
That's what we've tried to fix :) We did https://technet.microsoft.com/en-us/library/cc738491(v=ws.10).aspx using the option "If in a Windows Server 2003 domain, on the Delegation tab, click Trust this computer for delegation to any service (Kerberos only), and then click OK."
A thought -- does ONE OF or BOTH OF the middle server and the user account need to be trusted?
-
The user's account needs to not have "Forbid delegating this user account" set, and one or both of the servers need to have "Trust this computer for delegation" set, provided that the service is running under "Network Service", "Local Service", or "SYSTEM". If it's running under another account, that account itself needs to be trusted for delegation. I think Remote PowerShell is a Network Service, but I'm not sure.
-
It's using my forwarded AD credentials so.... probably I need to be trusted then?
When I RDP, I log on with my AD credentials. I am running the script under my AD credentials as well. I pasted the powershell code I'm using, but as far as I can tell, it should connect using my AD credentials and run as my user, right?
-
You've logged in with your AD credentials to your local computer, which gives it a ticket to present to other computers to say that you are you, and that computer does things on your behalf. But, by default, the remote computer can't then take that ticket and present it to some other computer. The ticket allows it (FORWARDABLE), but the computer's own account does not (OK-AS-DELEGATE).
I have no idea how Remote PowerShell works, precisely, but whatever account it runs as before it gets your ticket needs to have Trusted for Delegation (OK-AS-DELEGATE) set.
-
So probably me then. Because probably the ticket is sent from my laptop to the middle server, and then handed right over to SVN. Right?
-
I'm thinking middle server. Except you said it was already trusted, so I have no idea.
Also, I found a thing that might be relevant, but might not. I'm at the very edge of my knowledge here.
-
oh look, some bullshit called cred-SSP.
Fucking yay. More shit I don't know.
-
Are you fucking serious right now.
-
All I know about CredSSP is that it was introduced in Windows Vista and was going to be the hottest thing ever, the best thing since replaceable GINAs and sliced bread and the invention of passwords.
I have no idea what it is, what it does, how it's better, or how to use it. But it's a thing on a major Hype Train℠.@Yamikuronue said:
Are you fucking serious right now.
... oh my.
-
replaceable GINA
Not to be confused with [this][1][2].
[2] content warning for @accalia
[1]: https://www.youtube.com/watch?v=byDiILrNbM4
-
Don't get me started about the NetWare GINA...that thing was responsible for The Boot Loops™ back when I was in HS...
(I eventually pinned it down to some sort of error handling gone horribly wrong with the aid of some 1337 reverse engineering skills, but can't quite recall just what error it was that was causing it to puke.)
-
He sent back:
So now I'm confused as to how I even make this work
-
[2] content warning for @accalia
wait, what now?
i'm at work now so not clicking through,m but what can i expect on the other side of that link when i check after work?
-
... and the Remote PowerShell service on middle server probably doesn't have a service account that lives on the domain, just the local service account which should already be Trusted for Delegation since you said the computer it lives on is Trusted for Delegation. Well damn...
-
I mean, it can. It can do whatever we want. I just need to know what that is.
I have some service accounts that have SVN access, but I'm running the powershell script as me, so how do I tell it to log in as the bot account? I guess with the -Credential switch? But in that case, is it even a double-hop anymore? Or is it? No, it'd have to be. So the bot account needs rights on the server as well as rights on the SVN server? I guess?
-
i'm at work now so not clicking through,m but what can i expect on the other side of that link when i check after work?
I'm just joking because you got all squeamish or something the last time I posted that link.
-
So now I'm confused as to how I even make this work
Well, it looks like registering an SPN on your account might help.
-
Yami's account isn't a service account though. The account that should get an SPN is the account WinRM is running under on middle server, before it impersonates Yami. And I have no idea which one that is. It's not Yami's account though; it "can't" be.
-
No, but that does mention that you can register an SPN for a user account. It even uses those words!
-
-
What account is magically involved here?
I sit at my desk and log in with my AD account. I open Powershell. I run the script. When does a service account take over?
-
I'm partial to that animation someone used recently of the badger running away, but we're kind of OT and maybe @abarker or someone should jeff these posts away.
-
You sit down and interactively log in at your desk. You open PowerShell and connect to middle server; Windows Remote Management, which is running under a service account on middle server, accepts the connection and begins impersonating you. You ask middle server to run the script, and now WinRM is trying to authenticate to the SVN server; it can't, because although it's impersonating you, the account it's actually running as -- the service account -- isn't trusted to delegate on your behalf.