|
Softpanorama |
May the source be with you, but remember the KISS principle ;-)
|
Authentication is a means of access control that ensures that user are who they claim to be. Through password protection, security tokens or other means, the authentication process is intended to avoid the possibility that unauthorized persons might gain access to internal enterprise resources.
Authentication is not limited to Unix servers, of course. WLANs have proved to be particularly difficult to secure.
Contrary to popular belief, Unix passwords cannot be decrypted. Unix passwords are encrypted with a one way function. The login program accepts the text you enter at the "Password:" prompt and then runs it through a cryptographic algorithm. The results of that algorithm are then compared against the encrypted form of your Unix password stored in the /etc/shadow file.
On a more technical level, the password that you enter is used as a key to encrypt a 64-bit block of NULLs. The first seven bits of each character are extracted to form a 56-bit key. This means that only eight characters are significant in a standard Unix password. The E-table is then modified using the salt, which is a 12-bit value, coerced into the first two chars of the stored passwd. The salt's purpose is to make precompiled password lists more time consuming to use. DES is then invoked for 25 iterations. The 64-bit output block is then converted to a 64-character alphabet (A-Z,a-z,".","/") string.
Unix password auditing software uses wordlists to implement a dictionary attack. Each word in the wordlist is encrypted using the algorithm described above and the salts from the password file. The results are then compared to the encrypted form of the target password.
To ensure better password security your use the following measures:
Tip: Errors in the /etc/passwd file can cause many problems including the inability to login as root. The pwck command is a quick way to test the file and should be run whenever you make manual edits.
|
|||||||
Just released, this prescriptive guide shows IT Pros how to use Microsoft Windows Server 2003 Active Directory for both authentication and identity storage within heterogeneous Microsoft Windows and UNIX environments.
Microsoft released a pretty big guide on how to do this (make UNIX systems do authentication and authorization through AD). You can pick up the current version here.
Microsoft announced at TechEd US that the team which built that guide is revising it to explicitly support HP-UX 11 (i.e. they're going to test with HP-UX systems, include the exact commands to be issued there, etc.).The current guide, called "version 0.9", supports Solaris and RedHat; see the guide itself for the specific versions tested.
_____________________________
Jason Zions
Microsoft Corporation
Disclaimer: All information is provided as-is.
John Christian john.christian at TheCReGroup.com
Wed Sep 15 16:57:00 EDT 2004
SUMMARY: Solaris login based on Windows Domain? [Original post at bottom] Thanks for the input: Debbie Tropiano, Bousquet Francois, Alan Pae, Chris Pinnock, Victor Schrader, Tristan Ball, Darryl Baker We now have some new topics and directions to research. The biggest disappointment was that (according to Chris) Solaris with RADIUS is not supported yet. Looks like we'll need to dive into LDAP or Kerberos if we're serious about addressing this issue. Of course NIS or NIS+ related is possible, but what little NIS I see out there is slowly disappearing. Below is a collection of the replies with some additional links at the bottom. >>>>> It may be more than you want or need, but we use Ganymede (http://tools.arlut.utexas.edu/gash2/) here and using it allows up to have logins that authenticate both for Windows and Solaris. It's open source, so perhaps it'll give you an idea of how it's done (no, I don't know the internals). >>>>> Look for LDAP I've just installed a Samba PDC with an LDAP backend to connect my Windows Server and I am using pam_ldap to authenticate Solaris to LDAP. This creates a centralized authentication for both types of server. The system is secure with SSL encrypted connections and standard with LDAP. If you are not using Solaris 7 or minus or Windows NT 4.0 you might also consider using Sun iPlanet (Sun LDAP server) and get support from Sun for installation. >>>>> Although I've never used it, you might want to look into: http://www.vintela.com/products/vas/ <http://www.vintela.com/products/vas/> also, I think the Sun Blueprints site might have a doc on this subject. [ed note: I did find a few docs which are listed further below.] >>>>> A1: It is possible with Kerberos. Active Directory is Kerberos underneath. A2: You would need to have login linked against a radius library - possible on FreeBSD but not on Solaris at the moment. >>>>> Supposedly (have not done this myself yet), MS has 'Services for Unix' that will let W2K+ be a NIS master with passwd syncing between the 2 worlds. I have been using it, but not with NIS (yet). Out of the box (it is free) it has Korn shell and functions as a NFS server in parallel with CIFS shares. I have a mixed network of Solaris X86, various Linux versions and Windows machines the idea seems attractive to me. If you play with it let me know how it goes. >>>>> Checkout the windbindd system that is part of samba-3. You don't need to use samba, the winbindd part hooks in as a NSS modules. >>>>> If it is a XP domain you could use the XP server as an LDAP server. >>>>> Additional information that needs to be digested: Extending Authentication in Solaris 9 with PAM (part1) http://www.sun.com/blueprints/0902/816-7669-10.pdf Extending Authentication in Solaris 9 with PAM (part2) http://www.sun.com/blueprints/1002/816-7670-10.pdf Solaris and LDAP naming services http://www.sun.com/books/catalog/bialaski.xml [original post follows...]
As with the procedure for authenticating Linux against Active Directory and providing Kerberos-based SSO with Apache, there are a few steps to be performed. Some of these steps are performed on the Active Directory side, some of them are performed on the Solaris 10 system.
This procedure assumes that you are using Windows Server 2003 R2; if you are using a previous version, the LDAP attribute mapping will need to be modified to match the schema extensions found in Microsoft’s Services for Unix (SfU) add-on product.
Hi. I don't know MS AD specific regarding LDAP implementation (perhaps they have more or less standard one) but for OpenLDAP I used defaults when building pam_ldap and nss_ldap. Both clients and server are Solaris 9. What sort of problem do you have exactly? Otherwise it is very difficult to help...
[PPT] Windows and Unix Account Management and Authentication Integration File Format: Microsoft Powerpoint 97 - View as HTML Kerberos Authentication. Active Directory. SFU NIS Extensions. LDAP Queries ... SFU NIS Extensions.
[Jan 24, 2005] Hackers eavesdrop on phone networks to steal data - Computerworld
Computer hackers have taken to stealing data the easy way -- by eavesdropping on phone and e-mail conversations to find the keys to seemingly impregnable networks, security experts say.
The danger of attacks with insider information was illustrated earlier this month with the arrest of a California man accused of breaking into mobile phone network T-Mobile USA Inc.'s database and reading e-mails and files of the U.S. Secret Service, and by the exploits of a hacker who breached a hospital's database and changed mammogram results.
The nature of threats to network security has changed as sophisticated hackers learned to tap into sensitive information flowing through telecommunications servers, especially those that provide wireless and Internet access.
"Telecom providers are probably one of the main targets for malicious attackers because they control communications for everybody," said Ralph Echemendia, head of Intense School, which trains executives in network security risks.
Hackers may con their way into a phone network by posing as phone company tech employees to get passwords into the network. Then they could essentially tap phones or search for personal data like text files or even camera phone photos.
"[Hackers] will sit there and listen in, waiting to get valuable information," Echemendia said. "Once they have a foothold on one system, they go through the same process to find other hosts."
Security experts at Intrusic Inc. captured 4,466 passwords and 103 master passwords allowing global access to corporate databases while monitoring just one Internet service provider for a 24-hour period, Intrusic President Jonathan Bingham said. "It's like stealing candy from a baby," he said. "The malicious attacker will assume the identity of a person whose password they have stolen through this passive sniffing, and they end up entering this organization as a legitimate user."
Once inside, it takes the hacker seconds to set up back doors that allow access to the database at any time to do more spying, data theft or worse.
Most hackers, however, are after information -- passwords, Social Security numbers and birth dates -- that they can sell or use to penetrate bank and credit card accounts, Forrester Research Inc. analyst Laura Koetzle said.
"Telecoms and cable companies are pretty high on the list simply because of their huge customer bases," Koetzle said. "If they can crack T-Mobile's database, they can get user names and passwords for [millions of] subscribers at all once."
In a statement, T-Mobile, a Deutsche Telekom AG unit, said that it "quickly put in safeguards to prevent further access and began an investigation" after a hacker broke into its internal computer systems in 2003 and accessed data on 400 customers.
As more companies shift business functions to the Internet and allow workers to access secure systems from off-site, it becomes tougher to guard against insider attacks and easier for hackers to breach the systems, said Stan Quintana, director of managed security services at AT&T Corp. "All these types of environments are requiring a higher level of security ... of data in transit," he said.
The key to reducing damage from inevitable insider attacks is to constantly monitor data flow and train employees to guard passwords and access to computers, he said. Among the best practices AT&T advocates is that its customers periodically hack into their own networks, he said.
Security is a big, challenging topic, but everyone with server-side responsibilities should know the basic steps. Cameron outlines a number of ways to keep your user accounts clean and safe.
Security is hard. It doesn't sit still, and it's difficult to know how far it needs to extend: if you don't watch yourself, you can end up believing that your boss needs to understand the beauty of elliptic curves when all he really wants is to make sure the custodian doesn't read his annual budget.
However challenging it is to keep up with all facets of computing security, a few areas have matured enough to be worth learning methodically. The first one I recommend to anyone working with Linux servers is account management.
Tend to your users
Many of the first wave of books devoted to Linux administration and programming included a chapter on "user management" or "account management." Their meaning was rather specific: how to set up and maintain the computing accounts and group affiliations for the people who use your host.At that time, "use" necessarily meant "log in to." Account management was all about working with commands such as
useradd,chsh, and so on, to configure Linux accounts that would be convenient for a user population dominated by fellow developers. /etc/passwd and its APIs were the focus of Linux experts.Those times are long past, and the first recommendation I make for most servers is to eliminate most of /etc/passwd. What I mean is this: For historical reasons, most e-mail servers, Web servers, file servers, and so on, manage their user access in terms of /etc/passwd. I think this is generally a mistake. It was a sensible practice earlier in our history, when one or two dozen engineers might share a high-end workstation. Conventional /etc/passwd practices are a mistake, though, when one e-mail server might handle mailboxes for tens of thousands of users, for most of whom computing is just another utility like the water fountain or telephone system.
It's certainly possible to rely on /etc/passwd. It's been patched and tweaked enough to handle surprising workloads. It shouldn't have to, though. If you move user accounts into a dedicated datastore, such as an LDAP (lightweight directory access protocol) or even an RDBMS (relational database management system) datastore, you gain advantages in scalability, security, and maintenance. Restrict /etc/passwd to the few developers and administrators who truly need logins.
This practice gives a big advantage in security, because the duty cycles of service (e-mail, Web, and so on) users are entirely different from those of developers. Once you have burned in a new server, its /etc/passwd shouldn't change often. It's an easy job to monitor it for any updates and, particularly, for tampering. If you're running a large server, though, you might have several new and expired e-mail account changes daily. You need to isolate those from the wider access that /etc/passwd gives.
Is construction of an alternate account datastore a serious recommendation? Yes it is, as surprising as that may seem. A lot of effort has gone in over the years to make very large /etc/passwds, filled mostly with login-free users, work properly. If you do decide to code your own account authentication, and you rely on such traditional e-mail programs as
sendmail, you might well find yourself writing changes for SMTP, POP3, and IMAP4 servers.Those obstacles generally incline developers toward using off-the-shelf software. My habit is to favor solutions others have written and that I can re-use. One difference with these industrial-use servers, though, is that I often need to customize them anyway -- to set up special message directories, logging information, or usage accounting, for example. What decides the issue for me is a preference to modularize security considerations. I like to be able to manage developer and administrator accounts entirely separately from end-user services. By splitting off the latter from /etc/passwd, I can easily lock down either side without affecting the other.
Automate policy
Almost as important as separating developer accounts from user services is to automate policy. Establish specific, detailed processes for creating and deleting accounts, both developer (/etc/passwd) and end-user (e-mail, Web, database, and so on). While it's good discipline to capture these into executables, it's not strictly necessary. What is important is that the processes be understandable and unambiguous. Casual account creation and deletion always leaves security holes. Review your processes with your human resources, customer support, or other pertinent departments. It's hard to appreciate how crucial this is unless you've lived through the alternative.When you don't have written procedures for adding and removing users, the invariable result is that a new worker shows up on Monday, say, and by Friday still can't get to his or her company files. Or someone resigns, says goodbye at the holiday party, and is still retrieving occasional corporate assets as February begins.
One of the incidental benefits of account automation is that it encourages more thorough validation. If developers don't have a convenient way to configure accounts with different properties, they're quite unlikely to exercise applications that are supposed to differentiate those configurations.
I recently experienced this first-hand. I was called in on an emergency in which our implementation team had "correctly," in effect, allowed managers to review employee performance reviews -- even for employees they didn't manage! As ridiculous as that sounds, it's typical of security issues. It had even been flagged a couple of times during analysis and design reviews. Every time it was brought to a decision-maker, though, it was part of a sufficiently large and muddy collection of problems that it was passed on without crisp resolution.
Only when a support specialist finally set up a concrete example of a general instance -- one with multiple managers, each of whom had multiple employees reporting in -- did the error get the attention it deserved. Save yourself last-minute dramas; make configuration of all sorts of user accounts routine and available for thorough testing.
Stay alert
The hardest part of security, at least for many of us, is to avoid doing dumb things. Security is one of the "weakest link" affairs, where a single loophole can make all the rest of your investment, however huge and well-planned, laughably pointless. To do security well, you have to stay on the alert for things that you aren't otherwise thinking about.U.S. government sites frequently exemplify the magnitude of that challenge. One federal agency, frequently in the news for security issues in the "anti-terrorist" sense, maintains a Web site where user passwords are displayed in the open, on the page for changing user preferences. Quite a few organizations address the frequency of lost passwords by assigning passwords based on more-or-less public information (for example, "your password is the first four letters of your birthplace, followed by the final two digits of your birthyear").
How can you avoid such catastrophic mistakes? Unfortunately, there are few systematic ways to succeed at such an abstract goal as "being smart." Among the useful steps to take, though, are study of the RISKS digest and disciplined engineering review.
RISKS is an online newsletter that Peter G. Neumann has been editing since 1985 (see Resources below). Reading it is excellent practice in thinking about how things -- security on your Linux servers, in particular -- can go wrong. Neumann makes the digest quite readable and entertaining, if occasionally macabre.
You should also acquire the habit of trying out your ideas on others. You might think of "software inspection" as no more than a way to spot misplaced punctuation in developers' source code, but it's actually a far more interesting and productive practice. In particular, inspections are a great way to organize peer reviews of requirements documents, Web sites, and all sorts of other artifacts. Stage inspections. See your work through the eyes of others. You'll probably learn a lot about the security, or insecurity, of your servers.
Conclusion
The Resources point to more reading on the subjects of hardening servers, Linux security, and inspections. While server security is an enormous subject, you can pursue the aspects this column describes quickly and inexpensively. If you haven't looked into these approaches already, you should; they'll improve the security of your operations a great deal.What problems of server security are hardest for you? "Server clinic" will return to the security topic at least a couple more times in the coming year. If you write to me or post your thoughts in our forum, I'll try to address your issues.
- "General System Security" is Chapter 5 from the online Hands-on Guide to Red Hat Linux.
- "OpenSSH key management, Part 1" is a good introduction to practical
sshuse (developerWorks, July 2001).
- "Addressing security issues in Linux" is an IBM whitepaper that discusses various security issues, outlines strategies for dealing with them, and lists IBM as well as non-IBM products that can help keep systems buttoned up.
- The RISKS Digest page provides access to subscription information and indexes to back issues of The RISKS Digest.
- LinuxSecurity.com is a community resource that points to valuable information.
- Software Inspections is a marvelous book on the subject. The discipline applies far more broadly than to just the "code reviews" the title brings to many programmers' minds.
- The Software Engineering Institute formally defines software inspections at its site.
- The SANS Institute is the ideal place to locate resources having to do with system administration, networking, and security.
- The IBM Security Web site contains an overview of security solutions, hardware/software, products, research technology, announcements, press releases, and more.
Sys Admin Magazine Using LDAP to Manage Unix Accounts Jeff Machols
User management is one of the most tedious tasks in a systems administrator's job. There have been some attempts to centralize user management with NIS and NIS+. NIS fizzled out because of its security holes, and NIS+ is not very straightforward to configure. So, what's the best way to centralize user management in an environment? The answer is looking more and more like LDAP.
LDAP (Lightweight Directory Access Protocol) is quickly emerging as the standard in hierarchical data, such as user and group data. LDAP servers are designed for an "update seldom, access often" scenario. One of the roadblocks LDAP has faced in gaining popularity as a centralized user management system is the effort to get client machines to securely authenticate users. In the past, this required writing custom PAM modules or trying to configure existing ones. However, as major Unix vendors are realizing the potential of LDAP, they are including clients in the operating system.
These built-in clients also contain the PAM libraries for authentication with an LDAP server. These client-side applications are included in the Solaris 8 and 9 distributions, as well as AIX 5L. HP-UX has a free software depot called ldapux that can be found at software.hp.com, and Linux has an RPM called nss_ldap. These clients include built-in libraries, so fears about writing C programs to authenticate or having holes in your security can be put to rest.
Server Considerations
Several LDAP servers are available on the market. Currently, the two predominant servers are OpenLDAP and Sun One Directory Server (formerly iPlanet). If Solaris is your OS for the LDAP server, Sun One Directory Server is the way to go. It is currently bundled with Solaris 9, and version 5.1 is free up to 200,000 entries (each distinguished name in the server is considered an entry). Sun One Directory Server is also available on HP-UX, AIX, and Linux. OpenLDAP is free and can be compiled on most flavors of Unix, but configuration and compilation take a little more effort.
The LDAP community has created an RFC (RFC 2307) to define a schema for Unix to use LDAP as an NIS provider. The schema defines all the previous maps that were available for NIS, so it is aptly named the nis.schema. This schema comes loaded in the standard installation of Sun One Directory Server. If you are using OpenLDAP or another server, be sure the schema is loaded into your server. As part of the nis.schema, the following services can be centralized with LDAP: password, shadow password, groups, and netgroups. Other services, such as DNS, are also available with LDAP, but that is beyond the scope of this article.
The default communications for the LDAP server and clients are clear ASN1 strings. All information is sent in clear text. This is the major problem with NIS, so be sure you don't make this mistake with your LDAP implementation. I recommend using the default communication method during the installation and initial test. Once you have tested the server and the clients, and are comfortable with the configuration, switch to SSL.
When configuring your clients, you will need to specify a search base. This is the point in the directory at which the client starts looking for NIS entries. This functionality allows you to separate Unix user and group accounts from other parts of the directory. For example, you may want to set up a group with a distinguished name (DN) of "ou=unix nis, dc=mydomain, dc=com". You can segregate this more if desired, but all Unix accounts would be under this organizational unit; this DN would be your clients' search base.
Segregating your NIS environment inside the LDAP server will give you two advantages. The first advantage is speed. When you specify the start DN, your clients will not have to search through the entire directory to find the accounts, which will help performance. The second benefit is administrative flexibility. You can give account administrators access to a specific area of the server, instead of to your entire directory. You can have different search bases for different Unix clients. If you do this, note that user accounts will need to be replicated in both search bases to have access to the different clients.
Adding NIS Entries in the LDAP Server
To add a Unix group into LDAP, you will need to create an entry of object class posixGroup. The attribute gidNumber corresponds to the Unix GID number for the group. Since the local and LDAP groups are treated the same, it is important to keep all the gidNumbers in LDAP as well as the local GIDs unique. The Full Name, or cn attribute, is the name of the group. The memberUid attribute correlates to the users who are part if that group. Each user will be an additional attribute in the group's entry. In the example below, users jdoe and scarter are part the admins group:
dn: cn=admins, ou=unix nis, dc=mydomain, dc=com gidNumber: 900 memberUid: jdoe memberUid: scarter objectClass: top objectClass: posixgroup cn: adminsHere are the instructions for adding entries. If you are unsure how to add an entry into an LDAP server, copy the above entry information into a file on the LDAP host and run the following command:
$ ldapadd -D "directory_manager_dn" -w "directory_manager_password" -f filenameYou can assign users to groups in two ways; the first way is described above. Each posixGroup entry will have a list of users. The second method is to assign gidNumbers for each group in the posixAccount entry (described below). These methods can be intermixed but, for consistency, I recommend choosing one method. When you create a new user, you will use the object class posixAccount and shadowAccount along with the standard person object classes. The uid attribute is the user login name, and the uidNumber is the user's Unix uid. The gidNumber attribute lists the groups to which the user belongs. When you specify the password, there are multiple ways to store the ciphered password. For authentication on Unix, you must use the crypt method. This is accomplished by using the {CRYPT} tag in front of the cipher password:
dn: uid=jdoe, ou=unix nis, dc=mydomain, dc=com givenName: John sn: Doe userPassword: {CRYPT}QGxOG7iX3lbLU loginShell: /usr/bin/ksh uidNumber: 343 gidNumber: 900 objectClass: top objectClass: person objectClass: organizationalPerson objectClass: inetorgperson objectClass: posixAccount objectClass: shadowaccount uid: jdoe cn: John Doe homeDirectory: /export/home/jdoeAlong with specifying the password, you can also set password options such as length, minimum characters, expiration, etc. All of the attributes in the NIS schema can be found in RFC2307. With replication and the correct setup, your LDAP environment will be reliable, but there are still some users you should keep out of LDAP. The most obvious is root; this user should always be kept local. I suggest keeping application users local, so even if the network goes down, your applications will still be able to run (assuming they don't need the network).
LDAP supports the use of netgroups, so you can control user access to individual servers. The object class is called NisNetGroup and uses the same "triple" notation as NIS. Each entry has three fields: host, user, and domain. If you leave a field blank, it allows complete access. In the entry below, jdoe is in the appuser netgroup for all servers, all domains. The user scarter is in the appuser netgroup only on the server mars, and all users are in the appuser netgroup on the server pluto:
dn: cn=appuser, ou=unix nis, dc=mydomain, dc=com nisNetgroupTriple: ( , jdoe , ) nisNetgroupTriple: ( mars , scarter , ) nisNetgroupTriple: ( pluto , , ) cn: appuser objectClass: top objectClass: nisnetgroupThe passwd command can be used to change the password in the LDAP server. The only change is an extra switch -- the -r option. To change the password for user jdoe:
$ passwd -r ldap jdoeConfiguring the Unix Client
Unfortunately, the client setup is different for each version of Unix. There is an effort on the Apache Directory project to document the steps for configuring each client. As each configuration is tested, the documentation will be posted on the Directory Project site. I will use Solaris 9 as an example for the rest of the article.
The Solaris 9 clients will run a daemon called /usr/lib/ldap/ldap_cachemgr, which will handle all communication between the client and the LDAP servers. The clients use a configuration profile stored on the servers and periodically update themselves against the profile. This allows you to make a configuration change once that will be populated out to clients automatically. To do this, you need to create an organizational unit for the profile to reside in. Add the following OU:
dn: ou=profile, dc=mydomain, dc=com ObjectClass: top ObjectClass: OrganizationalUnit ou: profileNext, create the profile. This is accomplished by using the ldapclient command built into the OS. This command will create LDIF output that will be added as an entry into the server. The following example will create a profile that will configure the clients to use multiple servers (for replication and failover) and map where in the directory the NIS information will be stored. This command can be run on any Solaris 9 machine regardless of whether it is a server or a client:
$ /usr/sbin/ldapclient genprofile \ -a defaultSearchBase="ou=unix nis,dc=mydomain,dc=com" \ -a serviceSearchDescriptor="passwd: ou=unix nis,dc=mydomain,dc=com" \ -a serviceSearchDescriptor="group: ou=unix nis,dc=mydomain,dc=com" \ -a serviceSearchDescriptor="shadow: ou=unix nis,dc=mydomain,dc=com" \ -a serviceSearchDescriptor="netgroup: ou=unix nis,dc=mydomain,dc=com" \ -a authenticationMethod=simple \ -a credentialLevel=proxy \ -a "defaultServerList=192.168.0.155 192.168.0.156 192.168.10.100" > profile.ldifThe profile.ldif file will contain the entry information. Normally, you should not have to do anything to this file, but you can make changes before adding the entry, if necessary. When you are happy with the profile, add it to the server:
$ ldapadd -D "directory_manager_dn" -w "directory_manager_password" \ -f profile.ldifOnce the profile entry has been added, set up each of the clients to use it. On the client machine, run the ldapclient command with the init option. This command will configure the ldap_cachemgr; it will also copy the /etc/nsswitch.ldap to /etc/nsswitch.conf and start the client in the background:
$ ldapclient -v init -a proxyDN=" directory_manager_dn" \ -w "directory_manager_password" ldapserver_IP_addressIf the client does not start or you encounter other problems, you can add debug flags to get more information. Just add option -d 6 to the command for verbose output:
$ /usr/lib/ldap/ldap_cachemgr -d 6After ldap_cachemgr is up and running, you can test the connection to the server. It will be easier to test if you have at least one entry for each NIS component you are using. To get a list of entries the client finds, run the ldaplist command. You should see all the entries in your search base:
$ ldaplist dn: cn=admins, ou=unix nis, dc=mydomain,dc=com dn: uid=jdoe,ou=unix nis,dc=mydomain,dc=com dn: cn=appuser, ou=unix nis, dc=mydomain,dc=comOnce you get the client talking to the LDAP server, you can begin configuring the OS for user authentication. The first step is to add LDAP as a service in the /etc/nsswitch.conf file. The following nsswitch.conf file will support user authentication, groups, and netgroups in LDAP. If you are not using netgroups, replace the passwd: compat entry with passwd: files ldap and delete the passwd_compat entry:
# # /etc/nsswitch.conf # passwd: compat passwd_compat: ldap group: files ldap # # All other services are unchanged # netgroup: ldapIf you are not using netgroups, you don't need to change the /etc/passwd file. If you are using netgroups, you will need to add the name of the netgroups with access. You will also need to deny other net users. The following snippet can be inserted at the end of the /etc/passwd file to allow users in the netgroup appusers to log onto the server:
+@appusers:x::::: -:x:::::After the entry is added, run the pwconv command to update the /etc/shadow file.
You will need to add the LDAP PAM library to the /etc/pam.conf in order to authenticate. The library should already exist in /usr/lib/security; it will be called pam_ldap.so.1:
# # Authentication management # # login service (explicit because of pam_dial_auth) # login auth required pam_authtok_get.so.1 login auth required pam_dhkeys.so.1 login auth required pam_dial_auth.so.1 login auth sufficient pam_unix_auth.so.1 login auth required pam_ldap.so.1 # other auth required pam_authtok_get.so.1 other auth required pam_dhkeys.so.1 other auth sufficient pam_unix_auth.so.1 other auth required pam_ldap.so.1 # passwd auth sufficient pam_passwd_auth.so.1 passwd auth required pam_ldap.so.1 other account requisite pam_roles.so.1 other account required pam_projects.so.1 other account required pam_unix_account.so.1 # # Default definition for Session management # Used when service name is not explicitly mentioned for session # other session required pam_unix_session.so.1 # other password required pam_dhkeys.so.1 other password required pam_authtok_get.so.1 other password required pam_authtok_check.so.1 other password sufficient pam_authtok_store.so.1 other password required pam_ldap.so.1Conclusion
Besides GUIs supplied by the LDAP server, command-line clients also exist. These LDAP clients allow you to add, delete, and modify LDAP entries via the command line and LDIF files. This is useful for scripting or creating custom application to access LDAP.
With the built-in clients, secure connections, and the ability to build GUIs around the server, LDAP has become a viable solution for user management and authentication. Not only does it make it easier to administer users, but LDAP also allows much of the work to be moved to a help desk or level 2 systems administrator support.
Jeff Machols is the Manager of the Unix Administration team for a financial institution and the co-founder of the Apache Directory Project. He can be contacted at: jmachols@apache.org.
Copyright © 1996-2008 by Dr. Nikolai Bezroukov. www.softpanorama.org was created as a service to the UN Sustainable Development Networking Programme (SDNP) in the author free time. Submit comments This document is an industrial compilation designed and created exclusively for educational use and is placed under the copyright of the Open Content License(OPL). Original materials copyright belong to respective owners. Quotes are made for educational purposes only in compliance with the fair use doctrine.
Standard disclaimer: The statements, views and opinions presented on this web page are those of the author and are not endorsed by, nor do they necessarily reflect, the opinions of the author present and former employers, SDNP or any other organization the author may be associated with. We do not warrant the correctness of the information provided or its fitness for any purpose.
Last modified: November 08, 2008
Solutions
(Score:5)We have had similar issues regarding Microsoft's Active Directory product at Amaa Fui. We were switching from a Unix based kerberos system to one that used Microsoft's.
Here are some solutions to the same problems you had. Firstly, you need to patch your w2k boxes to the latest pack. Then install the beta k5 updates from Microsoft beta w2k site. These updates remove the slight changes Microsoft made to kerberos, and thus makes it compatible with your other systems.
Once those are patched in, you need to install Heesi optimizer (This can be found on any download site), I recommend this, cause this would go through your AD configuration and kerberos setup and tell you exectly where your security is weak and so on.
Once everthing is in place, you can move to more secure passwords and corportation wide access to single passwords. But let me warn you, you still need different passwords on resources that are of a criticial nature.
Also ensure everthing is behind firewalls and if your using VPN install the latest patches from Microsoft site, We run OpenBSD and Ipsec, they work very well with the current configuration.
Our systems include, Windows 2k/nt, Linux i386/alpha/ppc, Mac OS 9/X, HP/UX, IBM AIX, Solaris and an old VAX system. All of them are maintained by the w2k based kereberos authentication systme and LDAP for directory stuff.
Everthing works well and I'm very satisfied, only concern we have is that Microsoft's version of kerberos is very slow to authenticate our user. This creates some problems, specially since some of our internal services have authentication decay in it, to solve this problem we just moved to better hardware, but this is something Microsoft has to solve on their own.
Good luck with your setup and hope this helps, if not you can send me an e-mail to, fadaboi@NOSPAM.riyaasath.com
Fadaboi Kesbe
Been there...
(Score:5)(http://slashdot.org/)
Authenticating users against AD with pam_krb5 works fine. Just list the DNS names of your Win2k domain controllers in the config file just as if they were normal Kerberos servers, and use the AD domain as the Kerberos realm.
When I did this, I still had local passwd and group files. But it should be possible to move that stuff into AD. You would have to modify the AD schema to include that info in the directory (that's not a task for the faint of heart). Once you do that, though, it's pretty easy to query AD from Linux.