Scenario: Windows server in a AD domain hosting a Subversion repository using SVNSERVE only (no Apache), and not VisualSVN.
Objective: Authenticate users to the Subversion repository via SASL through GSSAPI to a Windows domain via Kerberos.
Frequent postings in multiple sites indicate users often dead-end in this configuration with a "Could not obtain list of SASL mechanisms." I've not seen any instance where this is actually running. Does anyone have this running?
I ask this question as a result of a 2011 posting in a Gentoo forum in which someone in precisely this scenario reviewed the relevant source tarballs and concluded that while, at one time, such a configuration probably worked, the files necessary for it are no longer in the source.
GEntoo forum discussion where poster claims svnserve+gssapi+sasl worked at one time, but no longer does.
Now, I don't assert that claim to be accurate, but I do know I am stuck at precisely the same point, and I've not yet seen any posts that claim "victory" over such a setup. If you have, please advise details!
Many thanks in advance.
I've just managed (after close to 30 hours of head scratching, compiling, and sourcecode-less debugging to get decent error codes) to get svnserve+SASL+GSSAPI to work! My setup is as follows:
AD server is Samba 4.1.0 on Debian 7.2 (built from source).
Subversion server is subversion 1.8.5 on Solaris Express (SunOS 5.11 snv_151a i86pc i386 i86pc). Built for x64 from source using native (Sun) SASL.
Client is Windows 7 x64 with TortoiseSVN 1.8.2 (x64 binary release) and Heimdal 1.5.1 (x64 binary from secure-endpoints).
As with anything involving Kerberos, you need to have forward and reverse DNS working smoothly, clocks synchronized, etc.
Steps on a Windows box with domain creds:
Create a "svnserve" user account (not computer account) for the Subversion server.
Run "ktpass -princ svn/server.domain.local#DOMAIN.LOCAL -mapuser DOMAIN.LOCAL\svnserve -crypto RC4-HMAC-NT -pass password -ptype KRB5_NT_PRINCIPAL -out svnserve.keytab". You do not want to turn on DES for this account or Windows 7 will refuse to authenticate to it. I turned it on earlier (following the recipes) and had to turn it off again to get it to work.
Steps for the Subversion server:
Set up /etc/krb5/krb5.conf
[libdefaults]
default_realm = DOMAIN.LOCAL
[realms]
DOMAIN.LOCAL = {
kdc = pdc.domain.local
admin_server = pdc.domain.local
}
[domain_realm]
.domain.local = DOMAIN.LOCAL
domain.local = DOMAIN.LOCAL
# Other defaults left as-is.
Set up repo/conf/svnserve.conf:
[general]
anon-access = none
authz-db = authz
realm = DOMAIN.LOCAL
[sasl]
use-sasl = true
min-encryption = 0
max-encryption = 256
Set up repo/conf/authz:
[aliases]
[groups]
[/]
* =
# Still investigating whether access to the server can be controlled through an AD group.
# Below is for user#DOMAIN.LOCAL, the realm appears to get lost.
user = rw
Set up /etc/sasl/svn.conf:
mech_list: GSSAPI
Drop svnserve.keytab in to /etc/krb5/krb5.keytab (keytab in the sasl configuration doesn't seem to do anything).
Start svnserve.
Steps for the client:
Install TortoiseSVN and Heimdal.
Edit C:\ProgramData\Kerberos\krb5.conf to be like /etc/krb5/krb5.conf on the Subversion server. There's some other defaults in there that I left alone.
Do a checkout, no password required!
One issue with this setup is that the svnserve process has to be able to read /etc/krb5/krb5.keytab, so permissions on that need to be wound back a bit. svnserve is going in to its own zone though so this isn't an issue for me. I also had mslsa_cc.dll crashing while testing things, but I haven't seen any crashes once I got everything sorted out.
With some wrangling, you might be able to get this working for svnserve on Windows as well. I tried MIT Kerberos on the Windows client but it crashed every time on startup so I gave up on it. You might have better luck.
Update: Figured out the crash issue - it's a bug in mslsa_cc.dll (similar to https://github.com/krb5/krb5/commit/7acb524f5aa00274771dbbfac19d2dd779aad409, which also gets it slightly wrong as nOutStringLen needs to be divided by 2 for the way that ANSIToUnicode is called). Binary patch on mslsa_cc.dll is:
Offset 0xB46: Change from FF 15 04 69 00 to D1 EE 0F 1F 40.
Offset 0xB5E: Change from 77 to EB.
After earning a "tumbleweed" badge for this unanswered question, and considerable additional research on my own, I've come to the conclusion that the subject combination for Subversion under Windows is, in fact, not possible under the current code base. I believe something in the SASL authentication layer is the problem here, with some source removed or significantly changed to "break" what did, I believe, work at one point.
My solution has been to add Apache to the mix with mod_auth_sspi, and while it does slow down the repository some, the authentication works perfectly. This appears to be the "fix" for the authentication requirement.
I have done authentication against AD with SASL+LDAP, but not SASL+GSSAPI, and with a small caveat: I have to use and run svnserve from Cygwin in Windows.
1) It was quite easy to get svnserve authenticate users via SASL+LDAP/AD in Linux ( I know the question is about svnserve in Windows, but bear with me ). The important part to get the authentication working against LDAP/AD is saslauthd, and test the authentication using testsaslauthd.
Using Ubuntu as an example:
1a) /etc/sasl2/svn.conf
pwcheck_method: saslauthd
mech_list: PLAIN
This tells subversion / svnserve to use saslauthd to do the authentication on its behalf.
1b) /etc/saslauthd.conf
ldap_servers: ldap://yourADserver.dept.org
ldap_search_base: DC=dept,DC=org
ldap_bind_dn: cn=bindaccount,dc=dept,dc=org
ldap_bind_pw: passwordOfbindaccount
ldap_deref: never
ldap_restart: yes
ldap_scope: sub
ldap_use_sasl: no
ldap_start_tls: no
ldap_version: 3
ldap_auth_method: bind
ldap_filter: sAMAccountName=%u
ldap_password_attr: userPassword
ldap_timeout: 10
ldap_cache_ttl: 5
ldap_cache_mem: 32768
1c) Do a test via testsaslauthd
testsaslauthd -u myusername -p mypassword
1d) If successful, then run saslauthd, and start svnserve. and use whatever svn client to test the authentication.
2) Problem is, there is no native port of Cyrus' saslauthd to Windows, and probably never will be. Answer is to use Cygwin, which has svnserve, testsaslauthd, and saslauthd.
Just repeat the above steps .. but the location of svn.conf may be different.
Related
I work as a React Developer for a company that chose to use IIS and SQL as their backend. The API calls don't use JWT but rather use Kerberos tickets.
This already presents an issue that I have to run chrome with --auth-server-whitelist="*" in order to get a ticket from kerberos at all. However, I am still unable to make API calls.
The best we can tell is my kerberos ticket (which can be viewed by issuing klist to terminal. The only difference between one that works on a PC and mine is that theirs has the ok-as-delegate flag and mine does not.
Surely there is a configuration issue on the backend or with IIS preventing my ticket from attaining this flag? Any help would be greatly appreciated.
After successfully running subversion for years on a Windows 2008 server, I recently moved to Windows 8.1, mainly because the machine does also serve videos to my home network (works fine) and because Windows 8 provides better energy saving on my platform than Windows 2008 server did. So far, so good.
Then I tried to re-install Subversion. I intend to use the built-in server application svnserve.exe. I downloaded the latest windows package, installed it (success), and configured a service (svnserve --service ...) which I can successfully start using the Windows Service Management Console. Port 80 is already taken by a different application, so I let subversion pick 3690, which is fine for me. I used netstat to confirm that svnserve.exe is bound to port TCP:3690, which is listed OK. Just to clear one potential roadblock I also disabled the Windows firewall.
Then I created a sample repository named "test" using svnadmin locally, success as well, a subversion file structure appeared on the harddisk.
Problems arise when I try to access the repository using my local browser (Firefox), an attempt to connect to URLs
http://127.0.0.1:3690[/svn|/svn/test]
all three give me the same cryptical response:
( success ( 2 2 ( ) ( edit-pipeline svndiff1 absent-entries commit-revprops depth log-revprops atomic-revprops partial-replay inherited-props ephemeral-txnprops file-revs-reverse ) ) )
Somehow I have expected a subversion GUI instead.
Connecting from a remote machine via browser reveals the same useless line of text.
Connecting from a remote machine using my usual Tortoise client gives the message:
Unable to connect to a repository at URL 'http://xxx.xxx.xxx.xxx:3690/svn/test
Error running context: The server unexpectedly closed the connection
I tried to add the --log-file option to svnserve, and indeed a log file appears once I start the service, but it is empty and it remains empty.
Trying to use svnserve -X instead of running it as a service reveals the exact same behavior.
Seems I am stuck. Anyone who has an idea what I can do to get that thing working?
Just to help out another beginner running into the same problem ... I finally found the problem: I simply used the wrong client, svnserve does not support web browsers. Using the Tortoise client, and providing the correct prefix (svn:127.0.0.1/...) was all I had to do.
The long version:
If one wants to work with the simple, reliable, fast, but plain-text and proprietary protocol based) svnserve service, he needs to use a proprietary client, like Tortoise, and the svn: prefix instead of http/https:, and no port, like
svn://mysvnserver/testrepo
If needed, one may even reconfigure svnservice to use authentication and encryption later. svnserve isn't supporting web browsers, if one tries to access svnserve using a web browser like I did he gehts the internals of the svn protocol dumped to the screen.
If one wants to use his web browser, http/https protocol, and niceties, like a user friendly browser based interface and some remote administration capabilities, he must not use svnserve, but install a web server service (like apache) and configure if for use with subversion.
So in the end my problem had nothing to do with Windows 8. It just has slipped from my mind that years ago I went the apache path, while now I decided that the built-in svnserve service was good enough for my needs.
Armin.
I am forced to use a visual-svn-server that is located in our windows domain. The problem is that it is super slow to use with windows client. Weird thing is that the same repository is very fast with linux client. The difference is like 3sec vs 90sec. I know somebody should fix the server, rather than me trying to fix the client, but i have no change of doing that.
So, to debug the problem I did some package capture with wireshark and it seems like windows, when doing 'svn up' (on up to date repository) does quite much ldap-negotiations before actually talking again with the actual svn-server. This takes time. Linux svn client when doing 'svn up' is not doing any ldap calls. The problem is not on my machine, but on all my colleagues windows clients too.
I tried forcing the svn client to 'basic' auth with configuration option http-auth-types (http://svnbook.red-bean.com/en/1.7/svn.advanced.confarea.html), but it didnt help. I figured that would be basic, no ldap, http-basic-auth. I am able to confirm that the setting is included, since setting it to 'digest' says that authentication method is not available. But even that takes about 60s, so my guess is that its doing the ldap-wacko stuff before trying to do the authentication.
The subversion client i am using is 1.8 serie from tortoise svn official build. I did try also slicksvn client and it did have the same problem. The svn versions shows ra_serf is handling the https requests and my repository is visual-svn server located at https://my_server_intra_dns_name/
When opening the address with browser, its again fast as it should, so problem should not be with dns or similar.
I am linux guy, so i am bit lost with windows, but does anybody have an idea wtf is going on here?
---- edit ----
I had also linux as guest operating system on the windows host, and inside that linux doing svn up was about 3s, compare that to native windows 'svn.exe up' that took over minute !
If a Windows machine has a limited connectivity to the Internet, then you may notice the delay when running Subversion client command's against a remote repository over HTTPS.
Using a traffic analyzer you can notice, that the delay happens when Windows attempts to access ctldl.windowsupdate.com and gets a timeout. Windows attempts to access ctldl.windowsupdate.com to check Certificate Trust List (i.e. Certificate Revocation List). With limited Internet connectivity, Windows may be unable to access it thus resulting in these delays.
If it's not your case, then I suggest contacting VisualSVN's support team for investigation.
In my case it was due ot Windows proxy settings - that you set in IE (I use TortoiseSVN client, and Visual SVN Server was set to use basic authentication).
After I've set up IE proxy settings accordinlgy (automatic for me, but for you it might be something different) initial delay was gone.
It helped even though the svn server is on local LAN and I have checked with Wireshark if the traffic goes over proxy. In Tortoise I have proxy disabled. Why it helped with my issue - no idea.
The initial delay I had was 11-13 seconds. Now next to none.
And I am not using ssh client.
Go to http(s) location of your SVN server using your browsers: IE, Fireofx, whatever, and if the response is quick then it is very possible that is an svn client problem, or due to some similar settings (similar to your browser settings).
For instance IE was slow (IE was set up for local connection only previously), Firefox (with proper proxy settings) was OK - and SVN server IS local (sounds like some sort of network/firewall/routing issue to me, but proxy settings helped me).
I´m following the steps outlined in Tim Davis´ blog for setting up GIT with copSSH on Windows (http://www.timdavis.com.au/git/setting-up-a-msysgit-server-with-copssh-on-windows/) but I´m having problems. I´ve gotten up to step 15 under the Installing Putty instructions but rather than getting a "Enter Login" message, I´m getting a "Network Error: Unable to connect to server" error.
I know that it could potentially be a myriad of things but I was wondering if by some miracle, someone could give me some ideas of what else I should check?
I´ve doublechecked the following:
IP address is correct
User has been added to copSSH
Key is stored in the specified user folder
Rule has been added to Firewall
(NOTE: We´re using a server on 1and1.com and the firewall rules allow us to specify a local port and a remote port. Have configured to local port 4837 and remote port to Any).
I tried to doublecheck if the SSH service is running but I don´t know what it´s called. I noted down the username and password from the copSSH setup but I haven´t seen anything remotely similar to SSH in the list of services.
Any help would be greatly appreciated!! I´ve never had to do something like this before so I´m a little lost.
Regards,
Kat
Troubleshooting
Are you specifying port 4837 in the Putty window?
I personally suggest using OpenSSH or SmartGit, not Putty... I've seen too many issues with it.
Also, I suspect your firewall configuration needs to be local port=Any and remote port=4837.
The 5 minute shortcut
This installer sets up a windows git server using CopSSH. It configures the firewall, the user accounts, and gives you a GUI for all the SSH and keys stuff. It costs $9, but it saves hours of configuration (it's a 5 minute, 3-step install). It has a self-contained Git install, so no conflicts should happen.
NOTE: I'm the webmaster of windowsgit.com. I got the project started after taking a good look at Davis' tutorial and thinking.... oh, ----! The CopSSH author and I collaborated to make the automate the process and reduce the number of frustration-related keyboard deaths :)
For some reason, no matter how I go about it, I cannot get TortoiseSVN to add an Author to Log Messages.
Currently we connect to a PC running svnserve, so it's not a file:// Address.
We have tried using svn://Username#svnAddress, svn://svnAddress
Even setting svn:keywords $Author: AuthorName$
I was under the impression that TortoiseSVN would use the windows login name, prior to upgrading from a file based repo, these did show.
Note: We are also connecting to a domain, if this would affect anything.
also, no hook scripts are in play and the svnserve.conf is default.
SVN Server is using SVN Version 1.5.1 (x86), Windows Server 2003.
Clients are using latest version of Tortoise, both x86 and x64.
Any help would be much appreciated.
Ohh and the SVN is used for source code, so it is programming related :) (well semi related anyway)
The svn: protocol, by default, does not do any authentication, and consequently, no identification of the remote user. As TortoiseSVN does not need to authenticate, no user gets logged.
The SVN keywords don't have to do much with this: If you put $Author$ in a file, it will expand to the author of the commit, rather than setting the user. In the keyword syntax, there is no support for colons.
So if you want to authenticate with svnserve, you should first set anon-access to none or read, to force an authentication prompt. You then need to setup a password database; svnserve has only support for CRAM-MD5 builtin. I recommend you try to get this working first, handing out new passwords to all users. Alternatively, you can try to setup SASL, which would then allow for NTLM authentication - provided you can get SASL to work on your system.
Yet alternatively, you can switch to a different protocol. If, by "PC", you mean "Windows", then I guess the ssh-based protocol is ruled out. That leaves http(s); it should be possible to set up Apache on Windows with NTLM authentication, so that the NTLM user appears as the svn author.