Dealing with Mac OS X and NetInfo Problems?

newkid would like some assistance getting to the core of this issue: "Apple likes to refer to its server software as an industrial-strength server based on Apple's modern OS. However, there are serious flaws in the authentication system (netinfo): I am locked out of four of my remote servers (even root has been disabled, and that is unacceptable), and the instability is well documented here, here and here. I have successfully reinstalled one server and replaced another one with FreeBSD, but I have not decided what to do in the long run. What is your experience? Should I completely forget OS X for my servers and switch to something else? Or should I move to Panther (it uses LDAP instead of NetInfo to control user accounts)? I would like to know about your experience with OS X Server and if your have made the switch to something else." What experiences have you had with NetInfo on your Mac OS X boxes, and do you have any other hints and tips on recovering the NetInfo database in the event that it does develops amnesia?

flame on.

[seann]

evil weblog [webweavertech.com]
"DirectoryService: NetInfo connection failed for server 127.0.0.1/local."

"The solution was to restore the Netinfo database."

NO. the solution is to turn off "Net Info" in the Directory Access program located within /Applications/Utilities folder.
If you are trying to athunticate to a non-existing netinfo daemon in your domain, your going to get problems.

Turning off that option relieves the problems hinted at in this link. Please sirs, try this instead of blowing away your net info database, When I first got my powerbook 12" I had this same problem. I realized later on that I clicked "Net Info" in the Directory Access program, and it was trying to auth to a non-existant server.

Dear Cliff,

[reiggin]

Would you please stop turning apple.slashdot.org into a hints, tricks, and tips forum? You're 2 for 2 right now. This is "News for Nerds" not "Nerds helping Non-nerds."

Thanks.

Re:is this a troll?

[CodeBSD]

The last time I checked, OpenBSD was available, but not FreeBSD.

There is a FreeBSD PPC distro, but it only boots into single user mode as of now....

Re:Maybe Apple knows?

[gsdali]

Not that slashdot should be a purely GNU/Linux preserve. There are better place to ask this question though; Mac OS X Hints Forums [macosxhints.com] and Mac Fixit Forums [macfixitforums.com] spring to mind.

Good resource

[sld126]

Especially for 10.2 servers:
http://www.afp548.com

and specifically to your question:
http://www.afp548.com/Articles/system/n etinfobacku p.html

Re:Dear Cliff,

[Midnight Thunder]

That's the feeling I got. The best place to ask such questions is http://discussions.info.apple.com/ [apple.com] or even on one of the mailing lists at http://lists.apple.com/ [apple.com]. On the other hand the guy did get some informed view points on why what he is asking, is likley to be a security issue.

Re:One of the best features about the Netinfo syst

[sld126]

Root is disabled by default on Client. It is enabled by default on Server, which is the version he was asking about.

RTFP?

Re:Panther DOES use NetInfo

[sld126]

Local accounts are handled with NetInfo.

Network accessible accounts are handled with LDAP.

Re:Boot from CD to change root access

[Dixie_Flatline]

Many things in Panther use flat files before NetInfo. If you want to check, do a 'lookupd -configuration'. 'man lookupd' will tell you how to change the lookup order, I believe. Don't forget to do a 'lookupd -flushcache' after you're done.

Re:flame on.

[trouser]

OSX does use Netinfo by default for local login but the previous poster is quite correct in saying the Netinfo should not be selected in the Directory Access utility. This checkbox is for enabling authentication using a remote Netinfo server and can cause authentication problems including fantastically long timeouts with no on-screen error message when logging in.

I use LDAP authentication through OpenLDAP on a Linux box with local Netinfo as a fall back for a local admin account. It's been pretty flakey with previous versions of OSX, mainly authentication failures first thing in the morning on machines that have been left asleep at the login prompt over night. Directory Access used to have a lot of trouble working out what to do with itself when the machine woke up. Authentication failed but the Linux server logs tended to suggest that the LDAP requests weren't being made. Anyway, it all seems to work reliably as of 10.3

Are you really using NetInfo correctly?

[plsuh]

Not to minimize your difficulties, but Apple runs NetInfo internally at a very large scale. In the NeXT days NetInfo was used for large-scale deployments and was quite stable.

Any Mac OS X or X Server machine has a local NetInfo database, stored in /var/db/netinfo/local.nidb/. It serves as the local directory services store for user and configuration information for that machine only. In addition, a Mac OS X Server that is acting as a NetInfo master or LDAP server will contain at least one other NetInfo database usually named "network". This is stored at /var/db/netinfo/network.nidb/. It is used to provide user and service information for a larger network of machines.

Clients can connect via the native NetInfo protocol which is based on the SunRPC portmapper, or via LDAP. In either case the data are taken from the network.nidb data store.

The fact that you were "locked out" of four of your servers is very unusual. To properly diagnose this, more information is required. Which one (if any) of these four servers was a directory service server for the group. Was that one acting as an Open Directory password server? What measures did you undertake to re-gain access once the problem was detected?

By the way, Panther still uses NetInfo as a local directory services store. Passwords are no longer stored as crypt hashes -- they are instead stored as shadowed MD5 hashes in a separate location.

--Paul
Technical Training and Certification
Apple Computer
psuh at apple dot com

Re:Mixed experiences w/Netinfo

[moof1138]

If you are using 10.2 Server you do not need to have your network user's password hashes visible to anyone. All you need to do is use the Password Server that comes with X Server. In the ODA if you select 'This Server will provide authentication for other systems' or something much like that, then it will be enabled. Once you enable it and set users from Basic authentication to the Password Server, the password field of their user record becomes '********'. With 10.3 the Password Server can still be used the same way, but it can also morph into the back end of the new KDC.

Note that in 10.2 you can export your users from WGM as an XML file which can serve as a backup if the parent NIDB get hosed, but if you are using the password server you need to also back up the password server database.

Security hole: remote netinfo in OS X 10.2 server

[Permission Denied]

You are using netinfo on MacOS X Server 10.2 to authenticate clients remotely. This is a bad idea; anyone on a network served by your netinfo server can obtain the password hashes on all accounts and then run a cracker against them. Basically, this is like broadcasting your password file to the world.

To demonstrate: on any of your clients, type "niutil -readprop -t server_ip/network /users/username/passwd"
Substitute "username" with any username or read all the usernames. Hell, I'll script it for you:

#!/bin/sh
IP=your_ip
DB=your_db
niutil -list -t $IP/$DB /users | while read i u
do
echo -n $u:
niutil -readprop -t $IP/$DB /users/$u
done

The hashes are encrypted using the standard Unix crypt(3). You can then massage them into some format that Crack can read and let it go. Remember, any user with access to your network can do this.

I really thought it was quite irresponsible of Apple to release this software and recommend this configuration to users. It took them a good long time to fix it.

Panther (client) finally fixed this. You'll note that passwords are no longer stored in netinfo, but netinfo rather references a "guid" which in turn references a file that stores the password, readable only by root. This means that standalone Macs no longer give all users access to all password hashes. I understand netinfo will finally be fully deprecated in 10.3 server.

You also asked if anyone has had other problems with MacOS X Server: I would strongly recommend against their mail server software. It does finally store messages as discrete files on the filesystem, so some munging can be fixed, but message flags are still stored in some opaque binary format that tends to get corrupted. In fact, whenever 10.2 server goes down ungracefully, all flags on messages are corrupted on our mail server, and thousands of deleted (and purged) messages re-appear in all the inboxes. The particular machine is on a UPS, so this doesn't happen very often, but it happens whenever the machine is purposefully rebooted without first explicitly stopping the mail server.

The good thing about 10.2 server is that it stores the passwords using standard DES crypt(), which makes migrating from it very easy. A shell script like the one above can produce a password file readable by most any *nix flavor. 10.3 uses some bizaare format that I can't readily identify. Since a lot of the most important bits of MacOS are closed-source, you may have a very difficult time migrating away from 10.3 server if it uses something akin to the 10.3 client hashes (options are making all users create new passwords or spending lots of time reverse-engineering the hash and writing an equivalent pam module for another OS (I'm assumming this new hashing stuff is not in Darwin, as most things in MacOS where I needed the code were not in Darwin - but I haven't checked for this)).

Anyway, your best bet is to drop netinfo and start using LDAP. MacOS X (client and server) uses OpenLDAP, which doesn't have these security issues, is easy to migrate onto other OSes, and is open source (with no modifications that I can identify), so you at least have the ability to fix your own problems if you're not scared of some coding. For example, the OpenLDAP version that ships with MacOS X 10.2 has a bug in that TLS_CACERTDIR directive does not work. I was able to identify and work around this since I had access to the code.