February 2006 - Posts
I'm reading a real
interesting article on the SANS website right now. Seems they are rightly concerned about an email they've received about a University professor who is forcing their students to either break the law or fail part of their course!
I'm not going to reproduce the whole email or their comments here, but I'm going to extract bits I want to reply to myself. To read the full article please use the link above!
The "TASK"
Student is to perform a remote
security evaluation of one or more computer systems. The evaluation
should be conducted over the Internet, using tools available in the
public domain.
Whoa. Sounds interesting, I wonder if the professor concerned is aware of the various laws against unauthorised access to computer networks.
In conducting this work, you should imagine yourself to be a
security contracted by the owner of the computer system(s) to perform a
security evaluation. "Imagine yourself" to be contracted to perform the survey? Why would he need to tell people to do that unless he was all too aware that you are
required to have authorisation before undertaking this kind of work?
The email goes to to require the students to provide full records of when and how the systems were "evaluated", what tools were used, "samples" of data collected and a handy cut out and keep chart of what systems had which vulnerabilities. Oh boy, be an awful shame if the wrong kind of people got hold of this information.
Never mind. I'm sure this is just a pro-forma project write up and the students will be permitted to audit their own organisation in order to ensure that they can obtain the authorisation they need to do this job, right?
"Word came down
this morning that no direct action will be taken against the professor,
but if we catch any students doing these scans against our computers we
will not be exempting them from our existing procedure. Specifically,
disabling their student account and referring them to the Student Dean
of Corrections."
So let me see if I have this one down clearly: We won't intervene in this class content (in other words, we approve of this assignment), but we will take disciplinary action against anyone who hacks our own systems. Can I get a "Hypocritical asshats!" from the front row?
Frankly, what we have here is a professor and a university that seem anxious to disgrace themselves. I'm no lawyer, obviously, but I would suggest that they leave themselves not only open to ridicule but lawsuits from companies who are targetted by students, and / or the students themselves who are placed in the unenviable position of either messing up part of their course or breaking a law that could see them jailed if they're caught.
For some reason, and I'm at a total loss to explain this, people just do not take "rules" and laws surrounding computing seriously.
I'm not sure if this is down to ignorance, or some kind of belief that "it doesn't matter" or what, but I myself have actually seen people who would rather
die than be accused of stealing as much as a penny blindly suggest breaking licence laws to the tune of
thousands of pounds.
Today, a colleague on another site tells me of someone who had purchased one licence for a package and then wanting their IT department to install it on several computers. And getting upset when told "No, sorry we can't" and having the reason explained to them. I've experienced this myself in fact, even to the point of people complaining that I'm being "unhelpful" and "obstructive" because I refuse to aid them in a criminal venture. Pardon my honesty, folks!
I want to make it clear: this behaviour isn't limited to academica by any means, I've seen it when I've worked in business just as often as I've seen it when I've worked in education. The vendors themselves are not without blame here either; when you can ring 5 different "Vendor authorised specialist" suppliers with a licencing question and get 5 different answers you have to wonder if the licence schemes aren't maybe a little too difficult for most people to understand?
It's all well and good to mis-understand licence terms. It's all well and good to disagree with the terms of a licence and feel that the vendor is profiteering. But at no time does it become OK to knowingly break the law and especially not to solicit others to do so on your behalf!
David Harley
reports on an ongoing rumble in the Mac community about the
awful false alarm problems that hit Mac users who run Sophos Anti Virus.
I've seen many of these complaints from Mac Sophos users. It certainly is a bitter pill for them to swallow that after years of no real threat to speak of, in the month where some holes finally do start to come into the light that they are damaged far more by their protection than they would have been by the threat it was guarding against. False alarms are sadly a fact of life with the current breed of virus
scanner. Some scanners are worse than others (and Sophos is far from
the worse), and some scanners are so bad that people tell jokes about
them.
I've seen people threaten to sue, and I too have seen people wanting to walk away from "pay for" AV and support open source products. The Open Source scanners certainly should be supported, but as much as I myself like and use Clam, it simply isn't designed to do the same things that Sophos can do.
At the end of the day, it is all about cost. Someone's time reparing a machine thats been attacked by either a worm or a runaway virus scanner can be a considerable cost. Is the cost of the insurance greater or lesser than the cost of the risk for you?
Keep in mind that if your comnputer becomes infected with malware that attempts to spread itself to others then part of the cost is your reputation. I can minimise the cost of a security issue to my business by working all night to recover from it, but I can't wind back the hands of time and regain the trust of people whose computers have become wrecked because of my foolishness.
So what to do? I won't rewrite stuff I basically agree with from the articles I've linked to as there is no point in that so I'll just leave you with a couple of questions:
- Are Mac users too fussy about AV, or are Windows users too accepting of shoddy products?
- What if I told you that a possible method for improving issues with false alarms and detecting "new" viruses means changing the way you think about virus scanning?
- Virus Scanners could be looked on as insurance. If the risk of fire was increasing where you live, and the insurance companies put up the cost of fire insurance accordingly, you might not like it. But would you want to go without insurance?
History Lesson:
Way back in the mists of time, Dr Alan Solomon, Yes - THAT Dr Solomon! Of Dr Solomon's Anti Virus Fame. Anyway, he wrote an interesting little article that talks about the perfect Anti Virus program. Always detects Viruses and never gives a false alarm. Personally, I wouldn't want to rely on it but it does illustrate the point.
More History:
It's nice to catch up with David Harley and (in his comments) Paul Schmehl again. They both used to be Alt.Comp.Virus regulars 'back in the day' and are two people whose posts I always tried to read - even if I didn't always agree with them!
If you're at all interested in security and malware then keep an eye on the site that hosts David's blog.
Just in case it wasn't already bad enough, apparently it is even worse.
SANS have yet another
write up(see update 2), based on the fantastic work at
Heise security. It seems the vulnerability we talked about
previously also effects the Apple Mail application.
In fact the problem with Mail is worse because an attacker does not
need to wrap the file in a zip archive to disguise it, due to the way
Mail implements the
Apple Double File standard for carrying data and resource fork info as MIME data.
Ooops.
First of all, lets keep some perspective here; Apple Macs still
have a superb "real world" security record. Don't trade in your Mac
just yet if this is starting to worry you.
Next up, this does make it all too clear that Apple have allowed "user
experience" to come ahead of user security in their design choices, and
that there may be a rich vein of similar exploits awaiting the curious
hacker who cares to go looking.
I think Apple urgently need to perform a review of how their built in
apps and tools like the Finder make assumptions about the data passed
to them is structured. I also think that Mac users who have previously
taken security for granted may need to approach things with a little
more caution.
Lastly, Microsoft took a lot of deserved criticism for a similar design approach
some time ago, and one way or another have worked very hard at moving
towards a much more grown up approach to secure product design. They're
not perfect but they are trying hard.
It seems that while
Apple are sneering
at Microsoft and suggesting that Longhorn is copying Tiger, Apple could
and should perhaps start their own photocopiers up and learn something
from Microsoft's much more open and honest approach to security of late. And before anyone replies to tell me how bad Microsoft have been at this, I know, that's my point.
I'm actually quite glad I had the chance to wait, reflect and of course drink in other peoples thoughts before starting my own write-up. What looked
this morning like a moderately interesting hiccup in Safari now looks like it might chain a minor issue with Safari on to a minor quirk in how the OS itself handles files, to generate what could possibly turn out to be a real issue.
Heise Security provided the original writeup of this issue, and their site is well worth reading if you're interested. The problem is now also being
tracked by SANS, who now agree with me that the problem has more depth to it than it first appeared.
Executive Summary. In my opinion, Apple need to correct the following issues:
- Safari should not automatically open ANY content.
- The content in ZIP files shouldn't be automatically opened.
- Resource fork file information
should be compared to other file information when a file is re-assembled and an
error called if it fails at least a basic sanity check.
- A safer default should be chosen for all shell scripts -
badly formed shebang lines should be a blocking issue when running shell
scripts automatically.
Some background
As many Mac users will know, Apple's file systems break down a file into two "forks". A data fork containing the actual data in the file and a resource fork containing metadata such as icon thumbnails, other information about the file, and most important of all information that the OS uses in determining how to open the file.
This information exists side by side on the file system and overall works in a very similar way to streams in NTFS.
When stored on a non Apple HFS / HFS + disk, OS X will break down the streams into the data fork, which is saved as the "normal file" and another special file containing the data from the resource fork. Such files are named as
._filename, so for example if I save a jpeg file named "
photograph" on my Mac and then move it over the network to my windows machine it will result in two files stored on the windows machine - "
photograph" and "
._photograph".
Prefixing a filename with "." instructs the OS to make this file a hidden file, so Mac users would never see the resource fork file. OS X, of course, sees all and understands how to combine a data file and the resource file to generate all the information on a file that the OS and applications might need.
So what happens with this Safari / ZIP file exploit?
Starting with the ZIP file:
In OS X 10.3, Apple added a feature to create a ZIP file archive of any file from directly within the OS, similar to the Windows XP archive folders feature. To ensure compatability and to keep things tidy for people on other systems who open these archives, the resource fork file is placed into a folder named __MACOSX (that's two underscore _ characters).
So if I create "Robert's Resume.doc" on my Mac, and zip it up and send it to myself on my Windows machine, I will open the zip file to see something like this:
\Robert's Resume.doc
\__MACOSX
\__MACOSX\._Robert's Resume.doc
Windows ignores the contents of the __MACOSX folder, and when we move back to a Mac again, the Mac knows how to combine both files automatically, without bothering the user.
So what if we were to create a "malicious" pair of files, with a data file that misrepresents itself as innocent data, such as a jpeg file, or a QuickTime movie, while actually containing some malicious code, and paired it with a resource fork file that instructed the OS to open the data file as a shell script?
This is what we've got here.
Opening up the "proof of concept" zip file, we find a file named "
Mac-TV-Stream.mov" and a folder named "
__MACOSX". In the "
__MACOSX" folder we find a file named "
._Mac-TV-Stream.mov". [
screenshot]
If we open the \Mac-TV-Stream.mov file in a text editor we find the following [
screenshot]:
# /bin/bash
while true; do
echo "Hallo Welt!"
doneIf we open the "
\__MACOSX\._Mac-TV-Stream.mov" file we see a binary file, which contains the following [
screenshot]:
%/Applications/Utilities/Terminal.app So we can see what happens here. We have a file whose extension and icon suggests it should open with QuickTime[
screenshot], but this is over-ridden by the resource fork which directs the terminal application to open the file[
screenshot] - which just happens to be a shell script instead of a film.
Lastly, the shell script contains a poorly formed
Shebang line which ensures that OS X will send it directly to the default handler app for shell scripts - which by default of course is the terminal.
Lessons learnt - When assembling a file from resource and data fork files, OS X should warn the user when the default action suggested from the resource fork is different from that suggested by other file characteristics, and possibly set permissions on such files as non executable when such a mismatch exists.
Moving onto Safari
Safari has an option to open "safe" (their quotes) files after downloading. This is turned on by default, and allows a user to download a file, and if it is "safe" it will be opened automatically.
In the case of archives, this appears to include re-assembling a file from its data and resource files and then performing whatever the resource fork suggests is the default action.
There really isn't much to analyse about this part of the problem - Safari is doing what it is told by design. Arguably the design is rather poor but from a programmers perspective this part of the system is in no way broken.
I'd certainly suggest that this is an unsafe choice of default settings however!
Lessons learnt - Are ZIP files safe to be opened automatically after download? Are ANY files safe these days? This option should be off by default. This is something you can do on your Mac right now, from Safari properties [
screenshot]
When an archive is opened, especially if it is by another app such as a web browser, files should NEVER be automatically executed.
Threats from this "attack".The current "Proof of Concept" script runs a simple "Hello World" statement. This "exploit" runs a shell script in the currently logged in user context, which is analogous to a windows user running a batch file; it can do whatever the user can do and no more. Hopefully you don't run as an administrator - this is actually pretty uncommon on a Mac so this isn't as bad as it could have been.
Of course being able to run as the user is perfectly ample for a script to trash that user's data. We could also install a Trojan into their account, providing that Trojan doesn't require admin rights to install its hooks (see
companion virus).
Maybe this exploit can't compromise the underlying OS from a normal user account, but then it doesn't have to affect the OS to break lots of hearts.
I don't have time to do a proper write up yet, so more to follow when
I've finished a) laughing and b) doing the things I actually get paid a
salary for.
But for now - Have Apple
learnt nothing from the mistakes Microsoft's IE team made?
[EDIT: I've now performed a
full write up of this issue, which you should probably read instead of this one]
I probably should go into SSL a bit more, as I'm not sure I made things
terribly clear from my last post. Matthew Thomas has also reproduced a
classic article on this from years ago which does a good job of highlighting some more weaknesses in SSL.
SSL performs two functions.
SSL provides encryption - it provides a mechanism for a web server and
a web browser to exchange data via an encrypted "tunnel". They do this
by a secure exchange of encryption details.
- The client requests information from the web server via SSL
- The server replies with its digital certificate and encryption preferences. The certificate includes a public key.
- The client generates a session key which it then encrypts using the server's public key. This is sent to the server.
- The server uses its private key to decrypt the session key.
- The client and server both now have the session key, and this is
used to encrypt all data exchanged in both directions for the rest of
the session.
- In addition, each packet is signed to ensure that no tampering takes place.
SSL provides Authentication - using a "web of trust" model. If you
visit my employer's SSL based websites then you / your browser decides
to trust us based on the following:
- Our server obtains a certificate from a trusted "root certificate authority".
- The root CA should take steps to verify that someone who applies
for a certificate is who they claim to be. This should involve actual
investigation of the business, checking details of registered
companies, and the like.
- Your browser has certificates from these root CAs. When it
receives a certificate from a server, it checks its own records for a
corresponding "root CA" certificate.
- It uses this to ensure that the certificate just presented to it is legitimate.
- In other words, you trust me because "Honest John's certificates"
says that I am who I claim to be, and you have decided that you trust
Honest John.
- Now are you sure that you really trust Honest John? Are you sure that he really verified my claims?
- Are you sure you trust your web browser? The most likely scenario
is that the certificates in use will be pre-loaded by the browser
developers, not hand picked by you.
As an exercise for the reader, where do you think this model breaks down to allow the "break" described below and elsewhere?
Seems that there has been some rumbling that SSL encryption has been broken recently, which is quite interesting and would be a major threat to things we are all just starting to take for granted such as online shopping and banking, privacy and other important issues that people take for granted. For those who don't know what SSL is, it is that 'little padlock thing' in your browser that you've always been told means that the website you are visiting is secure.
Now this is scary stuff and a true break of the SSL encryption routines would be a tragedy, but that isn't quite what has happened here. What we have here is a trojan that uses "pharming" (targeted hacks looking for specific things, in this case connections being made to online banks).
The
recent fuss revolves around a targetted hack attack using a particular trojan that sits between you in front of your computer and the data you send to secure website, and in this position it can intercept and monitor your traffic without having to actually "break" your encryption.
Note that this is a very simplified "layman's terms" explanation of what happens, technical explanation here.
So where does this leave us? It is perhaps worth recapping what SSL is and what SSL isn't at this point: Some people attribute that 'little padlock thing' with
super powers that guarantee that nothing can go wrong with their transaction and that just isn't true.
SSL is a way of providing a secure and encrypted 'tunnel' between a web server and a web browser on the Internet.
Think of SSL like your local mail posting service offering a guarantee that certain letters can be sent to and from certain destinations securely. That is all SSL offers - it is a very important offering to be sure, but it only guarantees part of your security.
A SSL connection doesn't know about the fact that your computer has a trojan on it, generating a SSL proxy performing a Man In The Middle attack. It only provides secure communications between two points and can't know that someone is reading your secrets over your shoulder before you send them, so to speak.
A SSL connection can verify that the tunnel
goes to the correct web server, which is great, but what if the correct web server has been hacked? Again, an unauthorised person reading your secrets over the shoulder of the person that you are talking to isn't the fault of the post office.
SSL cannot tell you if the secure connection goes to the correct web server and it hasn't been
hacked, but the data is stored insecurely at the web server because the business you are
dealing with is staffed by idiots. It isn't the fault of the post office if the person who receives your secret mail tapes a copy to their window for every passer-by to read.
A long time ago on a website
far far away, I suggested that while it is a very boring way to spend your time, it is well worth taking the time to check your logs every now and again if you run a website.
As well as the obvious benefits of seeing how many people think you're worth taking the time to read, you can spot some interesting things.
For example, people
leeching your bandwidth. Like
this guy, for an ebay auction. If you're really sharp you can play them a little trick in return for their stealing from you.
So tell me: would you buy a phone from
a bandwidth stealing wanker?
After my comments about the first Apple OS X /Worm/Trojan/Virus/Whatever,
Donna Buenaventura, a fellow MVP, pointed out that actually we also had the 2nd one this week as well.
F-Secure have a write up too [
blog entry] and an entry in their database [
virus db writeup]. This again is:
- "merely" a proof of concept.
- requires the end user to do stupid things (but we already know that plenty will, so I'm really not sure why this is held up as the holy grail).
- has an internal mechanism to halt its spread on Feb 24th 2006.
So the sky isn't quite falling for Mac users, but this should certainly be writing a few smiles off a few complacent faces. To be honest, we've still not seen any OS X malware that doesn't require
some user assistance (but again let me emphasise, that is not the barrier to entry that some people seem to think) but this does show that people are out there watching, waiting and sharpening their knives for Apple.
[edit]: Sandi Hardmeier, another long timer MVP, has
also been tracking this
on her blog.
While some argue it to be as much a Trojan as it is a Worm, just days after I wrote that "While I've always denounced people who claim virus infections are impossible in OS X as ignorant, and I still stand by that, the current risk to Mac clients is substantially lower than it tends to be on Windows machines." it seems that Sophos are trumpeting their discovery of a Mac OS X worm.
F-Secure are talking about it too, so this isn't just Sophos acting up. It seems the chance of infection is very low if you understand how to practice safe computing, and very low indeed if you don't use iChat. Of course, after years of not having to worry about this kind of thing, and arrogant assumptions that their platform was somehow magically immune to viruses, I wonder how many Mac users will be able to get into the "safe computing habit".
May we continue to live in interesting times..
It seems that this has ignited a lot of debate in the Mac community. Comments on message boards range from "The Sky is Falling" types to "What's the problem?". Both responses are wrong in my opinion. The sky isn't falling, but this is a noteworthy event. A "Proof of Concept", if you will. Every single currently active malware vector out there started as a proof of concept.
There is an issue here - it can't be ignored or wished away. I'm still unsure in my own mind as to whether this is a trojan or a worm, but in either case it is here. Its infection method is manual and trojan-like, and requires the user to "do something silly" - but those of us who have been working with Windows based users for years know that isn't a problem. Its method of spreading to other users works more like an email (actually IM in this case) worm once it is in place.
We're already starting to see other apps that behave in ways the users didn't expect but which still managed to get themselves installed. The fact is, OS X users have become accustomed to the idea that nobody targets their platform and hence not enough question why applications ask for admin rights at certain times and these users are just conditioned to supplying the appropriate username and password on demand.
With thanks to Andrew Welch who posted a good "neutral" description of this trojan/worm's actions. Symantec's writeup is pretty good too (I know, me with something good to say about that lot... shocking!) and includes instructions for manual removal.
Clam AV also includes detection for 'Trojan.Leap.A" in its up-to-date definitions for those who are running ClamXav or similar and want to scan their systems.
I typically listen to Radio 5 on the way home from work, and today presenter Jane Garvey announced with relish that "University students are graduating with 2:1 degrees and are barely literate". I guess the BBC loves a scandal, as do we all.
They go on to place the blame pretty much on the doorstep of 6th forms in both schools and further education, and maybe spread a little of that jam in the general direction of the govt. for "over testing" in the national curriculum. Of course, when you
read into the details then the problems are not actually that graduates are illiterate but that a few make spelling and grammar errors and have problems with numbers.
Still bad enough perhaps, but hardly the stuff that lives in the BBC's headlines. I suppose "Some people occasionally spell things wrong and can't remember how to use apostrophes" doesn't really scan. Actually it is quite an interesting report with some valid (IMHO) points when you get to the meat of the matter, but by no means deserving of the kind of headline Radio 5 gave it.
I personally think the BBC would also do well to focus on companies that present poorly executed and incorrect revision material on line, like
this vendor that the register has recently identified. "Physician heal thyself" or possibly "Let he who is without sin cast the first stone" spring to mind.
Now would probably be a superb time to remind everyone that the views raised in this blog are my own, and most certainly do not reflect ANYONE's official policy on ANYTHING, and are especially nothing to do with my employer.
In a very interesting move, VMWare have
announced that they are releasing their VMWare server product, for free. This is the next edition of their "entry level" server virtualisation product and is the one that competes most directly with Microsoft's Virtual Server.
All I can say is... you can't go wrong at that price... so give it a go!
Reproducing some of their comments here, VMWare server certainly seems to be fully featured:
- Support for any standard x86 hardware
- Support for a wide variety of Linux and Windows host operating systems, including 64-bit operating systems
- Support
for a wide variety of Linux, NetWare, Solaris x86 and Windows guest
operating systems, including 64-bit operating systems
- Support for Virtual SMP, enabling a single virtual machine to span multiple physical processors
- Quick and easy, wizard-driven installation similar to any desktop software
- Quick and easy virtual machine creation with a virtual machine wizard
- Virtual machine monitoring and management with an intuitive, user friendly remote console
Almost everything you need if you're curious about virtualised servers and want to trial them.
This falls hot on the heels of their release of
VMWare Player, also as a free too, and raises the possibility of VMWare users being able to create virtual machines on VMWare Server to distribute to their workstations for free with VMWare Player.
I can't decide if this pricing approach is a stroke of genius on the part of VMWare, or a sign of madness. Are they running scared of Intel and AMD putting virtualisation on the processor, or are they trying to kill
MS Virtual Server before it becomes too popular?
At the moment, if you decide you need to buy
VMWare GSX (the current release of VMWare server) you might look at
VMWare ESX and think "You know what, i'm already spending on GSX, lets go the whole hog and get the 'Rolls Royce' solution". But when you can get VMWare server for free, people will begin to think "You know what? I think I'll make do with that and keep the balance sheet clean"
Some good news for security researchers from this news though - creating sandboxes to do secure tests just got a whole lot cheaper.
A walkthrough of the steps needed to join an OS X 10.3 or 10.4 client to a Windows 2000 or Windows 2003 domain.
Any time you see a
![Star [*]](/emoticons/emotion-30.gif)
symbol in the text, this is a link to a screenshot of what is being discussed.
Setup (on the Windows DC)- Open Active Directory Users and Computers (ADUC)[*] and decide on a location for the Apple Mac's computer account. Best practice suggests creating an OU for Apple computer accounts.
- Create a computer account, giving it the name that you want to use for the Apple computer on your network - do not assign a GUID to make it a 'managed' account.
- Close ADUC
Setup (on the OS X client)- Login with an account that has admin access to the computer.
- Open System Preferences and open the Sharing tab.
- Check that the computer's name is the same as the one we just used in ADUC. [*]
- Click Show All
- Click Network. Select your active connection, and click on TCP/IP
- (If you are using DHCP then some or all of this information is possibly already delivered by your DHCP server - check with the DHCP admin)
- Type in a suitable IP address, subnet mask, router address.
- Type in a DNS server address - ENSURE that at least the first DNS server in the list corresponds to an Active Directory DNS server.
- Click on Search Domains, Fill in your active directory domain.
- Click Apply Now.[*]
- Click Accounts, then click Login Options, authenticating with your LOCAL admin account if asked.
- "Under Display Login Window As" select "Name and Password".[*]
- Close System Preferences.
Testing that the client computer can "see" the network.
- Open the finder, and navigate to the utilities folder inside applications.[*]
- Open the terminal, and ping domain controllers by NETWORK NAME to ensure that DNS resolution is working properly within your domain.
- Ensure that name and IP are resolved correctly and that the ping actually works. [*]
- Stop the ping and close the terminal when done.
DO NOT TRY TO PROCEED IF THE ABOVE STEP DOES NOT WORK!
Binding the Mac client to the Windows Domain - Run the directory access tool, which is also in the utilities folder.
- Tick "Active Directory", then click Configure. [*]
- Fill in the Fully Qualified Domain Name of the Active Directory namespace (note, NOT the Active Directory Domain Controller!).
- Fill in the Computer name of the Mac. This should be the same as the one we setup earlier in ADUC on the Windows Server, and configured the mac to use in system properties. [*]
- Click BIND. Authenticate with your local Admin password if asked to do so.
- Next, fill in the details of a Windows User Account with permissions to add computers to the domain. Typically this will be an admin's account.
- IF you DID NOT pre-create a computer account for the Apple Mac, then fill in the Computter OU with the details of where you'd like the account to be created, using standard LDAP notation.
- If you HAVE pre-created a computer account, then leave this as it is.
- Ensure that both tickboxes are ticked.
- Click OK [*]
The client will now attempt to bind to AD and join the domain.
- If you HAVE pre-created a computer account then you should be asked if you wish to use an existing computer account. Click OK, because that is exactly what we're trying to do. [*]
- When the operation is finished, you can close Directory Access by clicking OK.
- At this time you can also click Advanced Options to inspect and configure custom settings. I strongly suggest leaving these alone if you don't know what they mean or why you would want to change them. [*]
- Logout.
If all goes well you should now be greeted with a login window that expects you to type in your username and password [
*] instead of selecting from a list.
You should now be able to log in with an Active Directory account by typing in the username and password in the traditional manner, and you can also login with a local account by specifying their username and password in the same way.
Remember the assumptions for this series of articles - OS X 10.3 or 10.4 clients...
Q. Can you walk me through how to join an Apple Mac to my Windows AD domain?
Yes! I've written a seperate guide on how to do this, as there are quite a few steps. Enjoy!
Q. How can I manage user account settings? Can I use GPOs?
No! Account management works rather differently in OS X than it does in Windows. OS X does understand things like password policies, permissions, group memberships and the like so this basic level of access can certainly still be set from your Windows Server.
Q. I'm using ISA Server, and my Mac users can't connect to the Internet as it won't accept their password!
You need to enable Basic Authentication on the ISA Server to enable Mac clients to present login credentials. Your users should use their own user account details as they would to log in, and can save them in the keychain if they find they are being repeatedly asked for them.
Q. Do I need to worry about Anti Virus software on Macs? There isn't much choice!
While I've always denounced people who claim virus infections are impossible in OS X as ignorant, and I still stand by that, the current risk to Mac clients is substantially lower than it tends to be on Windows machines. As such, I wouldn't advise spending a lot of time or money on AntiVirus software for Macs.
If your current site-licenced AntiVirus program has a Mac version then by all means install it. If not, and you'd still like to do something, consider ClamXav an open source Virus Scanner for OS X that should be quite ample for most needs.
And remember, the best defence against viruses, trojans or anything else, and regardless of whether you use a Mac or Windows or whatever, is your brain - think before you allow strange code to run from your admin level account!
Q. What sort of access to email will users on an Apple Mac have on my network?
This largely depends on what email server and clients you wish to use. Assuming you have Internet access from the mac clients, the simplest method is to use webmail access if your email server offers this facility.
If not, you can consider using the standard OS X mail client to pull down messages. Concerns for this method are privacy - each user needs their own OS X client account for this to work, and integrity - email apps on both your Windows and Mac clients need to leave messages on the email server in order that they are available wherever a user logs on. This means that using the basic Apple and Microsoft email apps in their default pop3 setup becomes complicated.
Ideally, if you use Microsoft Exchange to run your email system then you might be able to use Microsoft's mail client for the Mac, Entourage, to allow Mac users to have a similar access to their email accounts as they enjoy with Microsoft Outlook in Windows.
Q. Is it possible to link an OS X server to AD for authentication - e.g. as a domain member server?
Yes it is. I discuss briefly how I've done this in another article in this series.
The scope of how to do it is beyond this kind of article because there are too many "it depends on your current design and what you're trying to achieve exactly" moments, but it most certainly can be done.
More Posts
Next page »