Posts Tagged ‘authentication’

Windows 7: What a difference time makes!

Wednesday, February 6th, 2013

While visiting our Santa Monica office I called on a client having difficulties connecting his Windows 7 computer to his file server. I expected this to be a pretty straight-forward issue since the environment was pretty simple:

  • Only his PC wouldn’t connect—everyone else was connecting without issue
  • Just a handful of users (about five)
  • All wired connections (no wireless)
  • A Windows Server 2003 file server
  • No domain—just a workgroup
  • A small simple router for DHCP and Internet

I went through basic troubleshooting steps and verified that the client could indeed browse devices on the network (including the server), had no unusual ping times or network settings and that his account password for the server was correct. Every attempt to connect prompted for his name and password but the server wouldn’t accept his credentials. He was repeatedly prompted for his credentials.

Likewise, a new server account that I created myself would work on other PCs but not his. I narrowed my focus to his machine and started asking questions:

Q: Was this a new machine?

A: Yes, pretty new.

Q: Had it ever connected to the server?

A: Yes, it had.

Q: Any recent unusual activity in the office?

A: Yes, the office had to be shut down for some recent power maintenance in the building a week ago. When he restarted the server it wouldn’t power up. Hardware technicians had diagnosed a few failed components. Only yesterday afternoon had the server been back online.

Q: Did he have the only Windows 7 PC in the office?

A: Yes.

The last question led me to believe he was having an issue with security negotiations between his PC and the server because the two OS versions were nearly 10 years apart and Windows 7 has considerably stricter security. Nothing in the PC’s local policy nor the server’s local policy for Microsoft Networking looked unusual. I tested a little registry change that seemed logical:

Go to HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA

Create Dword LmCompatibilityLevel with a value of 1

Restart computer and try to connect again.

No change.

After more research I found another potential solution on Microsoft Answers but was skeptical it would solve my issue since the computers were in a workgroup and not a domain. Check the time.

Just as soon as I was ready to pursue that idea the office manager asked me to check the backups on the server because they were reporting dates from October 2010. That was a smack to the face!

A quick resync to the NTP server corrected the time and the Windows 7 user logged in immediately.

Leopard Server: Using ACLs with Open Directory

Friday, October 26th, 2007

In Leopard, Workgroup Manager supports rudimentary ACLs for the LDAP database. We’re all familiar with Access Control Lists by now. Especially in the Mac OS X Server community. However, we might not all be familiar with ACLs as they’re implemented in LDAP. But we should be, because LDAP is being used more and more as an address book, and with the new Directory application being shipped in Leopard it is conceivable that environments aren’t just going to use ACLs to secure LDAP but they’re also going to use them to allow users to self update their information in the directory. So in the interest of security and making the most out of the technologies build into LDAP, let’s cover LDAP ACLs for a bit. So to push beyond what you can do in Workgroup Manager, let’s take a look at building out more finely grained ACLs manually.

First, like with most things in LDAP ACLs are configured using the /etc/openldap/slapd.conf file. Below is the pertinent portion of this file that we will be looking at:

# Define global ACLs to disable default read access. # Do not enable referrals until AFTER you have a working directory # service AND an understanding of referrals. #referral ldap:// # Sample access control policy: # Root DSE: allow anyone to read it # Subschema (sub)entry DSE: allow anyone to read it # Other DSEs: # Allow self write access # Allow authenticated users read access # Allow anonymous users to authenticate # Directives needed to implement policy: # access to dn.base="" by * read # access to dn.base="cn=Subschema" by * read # access to * # by self write # by users read # by anonymous auth # # if no access controls are present, the default policy # allows anyone and everyone to read anything but restricts # updates to rootdn. (e.g., "access to * by * read") # # rootdn can always read and write EVERYTHING! Now, if we remove the commented out portions of the file or add more lines we can start to limit who has access to read and/or change what information in the LDAP database. Keep in mind that you always want to back up your slapd.conf file prior to doing so.

You can control access to each element in the database. Each ACL has an “access to” which is the elements in the LDAP database that you are granting or denying access for and then a “by” portion that lists who can do what to that portion of the database. An entire ACL can be listed on one line, as is done with policies that have only one user or group associated to them. For example, the following line gives anyone and everyone read access to the database: access to dn.base=”" by * read

For ease of use and reviewing, we typically put the “access to” on one line and the subsequent users or groups with access in their own “by” lines for more complicated ACL rule sets. Slapd parses the file in such a way that it realizes that “access to” means the beginning of a new ACL. The following is an example of some more complicated ACLs: access to attrs=userPassword by dn="cn=users,dc=318,dc=com" write by self write by * compare access to * by dn="cn=computers,dc=318,dc=com" write by users read by * auth Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. In the above example, a user is able to write to their own userPassword record. This means that the user is also able to auth, compare, search and read that record.

ACLs are prosessed from top to bottom. This makes it important to put specific ACLs and by statements above more general ones. ACLs that restrict access to the userPassword attribute, followed by one applicable to *, that is, the entire LDAP database. In the above example, placing the userPassword ACL first causes the rule that allows users to change their own passwords to process before the wildcard that specifies everyone. When a * is used as a wildcard in the access to line of slapd.conf it means the entire database or tree of the LDAP database. When the * is used in the by line it typically denotes all users.

Access levels in ACLs are hierarchical. Levels that are used are none, auth, compare, search, read and write. None is the lowest level of access and write is the highest. Each level includes the rights of all lower levels. These two points, the first match wins rule and the inclusive nature of access levels, are crucial to understanding how ACLs are parsed. They also are important for making sure your ACLs don’t lead to either greater or lesser levels of access than you intend in a given situation.

It can be time consuming to go through every possible attribute by group and determine who has access to what. However, if you want to have users updating their own addresses, phone numbers, and other information, as can be done with the Directory application, this is often one way to accomplish this goal. You could also provide help desk users the ability to update the database using the Directory application but not allow them to access other records in the LDAP database, such as group memberships. Having a very granular ACL environment for records can also allow you to obtain a maximum level of security.

This can also be put into the schema in order to force replication between hosts. Keep an eye out for that article at a later date. ;)

For what it’s worth, at 318 we’ve found that commenting out each ACL helps us to keep track of who did what, why and what they were thinking when they did it. Happy OD everyone!!!

Using OD for Kerio Authentication

Tuesday, April 17th, 2007

Set up DNS record for
Set up OD master with Kerberos and make sure its all working.
Bind server into OD master and check Kerb.
Install Kerio.
Install Kerio OD extensions to Mail server.
Open Terminal and sudo pico /etc/openldap/slapd.conf
Find the include statements in the file.
Make sure that “include /etc/openldap/schema/kerio-mailserver.schema” (no quotes) is in that file in the correct spot under include.
Open Kerio Admin.
Go to Domains and click on the domain and click edit, than go to the directory services tab.
Check Map User accounts.
Choose Apple OD Kerberos Auth.

Username: uid=companydiradmin,cn-users,dc=dnsnameof,dc=main,dc=odmaster

LDAP Search Suffix:

Click test and you should get a connected successfully message!
Than when you go to users and click add choose activate user in directory service and you should see all of your OD users.