We use Windows Active Directory for account management. As a security policy, we need to change password for service accounts at least every six months. What we are experiencing is, when we change the password on AD, the application breaks before we get to change the password on servers where the account is being used. I was wondering if any of you experienced this issue. How did you resolve this issue? Thanks
Linux service account management
active-directorylinuxuser-accounts
Related Solutions
A Service Principal Name is a concept from Kerberos. It's an identifier for a particular service offered by a particular host within an authentication domain. The common form for SPNs is service class/fqdn@REALM (e.g. IMAP/mail.example.com@EXAMPLE.COM). There are also User Principal Names which identify users, in form of user@REALM (or user1/user2@REALM, which identifies a speaks-for relationship). The service class can loosely be thought of as the protocol for the service. The list of service classes that are built-in to Windows are listed in this article from Microsoft.
Every SPN must be registered in the REALM's Key Distribution Center (KDC) and issued a service key. The setspn.exe utility which is available in \Support\Tools folder on the Windows install media or as a Resource Kit download, manipulates assignments of SPNs to computer or other accounts in the AD.
When a user accesses a service that uses Kerberos for authentication (a "Kerberized" service) they present an encrypted ticket obtained from KDC (in a Windows environment an Active Directory Domain Controller). The ticket is encrypted with the service key. By decrypting the ticket the service proves it possesses the key for the given SPN. Services running on Windows hosts use the key associated with AD computer account, but to be compliant with the Kerberos protocol SPNs must be added to the Active Directory for each kerberized service running on the host — except those built-in SPNs mentioned above. In the Active Directory the SPNs are stored in the servicePrincipalName attribute of the host's computer object.
For more information, see: Microsoft TechNet article on SPN, Ken Hornstein's Kerberos FAQ
You can enable the Directory Service Changes feature, which was introduced in Windows 2008. This has the added benefit of recording both the current and previous values of an attribute when a modification occurs.
Warning: If you configure this setting in Group Policy, this is covered in the new auditing section as "DS Access". You should use either the new auditing settings or the older auditing section, but not both. When settings in the new auditing section are used, any settings in the old section may be ignored.
New location:
Computer Configuration > Windows Settings > Security Settings > Advanced Audit Policy Configuration
Old Location:
Computer Configuration > Windows Settings > Security Settings > Local Policies > Audit Policy.
It is possible to configure this using the auditpol.exe command, however if that method is used, it should be performed as a Computer startup script to ensure that the settings are in effect when the computer restarts. This is the command:
auditpol /set /subcategory:"directory service changes" /success:enable
You also need to enable auditing in AD Users and Computers:
Run Active Directory Users and Computers.
Right-click the organizational unit (OU) (or any object) for which you want to enable auditing, and then click Properties.
Click the Security tab, click Advanced, and then click the Auditing tab.
Click Add, and under Enter the object name to select, type Authenticated Users (or any other security principal), and then click OK.
In Apply onto, click Descendant User objects (or any other objects).
Under Access, select the Successful check box for Write all properties.
Click OK until you exit the property sheet for the OU or other object.
More information:
AD DS Auditing Step-by-Step Guide
http://technet.microsoft.com/en-us/library/cc731607%28v=ws.10%29.aspx
Which Versions of Windows Support Advanced Audit Policy Configuration?
http://technet.microsoft.com/en-us/library/dd692792(WS.10).aspx
"Using both the basic audit policy settings under Local Policies\Audit Policy and the advanced settings under Advanced Audit Policy Configuration can cause unexpected results. Therefore, the two sets of audit policy settings should not be combined. If you use Advanced Audit Policy Configuration settings, you should enable the Audit: Force audit policy subcategory settings (Windows Vista or later) to override audit policy category settings policy setting under Local Policies\Security Options. This will prevent conflicts between similar settings by forcing basic security auditing to be ignored."
Best Answer
Use correctly configured cache daemon on Linux server side.
SSSD works quite good with Active Directory.
Here is the link to RHEL Guide:
RHEL6 AD INTEGRATION AND SSSD GUIDE