Firstly before I launch into the details of the issues I'm having, does anyone have a good knowledge of Cygwin installations on SBS 2003? Or on any Server 2003 installation for that matter?

I'm having a spot of bother with new domain accounts authenticating when logging in using an SFTP client.

I doubt we have many welsh speakers on here

At a risk of being whooshed... You know the Cygwin I was referring to was this, right?

Heh... finally some proper fucking geek chat!

The fact that it's Cygwin shouldn't really matter as it sounds a privs problem more than anything else.

What are the errors you are getting?

Righto, basicly, we have a need to transfer files by SFTP. Existing domain accounts can log in no problem at all. I can change the home path in \etc\passwd and those changes propagate on the next login via WinSCP.

I have created a few new domain accounts, none of which are able to log in via WinSCP. This is after renaming both \etc\group and \etc\passwd and then running mkgroup and mkpasswd to generate new files including the new domain accounts. From my understanding of how this works, the passwd file actually has nothing to do with the authentication process and the login is just as though it were to AD itself...

When logging in I can see the following error in the security logs of the SBS 2003 box:


What I notice from there, is that the Caller user name is the sshd_server account that is created on installation of Cygwin. I know that sshd_server has logon as a service rights as existing domain accounts can log in.

Well I knew it wasnt welsh You know my reply was this, right?

Hence my "At the risk of being whooshed..."

It wasn't that I knew, more hoped you were joking

Sorry, I've had a f*cker of a day and didn't get a chance to look into this.

I am guessing you have done some investigation into this, but the first thing I would ask is can those accounts you are trying to SFTP into log into the domain normally?

No bother Ric, all help is appreciated!

Aye, I've done all the investigating I can into the AD side of things, but not sure if there are Unix privelages need set independantly of the Windows environment.

All of the domain accounts can log in normally.

Well seeing as the error you are getting is from NT AUTHORITY\SYSTEM, then it suggests it's certainly hitting AD.

We've got Linux AD integration on our servers but unfotunately I wasn't directly involved so I don't know much about what's needed to be done.



There should be a 'Unix Attributes' tab when looking at user properties and you need to put things like uuid and username in there. If you find it, remember to enter all the usernames as lower case otherwise you'll get an error.

We've also got a user group that all the users need to be part of to get the necessary permissions in Linux.

Is Cygwin S like a Welsh Bob Malcolm?

Aye the login attempt hits AD and then falls on its arse. Any ideas? I'd like to take this opportunity to mention that I was nothing to do with the installation of Cygwin on our server and nothing to do with getting the existing accounts to function normally. The guy that did it all, appears to have vanished off the face of the Earth...

When logging in as the domain user normally, everything happens as I'd expect it to. When logging in via WinSCP, the message "Access denied" appears and prompts for the password again. Either it's rejecting the password stored in AD, or there's something odd going on with permissions and I've not assigned the relevant ones to the account.



In AD Users & Computers? Sounds like a fancy Unix integration you have. There's no tabs relating to Unix in our User Properties. Good idea about the group though... But I'm not convinced the guy that implemented our Cygwin installation was that clever...

That's where it is for us. We don't use SBS so I thought it might be hidden somewhere else, found this link which mentions a few options http://blog.scottlowe.org/2006/11/28/unix-...and-nispropdll/

Just VPN'd in and tried adsiedit.msc and found the unix settings (along with what looks like every other AD setting) in there. If it's an AD problem, you'll probably be able to spot it in here by comparing values

Hope that helps in some way

Cheers dude, I'll give that a whirl tomorrow and I'll let you know how I get on. I'm in Aberdeen all day today.

No joy I'm afraid. It's definitely not the same kind of thing that we have. There's no Unix tab in AD, and like I thought, there's no group for privelages...

Ric, you seem to know about Cygwin, have I done something wrong in configuring the new accounts?

This is the steps I've taken:

Account creation
Test log in on domain with new account
Rename \etc\group and \etc\passwd
Open Cygwin Bash Shell and run mkgroup and mkpasswd
Configured home paths for accounts that are currently functioning in \etc\passwd
Test login on existing accounts - Login via WinSCP successful.
Test login on new accounts - Login via WinSCP unsuccessful: Access Denied.

Reading through Cygwins manual, there appears to be something called NTSEC, that forms some sort of ACL for processes and files. Is there any way of listing an ACL for any given user or exploring what privelages have been put in place for this?

I've used it and I've connected to a domain using it, but I never actually set it up. However, from what you have described I would have done the same thing.

Out of interest are you having this problem with every domain cygwin tries to connect to, or just this one? Although that test is probably irrelevant as you can log in using already created accounts just not this one.

Having a quick scan on google I found this... http://www.nabble.com/Unable-ssh-login-usi...-td3074950.html ..which seems to be a similar problem, even down to the user NT AUTHORITY\SYSTEM reporting the login failure. See if any of that helps.

I think I've narrowed it down to one of two problems. Either there's something wrong with the Cygwin installation or there's something wrong with AD. Aparently before I was offered this role, there was a 3rd party IT company drafted in who insisted on installing Dells OpenManage software on a 1 year old SBS 2003 installation. From what I'm told that FUBARed the DHCP, DNS and Exchange services. It could be that the AD is in tatters after that point and would explain why only existing accounts,, created before that happened are able to login via WinSCP...

We have a Terminal Services server that doesn't actually do much so I'm going to see if I can get either Cygwin or OpenSSH to get an SFTP service up and running on that. If that doesn't work, I'm pretty certain it's a fault somewhere in AD...

Oh, right.. that's interesting, although only relevant if you can't log in with new accounts created (manually) on that domain (assuming the machine you are connecting to is a domain server).

It's definitely hitting the AD, no doubting that, as you can see by the error log, so technically it's not as Cygwin "problem". It could be an error in the way or type of account you create or it could be that the account creation has not propagated into the domain by the time you try to log in with it.

Aye it's the domain controller that I'm attempting to connect to. Every account I've created has been done through AD Users & Computers rather than the crappy "Server Management" console. The account I've been testing was created at the beginning of the month. I've got a reboot of the DC scheduled after hours tomorrow, so that should give definite indication on whether the account has propagated or not on Monday morning.

So are you saying you are creating the accounts on the domain machine? Ah, right I actually thought you were creating them through an app using cygwin. If that's the case then the user details you are passing must be wrong. You are not doing something really silly like using the wrong slash to represent a domain..

ie: domain\user not domain/user

Nah you don't mention the domain when logging in. All you specify is a hostname or IP address to connect to, Username and Password (Alternatively use a key file). The domain is listed on the \etc\passwd file within the Cygwin installation. When you create a new domain account, you must recreate the passwd file using mkpasswd, to include the account and its SID on the passwd file. Each account within the file lists the username, domain and home path when you connect.

When you login using that account on WinSCP, it physically logs into the domain using the sshd_server user account which is then used to query the passwd file (I think).

Well that was my last guess to be honest. Without actually creating a virtual domain controller and installing cygwin locally here, but even that couldn't be guaranteed to replicate the problem.

Cheers anyway Ric, I'll keep you posted if I crack it.

Just thought I'd bump this to mention I have cracked the problem...

Well sort of.

I deleted the account in question and thought I'd start from the beginning again. This time I created the account by using the Copy command in AD on an account that works at the moment. After recreating the /etc/passwd file for what feels like the millionth time, it still didn't work. But this time if I add the new account to the Remote Desktop Users builtin group it works beautifully!

Weird thing is, before I created the account by copying my own one, no amount of adding to groups (even Domain Admin) would make it work...

Ah well, the important thing is it's working now

Will Wales now be declaring this day a national holiday?

I believe so, yes. This will go down in Welsh history to be a bigger event than when they first found coal...

eh...uhm... aye.. :|