1. Active Directory Mac Os

A java LDAP client with LDIF support, security (inc SSL, SASL & GSSAPI), translated into many languages (inc. Chinese), online help, user forms and many other features.

The commercial version is available at for $9.95. It extends JXplorer to include: - custom LDAP reporting - to pdf, word etc. Find and Replace with regexp and attribute substitution - A secure password vault to store directory connections - etc. Support for JXplorer and JXWorkbench is available at Commercial support available from sales@jxworkbench.com. Pyadselfservice is a software created using Python 3.5 and Django 1.10.

This project aims to provide web based password change interface to the end users, for their Active Directory account. While changing the password, users won't not need to enter their current password. Which means users can change their password even if they have forgotten their current password. Moreover, while changing the password, this software will automatically unlock the user account if it is locked. The authenticity of the user is verified against 2 factor authentication.

The first factor is validation of 3 different AD attributes. User will need to provide 3 different information which only he will know such as Home Telephone, Pin Code or any new AD attribute say PIN, Date of Birth, Date of Joining etc. The second factor is One Time Password (OTP). After successful validation of First Factor, a OTP is sent to the Email address of the user, may it be official or personal.

Hello to all, I have an issue plaguing the school I administrate. Basically certain users cannot log in to active directory bound machines.

They are told they need to change their password. I will give background.

Particularly, in the Library and certain kiosk machines, we have Macs that are bound to an Active Directory domain (I don't administrate this, just the Macs). These Macs have some prefs being set by a Mac OS X server, but nothing regarding Open Directory. All Active Directory. The majority of the machines are running 10.7.5. They bind/unbind perfectly as expected, and the majority of users can log in just fine. In the Library, there are a wall of Macs, and right on the other side, PCs. Every so often, we get someone who cannot log into ANY Mac.

They are told they need to change their password before they can log in, even though they have changed it recently (Active Directory is set to force users to change their password every 180 days). They will then get frustrated, go over to a PC and log in just fine there. Now I have found a few things.

I have an account that I have credentials to that is displaying the issue as of now. So I can easily test. On a few occasions, the user with the problem has reported being able to authenticate and login with their OLD password. Unfortunately at this moment I do not know the old password for the account that can reproduce the issue, but I may have it shortly.

I can reproduce the issue on any Mac bound to the domain, no matter what Mac OS and when it was bound. For example, I just imaged a brand new machine with 10.9, bound it to Active Directory (Did not bind it to OS X Server), and still will be told to reset my password on the affected account. Other accounts seem to be able to log in just fine, so it doesn't appear to be a binding issue. IMO, it seems as though the 180 day policy that Active Directory has set is somehow being cached by the Macs. What I mean is, when someone has an AD account set up and then logs in to a Mac, at that point it grabs the 180 day policy and runs with it. Even if you change your password, it just keeps your old password as your login password and waits for the 180 days to end, and at that point tells you to change your password. So the passwords seem to be out of sync.

I may be wrong on that diagnosis but in the end that is what it seems like to me. If anyone has any knowledge or help they can provide on this issue, it would be greatly appreciated. I have seen cases where after the Mac screensaver has activated the user is unable to unlock it with valid AD credentials. Rebooting and relogging in then works, I have also been told (if enabled) going to the fast user switching screen from the screensaver and then logging in with the same valid user details also works. Unplugging the network cable, waiting and then trying again to unlock the screensaver sometimes helps as well as then it uses the local cached credential and does not try to talk to the AD server. Note: The password has not expired and user is entering correctly when this happens.

I get the impression the Kerberos ticket may have expired and is not being renewed sometimes. With Kerberos as used by both OD and AD it is important that all the computer clocks are closely synced although I don't believe this is the cause of all the above cases. ' Are your caching the accounts on the Mac systems? Basically, in your AD bind configuration is the 'Create mobile account at login' box checked?

Yes it is checked. We did this to keep accounts available in the case of a network outage and also to keep data in tact if there were a power outage. 'Are you using network homes?' We are using local homes, meaning that students can log in on every Mac in the Library, however they are going to get a different desktop/home folder every time depending on which machine they have logged into.

When you say 'stale cached record' what do you mean? I don't think it can be anything on a local machine since I have tested with a newly-imaged machine and had the same results (that also should answer John Lockwood's response).

Also I know clocks are synced, and further I can log in with other accounts successfully (even ones that aren't locally cached). The fact that the issue is following you to other machines in the mystery and the condition I have not seen. Unless, the same user has accessed both machines in the past.

This does not explain how it would track to a freshly imaged device however. The 'stale cached record' is in reference to the.plist file that is created for the user (in /var/db/dslocal/nodes/Default/users) when they cache the account. I've seen many conditions (usually with laptops) where the user will never re-associate with the domain and effectively continue to work off the local cached account record. In some cases, the file needs to be purged from the machine and the user need to log in to create it. A possible test you can perform is to flush the cached record from the machine, reboot, and then try logging in as the user. A new cache file should be created when you login for the first time. Yes, my testing which involved reproducing the issue on a freshly imaged machine has ruled out that this is a local issue to any particular subset of machines.

I went ahead and deleted the.plist for the account that is having the issue, but the same issue occured when I attempted to log back in. It seems to me that the issue cannot be local to any machine, unless there is something consistent across ALL of them. The only thing that would be consistent would be the way they are bound to the domain. Otherwise there must be a problem in the way the Macs communicated with the AD server, the AD server itself, etc.

Not sure where to go from here or what to even try next. So somehow I got my problematic account to log in on my newly imaged machine, and it now works on all machines. Steps I performed are here: 1. Unchecked all boxes in Directory Utility Services Active Directory Advanced Options. Clicked 'unbind'. Deleted the problematic account's 'stale cached record' 4. Binded again to the AD server with no boxes checked.

Logged in, but Finder would not launch. Dock launched, so I was able to open system prefs and then log out. Checked each box one by one to see if one would ressurect the problem. After this I could not reproduce the problem and it works on all machines bound to the domain. I am not sure what fixed this. I am guessing the act of turning all of the advanced options of and unbinding/binding reset something.

Once I then authenticated with the problematic account, it fixed the issue for all other Macs. Not sure how else to explain it. Hi Number 6 sounds like a problem I've seen recently in a fairly large AD environment where a handful of users from amongst a thousand or so were affected. This particular environment had a folder structure that placed users' home folders two levels down from the share itself.

There was a policy that gave traverse rights all the way down from the parent share to users' home folders. Above this in the interface was an additional 'stale/out of date' policy that denied access to the parent folders upstream from the users' folder. Once this stale policy was removed and the new policy that allowed traverse rights re-applied/re-propagated the user was able to log in. Even though 'gpupdate /force' is supposed to refresh policies within 15 minutes it took a while (some 4-5 hours) before it finally took. Maybe the above might go some way in explaining what you saw?

Unbinding/binding the machine is causing DNS to hand out a new IP entry So the issue is that there are multiple DNS entries for the computer hostname. Go to the active directory server and go check DNS and remove the older entry. If for some reason your on a windows machine and you ping the hostname in cmdline then you can get wrong IP address.

Cool way to see this is if you then ping -a 172.168.x.x you can get a completely different Computer hostname given DNS has handed out that IP again. Typical issue with DNS in a windows environment and your system admin should be able to resolve this no problem. We are having the same issue on our campus. We are binding our Macs directly to AD, and not using a secondary binding mechanism, such as Centrify.

We don't select mobile accounts other than for the users Mac laptops. The issue is with the Mac desktops, and those predominatley in public areas. The problem is that users who are mainly Windows users, in a 180 password change policy, will be asked to change their password the first time they attempt logon to any bound Mac on campus. Regardless of when they last changed their AD password via their PC at login. If they do change their password at this point, they are then moved to a 42 day policy that exists somewhere, but they can then logon to any Mac on campus without issue. Mean while they still remain in the 180 day Windows policy. Eventually if they go back to any Mac they will be notified that their password will expire in X number of days, or that it has expired I'm in a 42 day policy, so at some point after changing my password I start seeing a message at login stating that I have X number of days before my password will expire.

This message will follow me around campus to any bound Mac I attempt to logon to. However once I've change the password the message goes away.

As a test I went a couple of days without changing my password after I'd received the message telling me that my password has expired. I could still go to a PC and logon without issue.

I am not all that knowledgeable about this, but it appears the Macs are looking at a different set of accounts for the validating of credentials than the PCs are, and these follow the users to the different Macs on campus. Apple Footer. This site contains user submitted content, comments and opinions and is for informational purposes only. Apple may provide or recommend responses as a possible solution based on the information provided; every potential issue may involve several factors not detailed in the conversations captured in an electronic forum and Apple can therefore provide no guarantee as to the efficacy of any proposed solutions on the community forums. Apple disclaims any and all liability for the acts, omissions and conduct of any third parties in connection with or related to your use of the site.

Active Directory Mac Os

All postings and use of the content on this site are subject to the.