Slashdot Mirror
Apple Responds to Exploit
Dave Schroeder writes, "This isn't so much of a root vulnerability as a default configuration that trusts the integrity of the local network services. This functionality has been around since NeXTSTEP, and is designed to allow for auto-configuration of new servers/machines brought into the network. The quick 'fix' for the vast majority of users who choose to implement it is to uncheck LDAPv3 and NetInfo altogether in Directory Access. Or, if LDAP services are used, just uncheck 'Use DHCP-supplied LDAP Server' in LDAPv3. ... One could argue that these features should be off by default, but if they are, it kind of wrecks the whole auto-configuration scheme." This sounds related to a great new feature in Mac OS X Server 10.3/Xserve called "automatic setup" that -- for machines that come with it preinstalled -- will get their address and LDAP server via DHCP and look for configuration files, and automatically configure the entire server, without any interaction beyond plugging it into the network and turning it on.
Is nothing but an Apple apologist. Pretty sad that someone can be so suckered into something. Apple is OK, but they aren't perfect (no company is).
The quick 'fix' for the vast majority of users who choose to implement it is to uncheck LDAPv3 and NetInfo altogether in Directory Access. Or, if LDAP services are used, just uncheck 'Use DHCP-supplied LDAP Server' in LDAPv3.
Yes that should be obvious to Mac users
but it's as valid today as it ever was. There is a dichotomy between security and ease-of-use. Hitherto it has been impossible to have the one and the other simultaneously. Choose one.
Apple choose ease-of-use, and get criticised for leaving an open security "hole". Microsoft choose the same, and get criticised for (well, just about everything except wonderful marketing), and Linux chooses the other, and is criticised for poor ease-of-use.
That's not to say it's impossible, but it needs more than the current level of effort that goes into multi-node design. Apple is taking the first steps, and they've been somewhat burnt. Let's hope that doesn't discourage them from carrying on down the path... Unix as a genre can only learn from a successful easy-to-use and secure implementation of multi-machine computing. The thing is that you only learn by trying....
Simon.
Physicists get Hadrons!
Realistically, an issue trusting the LDAP server that your DHCP server points you at?
What is the world coming to?
Do I need to manually verify every single setting supplied to me by my DHCP server because I don't trust it?
These days, the internet is not a safe place, we all need to be more than just a little paranoid - but are you paranoid enough?
Visit CryptoGnome in his home.
It's about damn time they found an explot for an Apple computer!
Goo goo g'joob.
No matter what sort of spin Apple puts on it, it's still retarded of them to trust LDAP to the point that UID=0 is trusted to be root.
Still, I don't think that this exploit is really that easy to take advantage of... the circumstances which would lead to it are fairly limited for now (until WiFi is as pervasive as air, anyway).
This is horrible... First the machine comes with a pre-configured backdoor/exploit, and they want to leave it like this? Second, if you can just plug in the machine in a network, and have it totally configure itself, you've just killed a job for an IT guy... and we need all the jobs we can get...
;)
Oh, wait... once the new machine gets owned by some script kiddies, then the IT guy gets called... okay... phew... nearly thought that a job was eliminated... nevermind... as you were...
---
Programming is like sex... Make one mistake and support it the rest of your life.
I wonder what new bug is waiting in their "automatic setup" to bite us.
.local tld with their Rendezvous/mDNS crap.
I was recently bit by their hijacking of the
(and when you call their support to ask why the Mac cannot see the local mail server called x.y.local, they have no idea and tell you to go around asking in web forums!)
So whatever they do and sell you as "making things easier", I would be very afraid to have it on my network.
This problem is rather simple... Operating systems such as Windows and MacOS X (don't troll me with Darwin) are commonly developed inside corporate environments, and a direct connection to the internet rather than a firewalled lan is the exception, rather than the rule. When the pointy haired boss walks in and requests a machine than can set up itself when he plugs in to the network, it gets delivered.
I expect retail software geared to the home user will continue to keep the tendancy of shipping flawed, because development often does not take place in a home environment. This goes for everything from Quake servers (remember ID's backdoor?) to all of the $40 photo-editing tools that are sold at Wal-Mart with marketing emphasis on the end user, with interfaces so all-encompasing, wizard-heavy, and dumbed-down that even I don't attempt to tech my low-tech friends how to use them.
...it's about *how it's handled*.
All software is, and will continue to be for the forseeable future, vulnerable. The question for the users and security people is, "How will company x handle themselves when a vunlerability is discovered in their product?"
This question, and its answer, is the most important issue when deciding who you trust with your data.
dmiessler.com -- grep understanding knowledge
really, from apples docs, you have to have a malicious dhcp server on your subnet. of course, someone could bring a rogue box into work, but this isn't on par with ms exploits. wouldn't a simple mac address filter at the switch level take care of all this. yeah, you could instal dhcpd on your authorized client, but this should also be a fairly easy thing to detect. i think apple is right, it's a configuration level solution.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
In many discussions, people downplay the importance of exploits like these because the attacker has to be on your local network to take advantage of the security hole. What about all of the mis-configured (or deliberately) open wi-fi networks out there? I think that wireless networking has changed the importance of "local exploits" by allowing somebody passing by to become a local entity on an open wi-fi network.
I was moderating, but this just burns me too much to remain silent.
I am not an artist. I'm bad at music, too. But I'm not much of a programmer, either. However, I know two people who are good examples.
First is my father. He has a doctorate in E.E., focusing on bottlenecks in computer systems, programmed assembly for TI in the 70s, and has been a professor in E.E. since long before I was born. He only uses Macs. We have one machine in the house that is not a Mac, this one, running Slack 7. He used Macs back in the "old days" for research because, for the money, they were the fastest things he could get his hands on. Now he uses them for work and at home because a) he's used to them and b) they are the best compromise between usability (he can still go into the terminal and screw around, but he can also use the very nice GUI when he doens't feel like typing everything or he's in a meeting with the Dean or the President of the university) and security/stability (it doesn't crash everyday and it has yet to get a virus). I use them for the same reason. And because I can't afford a computer of my own so I use what we have.
The other person is my music teacher. He's a professional musician as well. He's backed up Lionel Ritchie in concert before and plays bass in his own band. He also does some composing. On a Mac, only. He uses Macs because, back when he started, the best if not only composing software was for Macs. Since then, he's been sorta stuck with them. Not that he'd change, though, as my school has given him a PC and he hasn't found a program that works as well on it as his program for Mac (I wish I could remember the name, but alas, I can't. It's one of the major 2, though, I remember). Yes, he has been a "struggling musician" before. And yes, he stuck with his Mac through it because his Mac worked. Well.
Those are a couple of reasons why us "fruits" become blind zealots. It's sort of like being a Darwinian Evolution zealot. We get attacked by ignorant nay-sayers all the time, but we never lose sight of what we know works. Tell me, why are you such an ignorant bigot? Maybe you should get out of the house more...
No trespassing. Violators will be shot. Survivors will be shot again.
This problem seems little worse than other problems related to DHCP. If someone had access to your subnet and was able to configure a rogue DHCP server (e.g. to exploit the OS X ldap bug) they could just as easily return a rogue proxy as the default gateway or a tainted DNS server. If you are not vigilant about SSH warning messages or best practices you could be connecting to a server which is just recording your password and passing it along to the real server.
There may be something I missing, but this does not seem to be a problem with Mac OS X as much as it is with DHCP. DHCP in its simplest form is not secure. Using DHCP on a subnet requires trust. As with any other kind of security you will have to trust something, whether it is your computer or your home network.
I hope people do not blow this bug out of proportion too much.
The more they overthink the plumbing, the easier it is to stop up the drain.
Muslim community leaders warn of backlash from tomorrow morning's terrorist attack.
A friend of my brother's recently found this one in OSX: Link to his blog entry about it
Not SO bad, but could be bad, and it's considerably more dangerous for known Unix nerds.
I don't mind this at all.
:-)
No professional I know connects a server to the network BEFORE they configure security and network settings.
Shame on you if you do
In this case, the software is actually more vulnerable in a work environment, because it requires a compromised DHCP server on the local subnet. Most home users would probably notice if you plugged in another computer in their house. It's less likely to be noticed in a corporate environment, at least for long enough to compromise a few servers.
Besides, if it's possible for someone to sneak a compromised DHCP server on your network, you're basically screwed anyway.
I just tested it. It is real.
Maybe we deserve this world ?
.... turns out, if someone had RTFM, nobody would be talking about this.
You fool, have you even tried using a Mac lately? No? Just what I thought.
I'm a tech support (24+ years) who will have nothing but Macs in my house. Why? Because they work, don't crash, and my wife and son can't fuck them up.
After spending all day fixing other people's computer problems, the last thing I want to do at home is fix my own.
I'll stick with Macs.
This sounds related to a great new feature in Mac OS X Server 10.3/Xserve called "automatic setup" that -- for machines that come with it preinstalled -- will get their address and LDAP server via DHCP and look for configuration files, and automatically configure the entire server, without any interaction beyond plugging it into the network and turning it on.
Slashdotter A: "Are we being sarcastic?"
Slashdotter B: "I can't even tell anymore."
from the dictionary --
One who is zealous; one who engages warmly in any cause, and pursues his object with earnestness and ardor.
Doesn't sound so bad to me. Are you a Linux zealot? A Windows zealot? Does having a strong opinion make you a zealot? Or are you opinionless.
You are the lemming. Spewing the same tired crap about 'Mac zealots'.
Shut up, Anti-Mac zealot.
This isn't so much of a root vulnerability as a default configuration that trusts the integrity of the local network services.
That is a root vulnerability. You could perhaps trust LANs 20 years ago, you absolutely cannot trust them today, and any vendor that ships software that, by default, trusts the LAN is shipping software with severe security problems.
Hmm, as long as they don't have to right-click anything, I guess they should be able to handle it.
1. Don't use .local for your subdomain /etc/named/ (which effectively disables a large chunk of Rendezvous)
2. Disable Rendezvous' broadcast-based resolver by hacking on the stuff in
This doesn't sound much different from MS's way of leaving most services turned on and wide open by default.
It seems like Apple's public image prevents them from publishing more information about possible exploits. If it doesn't fit with the image of "easy-to-use!", they leave it up to someone else to publicize. It's a great idea to have automatically-configured machines, but these things need to be well-known. As is so often the case, education is the most important part of the equation.
Security and convenience do not mix. Apple is basically saying that their OS will continue to be insecure by default so users can enjoy convenience. PC's have a similar vulnerability, well ones that try to netboot by default. A rogue PXE server could feed a backdoored kernel to netbooting clients that mounts and runs the default root partition. Users, unless they pay attention to what their PC just booted off of, won't know anything is wrong. Netbooting is another convenience issue, who can argue with media-less booting!
WEP or not I think your wireless network would need to be much more complex that most to exploit this. At least on my Airport network (and probably by default) the wireless clients get their settings from the base station and the base station only. You can run and LDAP server all night and day in my front yard and it wont do you a bit of good. I'll probably ask you what youre doing when I mow the lawn though.
Malicious user sits 2 miles away with laptop and WiFi card and a good antenna pointed at your house. Waits for DHCP requests to come across the network, sends responses, and if lucky, gets one your clients to recieve its response before your base station's. That's all there is to it.
While I haven't tested this, I don't think that most base stations capture broadcast packets that look like DHCP requests and filter them out of the packet stream that they are sharing with the rest of the network. If this is the case, hurrah for the vendors that do this with their wireless AP's.
Mac OS X cannot be configured to only accept DHCP responses from one specific server. If it did have this ability it would be another way to mitigate the risks of this vulnerability.
Given the description you provide, your network can be had. Better to be safe than sorry and disable the settings that allow this vulnerability to exist.
well it's not likely to be a problem at home..
but mac notebooks are used regularly at public wlans as well(resteurants, hotels, some guys network that just happens to work from the bus station & etc)..
world was created 5 seconds before this post as it is.
Dammit, I leave my screen unattended for a couple of minutes and get baggy pantsed. :-) It's the first time (and I hope the last) - though while the moderation is fair enough it could just as easily have been +1, funny if the moderators knew their jargon file...
"'I pass the test,' she said. 'I will diminish, and go into the West, and remain Galadriel.'"
- JRR Tolkien.
Before anyone says "macinista", I've been using computers all day every day for 25 years now (since i was eight or so), and was a commodore man if you must know. I only got my first mac about two years ago. However, I will no longer have anything but a mac in my house because MacOS X based macs do everything I need - including a high quality X server - and never, ever, break. I'm a Solaris admin all day for a very large company. I don't want to hassle with munged computers at home. I prefer to farm.
"He who would learn astronomy, and other recondite arts, let him go elsewhere. " -- John Calvin, commenting on Genesis 1
-- will get their address and LDAP server via DHCP and look for configuration files, and automatically configure the entire server, without any interaction beyond plugging it into the network and turning it on.
Reminds me of a user who left the Windows 2000 Professional CD-ROM in his CD-ROM drive, booted from it, and reinstalled Windows. Though, he did have to "answer a few questions" (i.e. Press R to reinstall Windows).
I'd say it's one more nail in Microsoft's coffin. Apple once again comes through with a sleek and efficient design. The process to accidentally reinstall the OS is completely automated!
I was browsing a local windows network I set up the other day and saw a shared folder that was NOT previously made shareable. It seems one of the new Windows patches re-enables the "shared documents" folder on the network, and in explorer it's misleading because it doesn't use the standard "hand-looking" shared folder icon. I am really sick of this intentional and misleading crap by Microsoft! Apple should set a higher standard in this area by making sure everything is straightforward and on high security by default.
You Idiot! What does your MUSIC teacher or composing software have to do with security? Go read insecure.org or something then come back and tell me that....heck just get a smidgen of intelligence and tell me that. I haven't run a mac in a while so can't say much but this looks to be a pretty dumb thing to not publicize and in doing so has drawn some dumb people.
In light of the recent Debian break in, where the core servers were rooted and a rootkit installed on other machines, and all this using ldap for user authentification, I think Apple is making a huge mistake. All it needs is a couple of apple machines to be rooted by an exploit based on this and Apple will be in the same sorry boat that MS is in.
(And for the zealots, I'm posting this from a G4 PB so STFU thanks.)
Ah ahem, several storage servers like Snap and etc also come with this 'feature'..
and those run Linux...
Don't Tread on OpenSource
Sure, just send fake DHCP requests until the basestation uses up it's IP address pool.
The signal takes around 0.107ms to get there, so about 0.214ms round trip + processing time to handle the packet and send a response. I see roundtrip delays (ping) on the order of 0.4 ms on my switched network and 2.5 ms on my wireless network. I think the odds are above zero that you could beat the DHCP server to reply in this scenario, and so long as they are, there is an issue that needs to be dealt with.
In the end, people are just making excuses about why the attack might be kind of hard to pull off. And I don't disagree, it is kind of hard to pull off generally speaking, and most people, they probably won't be attacked anyway. But just because most people don't get their cars stolen and their homes robbed doesn't mean we leave them unlocked.
The goal for me is to help people protect themselves, so the risk that is there, however small it may be according to some, can be reduced to zero.
I know Google uses Linux. Just to give you some confirmation.
--fetch daddy's blue fright wig, i must be handsome when i release my rage
name one?
scott king
ability to have your computer be self aware of the network then set the settings on the fly after plugging in, ie no going through a windows like setup applet
Pinch me if I'm wrong. You're really trying to claim that having a DHCP client on by default is a 'Mac' thing and that having to manually configure the box is a 'Windows like setup applet'??
Golly. I've got a Macintosh SE/30 here that I keep around because it's cool, and I have NetBSD on it. Should I wrap it in plastic? Will I catch a dose of stupid from it if I don't?
[o]_O
Since this is an autoconfiguration feature, why not have it on only for the first boot after installing the OS? This way the computer can autoconfigure and then when it is configured it turns the feature off again.
The interactive way to Go -- http://www.playgo.to/iwtg/en/
Malicious user sits 2 miles away with laptop and WiFi card and a good antenna pointed at your house.
A good directional antenna (or an omni-directional + extra power) may ensure that the hacker's broadcast gets to your house. For your signals to reach the hacker at 2 miles, a clear line-of-sight and some intel-quality snooping device is required. Not to mention no neighbors using their microwave.
Mac OS X cannot be configured to only accept DHCP responses from one specific server.
For WiFi, you can set it to talk to a specific base station of your choosing.
cheers- raga
The messenger service is used by many orginazations for alerts. Where I work, our servers use it to send alerts to those that manage them. Works well since, unlike e-mail, it will get immediate attention. A web browser that is able to execute scripts is much more complex and therefore venurable than one that just doens't execute code at all.
Get off it, when you provide services to the world, you open yourself to the poiibility of getting hacked. Look at Linux. Consider the holes in OpenSSH. Is it essential? No. Is it useful? Hell yes. When you run services that the whole world can get at, you run the risk that there is a flaw in the coding that someone exploits.
Now, a valid solution to this is to have everything turned off and/or locked down by default. Ok, that works, but is a pain in the ass (read not easy to use) since you must then figure out how to enable everything and make it work. IF you have useful services enabled by default, it runs the risk they are venurable and can be exploited by default.
By the way, if you have to reinstall Windows continually, you need to get some skills with Windows. To fuck it up that often and that bad indicate poor skills of the user.
We had to track down and have arrested a haxs0r that was spoofing our router in an attempt to capture passowrds. He could have also easily done this with a DHCP server (well, had he been intelligent enough to make his software work). When tou run a network that offers some kind of public access, and there are a great many, you run the risk of infiltration. Plus, do you trust ALL your employees?
Security is not simple, and the balance between security and usability is even more complex.
I always wondered why there wasn't a sandbox approach to this automatic networking stuff... something to the tune of:
Plug new PC in, a daemon listens/pings for DHCP, LDAP, whatever... and if it finds it, politely asks the user if he/she would like to enable the service. If you have admin privileges you get to authenticate and proceed to register with the service or if in an untrustworthy environment you can choose to leave them disabled. If a new server is found at any time the process is repeated... though you could set a preference to ignore new servers as well.
See, sandbox. Requests are let in automatically but service must be opted into manually.
A fool throws a stone into a well and a thousand sages can not remove it.
In the end, people are just making excuses about why the attack might be kind of hard to pull off.
To be even handed, you should also point out that all OSes that pick up routing info from a DHCP server, have a variant of this "hole". At the very least, a rogue server can act like a proxy and, examine and redirect your TCP packets anywhere.
And even if you do configure Linux to go to a particular DHCP server, how long do you think it'll take to dos the real server and put up a ringer in it's place to spoof all the clients?
This is not hard to pull of, especially when the exploit comes from within your subnet. Starting from scratch, folks with a good knowhow of DHCP, ifconfig, dos exploits, ip-spoofing, and TCP in general could have this setup and start expoiting any DHCP-reliant client in less than a day.
cheers- raga
If remote setup is spin, why is it in the documentation that was released for Panther when the OS was released ? See the server administration pdfs.
.
This isn't a new "exploit" - all previous versions of MacOS X and NeXTStep had this with NetInfo by design - thats for nearly 15 years. However, it requires specific non-default configuration to work ( the network directory does not have precedence over the local directory by default - what is claimed in the original web page announcing the exploit is wrong )
For this to work, someone with local access to the machine has to go and change the directory lookup order for authentication, so that the network directories override local.
This is one of a long list of "exploits" that fall into the category of "If I have local administrator/root access and misconfigure something in a specific way, then I am potentially remotely exploitable"
The UI in MacOS should definately warn you if you tried to make the change, but this really isn't the sort of thing you'd work people day and night to fix.
Before misleadingly filling your comment with "IETF", maybe you should read a few IETF documents and join their working groups yourself.
.local tld, and not only did the IETF never recommended that it be reserved for Apple's Rendezvous, but in fact, had "concerns about multicast storms resulting from site-wide mDNS usage, as well as concerns about cache pollution" (among others).
I will gladly admit that mDNS doesn't have to be crap in itself, and may be cool, but Apple's proposed implementation is NOT going through the IETF standards process.
And Apple IS hijacking the
What they eventually adopted in the standards track is LLMNR.
LLMNR also doesn't require suddenly taking over a widely used tld.
Also: "Rendezvous is an individual submission that is not a work item of any IETF working group, and is currently not an IETF standard. While it is possible for an individual submission to become an IETF standard, this is unlikely in this case because an existing WG (DNSEXT) is already working on a competing protocol (LLMNR), which has just completed DNSEXT WG last call."
See the LLMNR FAQ.
But Mac notebooks rarely get restarted... maybe for major system upgrades... not something people will be doing in a coffee-shop, if at all.
This exploit ONLY works at boot, and according to Apple, is even more unlikely over wireless due to the timing of when the Airport network is available vs. when the system tries to net config.
However, looking at the documents themselves (draft-ietf-dnsext-mdns-24.txt and draft-cheshire-dnsext-multicastdns.txt), it's not immediately obvious which one is farther along. They are both Internet-Drafts in the "standards track" category. I didn't realize that Microsoft's protocol was a work item of DNSEXT while Apple's was not.
main(c,r){for(r=32;r;) printf(++c>31?c=!r--,"\n":c<r?" ":~c&r?" `":" #");}
So Osama's not only against the American Way of Life, democracy, human rights and bikinis but also hates the Clintons? WOOT, Hillary for President! =)
Don't think of it as a flame---it's more like an argument that does 3d6 fire damage
Apple's got a ways to go before they're really on the ball with security. I generally run their security update feature every day; I just got the patches for OpenSSL and zlib a week ago. Also, there's a bug filed in OpenDarwin that works in Jaguar and, I'm disappointed to see, also works in Panther.
, p->pw_passwd,p->pw_uid,- >pw_gecos,p->pw_dir,
Run this as any user with an argument of any other user's username. Pay careful attention to the second field.
#include
#include
int main(int argc, char **argv)
{
struct passwd *p;
p = getpwnam(argv[1]);
printf("%s:%s:%d:%d:%d:%d:%s:%s:%s:%s",p->pw_name
p->pw_gid,p->pw_class,p->pw_change,p->pw_expire,p
p->pw_shell,p->pw_expire);
}
Don't bitch at me about publishing this. It's already available in the OpenDarwin bug list.
www.sitetronics.com/wordpress
The 10.3.1 patch corrects this flaw, but there is still no patch available for 10.2. This flaw was mentioned a month ago on various Mac websites, I should have done my homework.
Maybe we deserve this world ?
What version are you using? It works in 10.3.1 and 10.2.8. For me.
www.sitetronics.com/wordpress
When I ran the directory access utility, LDAPv3, NetInfo, Rendezvous, SLP, and SMB where all turned on. My question is, do I need any of them running? I am on a stand alone computer on a DHCP enabled cable modem.
The guy's anecdote is wrong? His father wasn't sucessful during those 'dark middle ages' when his Mac 'wasn't good'? His artist friend should arbitrarily change platforms to 'save' a couple hundred bucks(money lost after purchasing new software)?
I don't want anyone to switch to Macs -- trust me. Apple will be around a long, long time. They do not need to be the most ubiquitous platform -- If I never bought another computer, I could be happy with my last Apple laptop and my present software collection for a few decades - if not forever. Sure I'll fall behind the 'gaming world' somewhere around 'Doom 6' but I never said I wouldn't buy a new console...
We apologise for the fault in this post. Those responsible have been sacked. -- Signed RICHARD M. NIXON
agree!!
Calling the autoconfig "feature" a root exploit is no different than calling the Win9x login one either.
Here's another exploit you can ignorantly mod down: The telnet protocol is unencrypted!! The entire telnet session, including usernames and passwords can be sniffed.
If you have a user account that was present in 10.2, it stays as it was in 10.2 - i.e. the password is world readable and limited to 8 significant characters. If you make a new account in 10.3 or even change the password of an existing account that was brought over from 10.2 to 10.3, then the new password handling will take effect: shadow passwords and a larger number (I don't recall how many) of significant characters.
What is not fully documented is that if you have multiple network locations, you have to deselect this checkbox for each location. Fortunately, this is straightforward since there is a network location pull down menu right above the checkbox.
Note that this means you can leave it checked for trusted networks but uncheck it for untrusted networks.
Bitch at MS for suggesting a non-standard .tld for private domains.
.local for SBS. Why not? It's a perfectly natural choice for an internal domain. That's why I had choosen it many years ago, like many other netadmins. If MS does the same I have no objection. It is perfectly valid and doesn't break anything.
.local as a local tld and it is widely used.
.local
I do like bitching at MS, but this is not a good occasion.
Yes, I discovered yesterday that MS suggest
There is nothing "non-standard" in using
The way Apple uses it does break valid existng TCP/IP functionality.
Apple's simply following the Zeroconf RFC, which specifies
I can also write an RFC, not listen to the objections, and follow my own RFC whatever the consequences. It wouldn't make my RFC a valid Internet standard.
This could have been just a little glitch in OS X. But the way they treated it, they appear to be just as arrogant as MS.
..for vulnerablities. "We're just trying to do it FOR you".
Joe
"Artificial Intelligence usually beats real stupidity."
The whole point of network account management is to easily allow the network administrators to have administrative rights on the machines on their network.
/me wonders about Kerberos and DNS SRV records ...
Most any LDAP authentication setup on a unix system will allow a uid=0 user defined only in LDAP to log in (and essentially be root). That's the whole point.
The problem that needs to be solved is making this both secure (preventing rogue DHCP/LDAP servers causing exploits) yet easy to set up.
One possible solution would be to require TLS and SSL certs signed by a (manually-installed) CA cert.
What was your proposal?
* Anything excludes most major Windows-based OEMs. :D
I have to disagree with this particular statement. I attempted to install Photoshop by dragging the Photoshop.app just the other day and it complained copiously about missing/wrong-version stuff, and quit before it finished starting.
.app. If I decide I hate something, I can just trash it and be done (Useful for MSIE). I save a lot of time not going to Start > Control Panel > Add/Remove Programs 3x a day.
As for your general point, yes, at least 90% of the apps on my machine are one
It seems only the truly huge apps like PS, Dreamweaver, MS Office, need installers. A lot of apps, the official AIM client (I know, I know--suck) being one example, can be installed by dragging the executable, even though they're distributed with an installer. I know this because I keep that client stored in a DMG whenever I'm not using it due to its buggy, slow nature).
Hey. Email me if you get a chance.
About Directory Access
Directory Access determines which directory services a Mac OS X computer uses and how it connects to specific directory domains. Directory Access determines how the computer discovers network services. Directory Access also defines search policies for finding authentication and contacts information in specific directory domains.
For more information about directory services, network service discovery, and authentication and contacts search policies, click "Tell me more."
Get the advice of a network administrator before changing Directory Access settings. If your computer is at home, you shouldn't need to change settings in Directory Access unless you are setting up a home network with a server.
If you are a network administrator and want help changing settings in Directory Access, open Directory Access and choose Help > Directory Access Help.