I was not able to access a newly joined Windows 7 computer on our domain from our Windows 2000 Server.  I just received that error.  “Cannot perform the requested operation”  Sharing was setup ok, permissions and security set ok, firewall was turned off.  I saw an Event ID 2017 on the Windows 7 system, too. Something about “unable to allocate from the system nonpaged pool”.

I found this online. Add the MaxNonpagedMemoryUsage value below in the client’s registry. (Windows 7 system)  Make a restore point first so you can undo if any problems arise.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters\MaxNonpagedMemoryUsage

DWORD VALUE: 0xFFFFFFFF

Next, restart the “Server” service on the Windows 7 machine.  Then go back to Windows 2000 Server and try to connect to \\window7machine and see if it can access it now.

This worked great for me, hopefully it works for you too.  However, it may be wise to increase that value in small increments from the default, which I THINK is 0×100000.   I just maxed it out and on my client system to test, and it’s working fine.  Just thought I’d make note of it.  If you have further problems, or this doesn’t fix the issue, remove the value and reboot.  This should return it back to the default.

This is just another one of those things that didn’t make any sense and only partially does now. At least NOW I know there is more at play here than the simple solutions in Samba using create mask and create directory mask. In Linux, that’s how I would get around the issues of Windows directory permissions running on a Linux SMB share.

Now, I am learning to do things the OpenSolaris way. I am loving OpenSolaris and ZFS! However, coming from a Linux and Windows “way of life”, there are some differences that just aren’t clear. What kills me is, I try the RTFM thing, and somehow completely miss that one little thing that makes it all work. Off topic, but an example, coming from Linux, I would just type “su” and get root access. In OpenSolaris, that won’t work. Neither will “pfexec su”, nor “sudo su”. Then one day, after dealing with it for a week or so, I stumble upon a post where someone in an unrelated sample script typed “pfexec su – root”. There ya go! Argh!

Anyway, back on the ZFS/CIFS/ACL thing. It was driving me nuts that I couldn’t figure it out. I wanted a folder with this setup:
/pool/sharefs – owner:greg – group:domusers
greg and domusers should have full control and all folders under “sharefs” should inherit that.

So under linux/samba, that’s where I would do like “create mask = 770″ or simlar, and “force create group = domusers”. Something like that, can’t remember exactly. made it simple actually. It always wrote files with the right perms and ownership and other people in that group could read/write just fine.

Problem is, you can’t get very specific about who get’s what, where, and you can’t use more than one group. Well, sure enough, there’s a thing called “ACL” that handles that stuff now. It’s been around for a while now, but I never even heard of it until I started using OpenSolaris. I like how it seems to be more compatible with the way Windows handles ACL’s. What I don’t like is, it’s confusing. I get the NTFS/Share perms in Windows, been doing that a long time now. The CIFS/ZFS ACL thing kind of makes sense, and it will “click” at some point the more I use it.

After spending hours on this, I reached a point where I had to figure it out. Here’s what I did.

On the ZFS file system, create it normally for SMB access. Then I changed some properties for aclinherit and aclmode. Change those to “passthrough”:
zfs set -o aclinherit=passthrough -o aclmode=passthrough pool/sharefs

Then chmod/chown. OH! That’s another thing. You need to use /bin/chmod and /bin/ls! Not just type: chmod … That wont work. In OpenSolaris the default path points to /usr/gnu/bin/chmod, which doesn’t have the “A” or “V” options to set/view ACL’s. That was another thing that DROVE ME CRAZY!!! I read the man pages and manuals and docs online and I didn’t catch anything that said, “Hey, there are different versions of chmod and ls here!” I can’t believe the time wasting here! Back to the point, do this to put your own default perms on:

/bin/chmod 2774 /pool/sharefs
(I actually am not positive that is needed, but I think it set group as inheritable)

/bin/chmod -R A- /pool/sharefs
(that will wipe out the current perms)

/bin/chmod -R A=owner@:full_set:fd:allow /pool/sharefs
(resets perms with only that acl)

/bin/chmod -R A+group@:full_set:fd:allow /pool/sharefs
(that appends the group perms, full control)

/bin/chmod -R A+everyone@:read_set:fd:allow /pool/sharefs
(above appends everyone read access)

In all the above that will preset INHERITABLE permissions for the subdirectories.  Notice above there is one with “A=” on it?  That will reset the perms and set only that perm.  So I guess you may not even need the previous line for “A-” to reset.  (I am just learning here ya know!)

It looks as if that makes a little sense now.  You can view the current ACL’s like so:  ”/bin/ls -V /pool/sharefs”

In my case, I might want to add another user or group:

/bin/chmod -R A+user:stacy:full_set:fd:allow /pool/sharefs
/bin/chmod -R A+group:othergroup:full_set:fd:allow /pool/sharefs
/bin/chmod -R A+group:yetanothergroup:read_set:fd:allow /pool/sharefs

So with this setup I can now open the share on the server and create a file or folder with inherited permissions.  It does, however, save my username as a new owner, so keep that in mind.  But if the group stays in there with “domusers” as full read/write access, I am happy.

Well, now I get it just a little and it makes more sense compared to Windows ACL’s.  I didn’t go over any share specifics and authentication issues, this was just ACL’s!  I still have to RTFM my way around that for a while.  Next project, join OpenSolaris to a Windows domain.  (Which, BTW, does not work in NT Domain style connections, you have to use Active Directory.)

I found some info on Google searches to get Windows 7 to join a Samba domain controller.  I have Ubuntu 9.04 Jaunty which runs Samba 3.3.2, which I guess does not work.  You need 3.3.4.   Windows 7 needs a registry change:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanWorkstation\Parameters]
“DomainCompatibilityMode”=dword:00000001
“DNSNameResolutionRequired”=dword:00000000

The above need to be added to allow the join to work.  Then find the key below and set those values to 0.

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\Netlogon\Parameters]
“RequireSignOnSeal”=dword:00000000
“RequireStrongKey”=dword:00000000

The Netlogon values need to be updated, or Windows 7 will not allow domain logons.  You’ll get an error about credentials and no domain controller, or something like it.  Adding the second two will allow the logon.

Adding the registry keys above, plus upgrading Samba, did the trick.  I was able to join Windows 7 to Samba 3.3.4, but I did get a weird error about the DNS suffix being wrong.  I just said OK and left it.  I tried to change it several times after, too, but always get the same error.  System working fine so far though!

As for upgrading Samba, you’ll have to Google that one.  But here’s what I did, in a nutshell. (This is NOT a HOWTO, just a record of my experience, so if you follow this, it might break your system. Just be warned.)  I had a working domain controller, so I had a SAM database already with SID’s and passwords.  I didn’t want to lose those.  After backing up my server and Samba configs (including all the tdb files) I removed Samba 3.3.2 package from Ubuntu.  Then I downloaded the Samba source tar.gz for version 3.3.4, unpacked and “./configure” and then compiled. (make && make install)

At this point I found all my tdb files and copied them into the default Samba installation, which was different than the Ubuntu package.  I think the original tdb files from Ubuntu are in /var/lib/samba.  I copied all that to /usr/local/samba/var/lock. (the default when compiling from source)  I also setup a link from the original smb.conf in /etc/samba to /usr/local/samba/lib/smb.conf.

Now I’ve got my Windows 7 system logged in and joined to my Samba domain!

Just wanted to add a quick note about this as I couldn’t find a reason why dynamic DNS on my Ubuntu 9.04 system were failing. I had all the right perms, ownership, etc. I even opened up the files to full world writable and still, I got errors that the journal files could not be written to.

Log snippets:

error: journal open failed: unexpected error

jnl: create: permission denied

Learning as I go… there’s a thing in Ubuntu called Apparmor. Never even heard of this. This is what was keeping the files from being written to by the bind daemon.  I guess Apparmor has been in this for a while now, but for several yeas now, I have not run into a situation where I had to mess with it.

Here’s what you change.  And keep in mind, this is NOT the correct way to handle this on a production or public DNS server.  You’ll need to read up more on the correct config for this one.  But on my tiny LAN or at home, here’s what I did.  In the /etc/apparmor.d directory, edit the usr.sbin.named file.  Find the line:

/etc/bind/** r,

Change it to:

/etc/bind/** rw,

Then restart the apparmord daemon.  If your DDNS config in Bind and DHCP are correct, you should start seeing successful updates now.

Here’s a coulple links that were helpful on the DDNS setup:

http://brunogirin.blogspot.com/2007/11/dhcp-and-dynamic-dns-on-ubuntu-server.html
http://ubuntuforums.org/showthread.php?t=274665
http://www.ops.ietf.org/dns/dynupd/secure-ddns-howto.html

Also, I wanted to make a note to myself. Creating a new key for DDNS:

dnssec-keygen -a HMAC-MD5 -b 128 -n HOST dhcp-update-key

That creates keyfiles in which you’ll get your key string, this is added in your dhcpd.conf and named.conf.* files as “secret”.   RTFM dnssec-keygen. and read up on the links above. :)

Well I just have too much fun with things like this. I don’t know where it came from, but the Blogosphere was a great name people use. I suddenly thought of Nettiverse because I was trying to connect my blog with Facebook and Twitter. I thought they were pieces of the virtual universe we take part in, the Nettiverse. Now, many people out there are moving away from the Blogosphere and into the Twitterverse. Or maybe it should be called the Twittersphere. Personally, I like Twitterverse.

What’s bugging me is this, Facebook’s name. I haven’t seen or thought up a cool name for it as it exists in the Nettiverse. Anyone out there with a cool idea?

I thought of BookHole! Hahaha! I like it, makes me laugh because that’s exactly what it is, a Black Hole in the Nettiverse. Once you get in, you can’t get out! It sucks you in and wastes away time! But there must be something more fun to call it? Tweet me if you have any ideas. http://twitter.com/gregthegeek

By the way, as people more and more move away from blogs and on to Twitter, I’ve seen a post or two from people suggesting that blogs are a thing of the past. Well, I disagree. I feel they are useful tool. I use my blog mostly as a tech log. Things I like to remember, things I once fixed. The world out there could care less about it, but that’s not the point. It’s for me. I refer back to it, and it’s easy to get online while I am at a client and can’t remember how I solved a problem. Also, the little tidbits I post are found by Google searchers. So, if I find a solution and it helps just one person out there. Right on! Tweets are too short for that. So I like my blog, and I’ll keep using it alongside my Tweets and BookHole. (there’s got to be a better name than that! ??? )

This drove me nuts!  Why Microsoft had to take something totally simple in Windows 2000 and make it a complicated thing is NOT beyond me!  This is MS we’re talking about!  Of course it’s not easy with newer versions.

Took me a little bit, but here’s the commands I used on our primary domain controller, and it’s working great. that first w32tm command is all one line.

w32tm /config /manualpeerlist:”0.pool.ntp.org 1.pool.ntp.org 2.pool.ntp.org pool.ntp.org”,0×8 /syncfromflags:MANUAL /reliable:yes

w32tm /config /update

net stop w32time

net start w32time

w32tm /resync /rediscover

That should do it. However, always make sure you firewall is open to port 123 outbound!  I initially was receiving this error after running a “w32tm /resync” :

The computer did not resync because no time data was available.

In my case, that was caused by my firewall blocking port 123 for NTP traffic.  Go figure, we’ve been running this particular network for probably 2 years with that firewall blocking port 123, and only now did someone come and ask “why is our computer time off by 6 or  7 minutes?”  This is when you say, “Welcome to the world, can I help you?”  (Good old Beavis)  Well, at least we got our server configured better as a “reliable” time source with the right ntp.org pools.

Before I get going, please comment on this. I am wanting more information, so please share.

I was wondering, though, why use a vpn to tunnel a terminal server connection? Isn’t terminal server encrypted already? Here’s a couple things that I *think* are important:

1. The vpn connection is no more secure than the terminal server. Why, if a trogan program runs on your remote client, what difference is it that you have a vpn to cover your terminal server? The attacker has access to the remote client, they now can get into your network with either system.
2. The vpn connection opens up a whole mess of insecurity if your remote client is compromised. (of course, it does with terminal server as well)
3. The data is never on the client if you use a terminal server, but with vpn, you open up your network. OUCH!
4. This is the one that really get’s me… with a vpn, if your remote client gets a nasty virus, your whole corporate network will probably now have it too once that vpn connection is opened. Not so with terminal server.
5. At least with terminal server, you can totally restrict apps and printing and such, so nothing is ever on the client, it only receives the screen shot of the server.
6. Brute forcing usernames and passwords are vulnerable on both.
7. If you were really worried about security… YOU WOULDNT RUN ANYTHING ON THE INTERNET! You wouldnt run IIS, Email, or anything else that communicates on the internet, expecially remote access services!

So from where I sit, I can’t understand how using vpn to tunnel terminal server will make my remote access more secure, in fact, possibly less secure. Please tell me if I am missing something though.

Thanks.

Greg

———————————–
Edit: 3/28/05

I have been talking about this issue with friends on forums, and I wanted to share more thoughts based on some of my posts. And just so you keep this in mind, I am basing these thoughts in the context of a small business with less than 50 users which might not even have an IT staff. A company like this typically will not spend $10-$15 thousand dollars on a VPN solution, leaving us with only the built in Microsoft technologies (or linux).

— from a post on 3/21/05 —

I dont think that vpn is less secure really, its got a great security model. What I think is less secure, is using vpn with TS. I dont believe it offers any additional protection. Why encrypt an encrypted connection? Why give access to the whole network and all the servers, if you only want them to access a few apps on 1 server? And why I think it’s less secure to run it this way? That is because the reason you run Terminal Server is to allow the user access to certain apps that would not otherwise run on a vpn, AND to isolate the use of those apps and their data. You cant isolate the processing of data and its transmissions on a vpn. The vpn essentially extends the internal network to a remote system over a public network, right? Well a TS client does not do that. It only extends the keyboard, mouse and graphics. So the data never leaves the network, it cant even be printed remotely or cut&pasted on the remote client (if you set that up of course).

So it’s not that I think vpn is less secure, implemented properly, it’s great, but only for the right purposes. For my systems, vpn wont work. I have to run apps that just wont run over a vpn, or they will but be so damn slow it just isnt practical. I installed vpn originally aboot 5 years ago at my largest client. We ran into many hurdles running our main apps. I basically determined that unless you have at least a 10 Mbit connection, dont bother. That’s not to say that apps cant work on vpn, it just depends on if they were written for it for one thing, and if not, how their execution and data is transfered. I have ran several apps that are so called ‘network’ apps, and all they do is put on a short cut to a large exe that is downloaded locally and then executed. That just wont work on vpn. It’s WAYYY too slow! Try running a 100mb + ms access mdb from remote vpn client, that then connects to a 3Gb + sql server db. Even on the fastest broadband connections, it just isnt feasible. Terminal Server solves that problem.

Now, also keep in mind, mostly why I have the ts’s is to do remote admin. Some companies have this setup: 2 servers, both are AD servers. One runs Exchange and IIS, and has MS ISA firewall on the server to vpn into and proxy out. (I didnt set that up, nor do I maintain it, I would have set it up way differently) The other server is behind that firewall and runs only a sql server internally. In this scenario, they didnt setup a dedicated firewall, and consequently are vulnerable from other sources that would put the domain controller at risk. This is because, it’s way more likely that IF an attempt were to be made to crack that server, it would be most open to attack on the IIS services, or Exchange. Once in, the firewall is useless. So… why put in the vpn here? There are so many WAY more insecure elements involved. This is why I mention in the blog… “if you’re worried about security, dont get online.” I mean, obviously your not THAT worried, or you wouldnt setup the systems that way. And if you’re not THAT worried, why use the VPN?

If I were to make the network more secure for remote admin I think I’d have to do this: Run a TS in a DMZ with admin rights to TS denied. (have to be a restricted use user acct.) Then, from the TS session, open another TS session to the specific server you want to administer. Your firewall can be set to allow communication on TS traffic to and from the dmz computer only. This way, no data is ever really sent to the remote pc, and the remote pc has not direct access to any internal system, but does have access to *view* information.

The insecurity I see, with both TS or VPN, is the client use and it’s vulnerabilities. They both suffer from the fact that IF some trojan is somehow executed and allows an unauth user remote control of the pc, that user could see all the data your company user can see. The advantage to TS in this situation, is that at least that ‘hacker’ would not have direct access to the whole network right from start. They could obviously run a keylogger and then log into that TS themselves, or from the remote pc. Same with the vpn. In my situation, the remote users use their own systems to remote into the company. They wont spend the money, nor do they have the administrative capability to maintain stringent policies and systems.

— Posted from 3/23/05 —

I found out that TS can be brute force attacked! (via password crack) (OH NO! VPN IS NEEDED!!) BUT!!!! Then I did a little more research and discovered that with my setup at my different clients, it aint gonna happen.

There is a program out there that can “dictionary attack” a Terminal Server. Not Brute Force it. There’s a difference. Dictionary attack uses a dictionary of words to test, brute force checks every letter combinatoin. That program must rely on the fact that the local “administrator” account always has local accees to the TS. And since it uses only a dictionary attack, dont use words for a password, it wont crack it. And since it relies on the admin account, rename the administrator to something else, problem solved.

Use of an 8 or more character password is also all that is needed to deter an actual brute force attack. Along with account lockout policies when logons fail, you can pretty much bet that you wont get brute force cracked. I read somewhere, that if you use 12 character passwords, and if they are only lower and uppercase, there are almost 400 BILLION BILLION combinations. And even if you could do 1 million attempts per second, it would take millions of years to crack! I am sure someone good at math can figure the details out. And this is all for just the password, YOU NEED A USERNAME TOO! Add lockouts to the mix, and it aint happening! Do some research on brute force cracking and you will see what I mean.

I read a post by someone who cracked a 6 character password with special characters in it, it was cracking something on the local machine (not networked then) and it took a day and a half to do it. Try doing that on network systems, where, if properly setup, will not allow millions of connection attempts like that.

I used to fear the “brute force” thing. Not now. And it’s not that it isnt possible, but properly configured networks/systems simply make it way too long to attempt it using current proccessing technology. that’s why higher bit encrytion is better. It takes way too much time to crack the encrypted key at 128 bits. By the time you did, the key would have changed.

Dictionary attacks are another thing, they can get a crack in minutes. But if you dont use dictionary words as passwords, then you are safe.

this all leads me to the essential wisdom of work, why do things the hard way. A hacker isnt going to try and crack something that is hard to get into, they will try the easiest route. TS and VPN are not easy to get into. They will look into which services provide the most exploits that are available to them. VPN and TS have very little exploits. (at least it was tough finding any) Try looking up exploits on your mail server or web server! I bet they’ll try getting in there way before an attempt on TS.

The amount of time involved to make these kind of attacks are huge. Script Kiddies or whatever arent going to spend that kind of time. The only way someone would do it is for money. And most likely a compititor might want the information and pay for the hacker, but holy cow, is that likely? I dont think so. It would be way easier to do some “social engineering” to infultrate the company and then get into the network.

Simple precautions on the TS are all that is needed. As with any service. 1. dont show the last user logged on. 2. restrict access to only certain users, not domain admins. 3. lockout failed login attempts. 4. long passwords 5. Change the admin name.

So I am still back to my original thought, vpn would not make ts more secure. It would only add more maintenance and head ache. But, if I already had a good vpn solution, I would utilize it.

However, I have a new thought, I guess. VPN, in certain situations that dont have stringent policies and procedures, would make remote access less secure than TS. This is because that encrypted tunnel does not get filtered by a firewall or IDS and a virus or attacker can use that connection to directly affect the entire network. With TS it is at least not possible. That’s why you have to have IT setup the remote computer and on it, restrict user actions as well. This makes VPN unattractive to me.

— and another post on 3/23/05 —

So when adding a vpn to tunnel a TS, what you are saying is, “I have a vpn, I need to tunnel it through another vpn to be more secure.” That’s like saying, “I need 2 firewalls to double up on the packet filtering.”

The only thing I think a vpn will do, and only if I had a nice hardware appliance type one, is give me device authentication. If I use MS software based vpn, especially using pptp protocol, I am no better off. I would still need to authenticate in either system (ts or vpn) and the hardware solution probably allows for IP or other device authentication. Also, I think that to really be secure you would need to use a certificate or something of that sort to authenticate. TS cant do that, so I would see that as an advantage in vpn.

If I put in a vpn, I open my whole network up. And with no real IT staff to monitor it or the client machine, that opens a whole mess of problems. At least with TS I prevent any openning of the network, only that port on that server. (no data is transfered, just user IO)

—————————————-

In my situations, as in small businesses remote administration, I do believe VPN is openning a hole in the network and making it a little less secure than to provide straight access to Terminal Services. So far I have not seen any evidence to tell me otherwise, but if anyone out there can give me specific reasons to give me some evidence, please do.