Computer Account Reset AD
Douglas E. Engert
deengert at anl.gov
Wed May 12 11:35:07 EDT 2010
Richard Smits wrote:
>
> Douglas E. Engert wrote:
>>
>> Richard Smits wrote:
>>> Hello,
>>>
>>> We have a problem where we keep getting stuck when we try to find the
>>> answer. I hope someone on this list can give us tips or hints in the
>>> right direction.
>>>
>>> I will explain it below :
>>>
>>> We use Linux/Fedora clients with a nfs4/krb5 mount to a NetApp nashead.
>>> Our KDC is our Windows 2003/2008 AD.
>>>
>>> The problem i was first facing was to establish root access to this
>>> nashead. I found out that we had to create a root keytab.
>>>
>>> No problem there, but we installed a "management station" for creating
>>> users an other maintenance work. Then you are going to face the
>>> "expired ticket" problem.
>>>
>>> I solved it this way.
>>>
>>> In the crontab, every hour :
>>> /usr/kerberos/bin/kinit -l 300d -k root/hostname.domain.net at DOMAIN.NET
>>>
>>> 300 days does not work, but one week seems to work.
>>>
>>> klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: root/hostname.domain.net at DOMAIN.NET
>>>
>>> Valid starting Expires Service principal
>>> 05/11/10 08:15:01 05/11/10 18:15:02 krbtgt/DOMAIN.NET at DOMAIN.NET
>>> renew until 05/18/10 08:15:01
>>> 05/11/10 08:20:01 05/11/10 18:15:02 srv005$@DOMAIN.NET
>>> renew until 05/18/10 08:15:01
>>>
>>> But now I will explain our problem.
>>>
>>> Every week (on the second) the computer object in the AD is reset.
>>> Why, we don't know. See logfile below :
>>>
>>> --------------------------------------------
>>> 27-4-2010 12:49:56 Security Success Audit Account
>>> Management 646 NT AUTHORITY\ANONYMOUS LOGON SRV005
>>> "Computer Account Changed:
>>> -
>>> Target Account Name: nasmgt$
>>> Target Domain: DASTUD
>>> Target Account ID: DOMAIN\nasmgt$
>>> Caller User Name: SRV005$
>>> Caller Domain: DASTUD
>>> Caller Logon ID: (0x0,0x3E7)
>>> Privileges: -
>>> Changed Attributes:
>>> Sam Account Name: -
>>> Display Name: -
>>> User Principal Name: -
>>> Home Directory: -
>>> Home Drive: -
>>> Script Path: -
>>> Profile Path: -
>>> User Workstations: -
>>> Password Last Set: 4/27/2010 12:49:56 PM
>>> Account Expires: -
>>> Primary Group ID: -
>>> AllowedToDelegateTo: -
>>> Old UAC Value: -
>>> New UAC Value: -
>>> User Account Control: -
>>> User Parameters: -
>>> Sid History: -
>>> Logon Hours: -
>>> DNS Host Name: -
>>> Service Principal Names: -
>>> "
>>> 27-4-2010 12:49:56 Security Success Audit Account
>>> Management 646 NT AUTHORITY\ANONYMOUS LOGON SRV005
>>> "Computer Account Changed:
>>> -
>>> Target Account Name: nasmgt$
>>> Target Domain: DASTUD
>>> Target Account ID: DOMAIN\nasmgt$
>>> Caller User Name: SRV005$
>>> Caller Domain: DASTUD
>>> Caller Logon ID: (0x0,0x3E7)
>>> Privileges: -
>>> Changed Attributes:
>>> Sam Account Name: -
>>> Display Name: -
>>> User Principal Name: -
>>> Home Directory: -
>>> Home Drive: -
>>> Script Path: -
>>> Profile Path: -
>>> User Workstations: -
>>> Password Last Set: 4/27/2010 12:49:56 PM
>>> Account Expires: -
>>> Primary Group ID: -
>>> AllowedToDelegateTo: -
>>> Old UAC Value: -
>>> New UAC Value: -
>>> User Account Control: -
>>> User Parameters: -
>>> Sid History: -
>>> Logon Hours: -
>>> DNS Host Name: -
>>> Service Principal Names: -
>>>
>>>
>>>
>>> Event Type: Success Audit
>>> Event Source: Security
>>> Event Category: Account Management
>>> Event ID: 646
>>> Date: 4-5-2010
>>> Time: 12:49:56
>>> User: NT AUTHORITY\ANONYMOUS LOGON
>>> Computer: SRV005
>>> Description:
>>> Computer Account Changed:
>>> -
>>> Target Account Name: nasmgt$
>>> Target Domain: DASTUD
>>> Target Account ID: DOMAIN\nasmgt$
>>> Caller User Name: SRV005$
>>> Caller Domain: DASTUD
>>> Caller Logon ID: (0x0,0x3E7)
>>> Privileges: -
>>> Changed Attributes:
>>> Sam Account Name: -
>>> Display Name: -
>>> User Principal Name: -
>>> Home Directory: -
>>> Home Drive: -
>>> Script Path: -
>>> Profile Path: -
>>> User Workstations: -
>>> Password Last Set: 5/4/2010 12:49:56 PM
>>> Account Expires: -
>>> Primary Group ID: -
>>> AllowedToDelegateTo: -
>>> Old UAC Value: -
>>> New UAC Value: -
>>> User Account Control: -
>>> User Parameters: -
>>> Sid History: -
>>> Logon Hours: -
>>> DNS Host Name: -
>>> Service Principal Names: -
>>>
>>>
>>> For more information, see Help and Support Center at
>>> http://go.microsoft.com/fwlink/events.asp.
>>>
>>> --------------------
>>>
>>> Event Type: Success Audit
>>> Event Source: Security
>>> Event Category: Account Management
>>> Event ID: 646
>>> Date: 4-5-2010
>>> Time: 12:49:56
>>> User: NT AUTHORITY\ANONYMOUS LOGON
>>> Computer: SRV005
>>> Description:
>>> Computer Account Changed:
>>> -
>>> Target Account Name: nasmgt$
>>> Target Domain: DASTUD
>>> Target Account ID: DOMAIN\nasmgt$
>>> Caller User Name: SRV005$
>>> Caller Domain: DASTUD
>>> Caller Logon ID: (0x0,0x3E7)
>>> Privileges: -
>>> Changed Attributes:
>>> Sam Account Name: -
>>> Display Name: -
>>> User Principal Name: -
>>> Home Directory: -
>>> Home Drive: -
>>> Script Path: -
>>> Profile Path: -
>>> User Workstations: -
>>> Password Last Set: 5/4/2010 12:49:56 PM
>>> Account Expires: -
>>> Primary Group ID: -
>>> AllowedToDelegateTo: -
>>> Old UAC Value: -
>>> New UAC Value: -
>>> User Account Control: -
>>> User Parameters: -
>>> Sid History: -
>>> Logon Hours: -
>>> DNS Host Name: -
>>> Service Principal Names: -
>>> ===================================
>>>
>>> As a result the KVNO (Key Version Number) AD attribute :
>>> msDS-KeyVersionNumber keeps changing and is getting higher and higher.
>>> We were at version 2. I rejoined the domain a few times and i am at
>>> version 6 now.
>>> See below.
>>>
>>> The problem is that I have to recreate a new keytab file because our
>>> clients are also using a nfs4/krb5 mount on another server.
>>>
>>> When the version is higher than local in the keytab, the krb5 security
>>> will not work anymore.
>>>
>>> I have talked to the Windows sysadmins and the say that the password for
>>> a computer object is changed every 30 days, but my experience is that
>>> the key is increased every seven days.
>> Looks like the SRV005 at DASTDU is changing the password.
>>
>> Are you using a single AD account for the machine and the root/host?
>>
>> What is SRV005$ is this the samAccountName of the machine's account?
>>
>> Is there a cron job or some NAS daemon that is changing it, and expecting
>> to change the host/fqdn at realm keys in the keytab at the same time?
>>
>> Did you do a setspn command to add root/hostname.domain.net at DOMAIN.NET
>> (What UPN and SPNs are on the account?)
>>
>> You may have been bit by AD using a single password per account which is
>> used to derive the keys on the fly for the UPN and all SPNs associated with
>> the account.
>>
>> Normally the /etc/krb5.keytab has host/fqdn at realm principals,and not a
>> root/fqdn at realm principals. Did you clobber the previous /etc/krb5.keytab
>> which may have had a host/fqdn at realm principal?
>>
>> You could consider separating using two the computer account one for root
>> and one for the machine. You may not need a root/fqdn at realm principal at
>> all. Look at ~.k5login and use kinit -k host/fqdn at realm
>>
>>> -----
>>> klist -k -e
>>> Keytab name: FILE:/etc/krb5.keytab
>>> KVNO Principal
>>> ----
>>> --------------------------------------------------------------------------
>>>
>>> 6 root/nasmgt.domain.net at DOMAIN.NET (DES cbc mode with CRC-32)
>>> 6 root/nasmgt.domain.net at DOMAIN.NET (DES cbc mode with RSA-MD5)
>>> 6 root/nasmgt.domain.net at DOMAIN.NET (ArcFour with HMAC/md5)
>>> 6 root/nasmgt at DOMAIN.NET (DES cbc mode with CRC-32)
>>> 6 root/nasmgt at DOMAIN.NET (DES cbc mode with RSA-MD5)
>>> 6 root/nasmgt at DOMAIN.NET (ArcFour with HMAC/md5)
>>>
>>> ----------------
>>> klist
>>> Ticket cache: FILE:/tmp/krb5cc_0
>>> Default principal: root/nasmgt.domain.net at DOMAIN.NET
>>>
>>> Valid starting Expires Service principal
>>> 04/21/10 12:15:01 04/21/10 22:15:01 krbtgt/DOMAIN.NET at DOMAIN.NET
>>> renew until 04/28/10 12:15:01
>>> 04/21/10 12:25:01 04/21/10 22:15:01 srv005$@DOMAIN.NET
>>> renew until 04/28/10 12:15:01
>>>
>>>
>>> Kerberos 4 ticket cache: /tmp/tkt0
>>> klist: You have no tickets cached
>>> ----------------------------
>>>
>>> Reminder :
>>>
>>> Because this is our maintenance / root station for our nashead, I am
>>> renewing our ticket every hour with a cronjob. So the lifetime of the
>>> ticket is extended every hour. Could this be one of the actions that
>>> causes this ?
>>>
>>> Greetings ... Richard Smits
>>>
> Hello,
>
> > Looks like the SRV005 at DASTDU is changing the password.
> Well srv005 is the Windows Domain Controller, and DASTUD the windows domain.
So what might be happening is the computer is not changing the password
as base on policy, so AD changes it. So unless you are using something like
Samba, Likewise or msktutil and changing the keytab and password, AD
may have change the password (but not the keytab) because the machine did not.
There is an option on the account to say password never expires.
>
> I use a single workstation account for my server. Why would someone need
> more ?
>
A number of reasons depending on the services, and needs to use different
keys/passwords for each.
> There is no cronjob on the client or server side what could be causing
> this in my knowledge.
>
> > Did you do a setspn command to add root/hostname.domain.net at DOMAIN.NET
> > (What UPN and SPNs are on the account?)
>
> Ok, here are my UPS's and SPN's of the computer object :
>
> (servicePrincipalName)
> HOST/NASMGT
> HOST/nasmgt.tudelft.net
> ROOT/nasmgt
> ROOT/nasmgt.tudelft.net
>
> (userPrincipalName)
> root/nasmgt.tudelft.net at TUDELFT.NET
Strange, you said your AD domain was DASTDU but the realm is TUDELFT.NET
Are these the same AD domain?
Usually the AD domain is the same as the realm. AD can use a short form
and is case insensitive, but Kerberos uses the full realm name and in
upper case.)
(Normally this would be host/nasmgt.tudelft.net at TUDELFT.NET
>
> But in my keytab file the HOST entry's are not there.... could this be a
> problem. I am relatively a newby for krb5, and never understood where
> the HOST entry's were for.
Yes. Normally, the keytab file only has host/fqdn at realm entries and
is used by pam_krb5, sshd, telnetd, rlogind, ftpd, etc.
i.e. used for "login" type services. and the AD account for a Unix host
would have only:
userPrincipalName: host/fqdn at REALM
servicePrincipalName: host/fqdn
You can use kinit -k host/fqdn at REALM as long as the keytab and the
AD account password are changed together.
>
> Your story about not needing a root entry in the keytab is interesting.
> I will look in to this.
>
> Greetings .. Richard
> ________________________________________________
> Kerberos mailing list Kerberos at mit.edu
> https://mailman.mit.edu/mailman/listinfo/kerberos
>
>
--
Douglas E. Engert <DEEngert at anl.gov>
Argonne National Laboratory
9700 South Cass Avenue
Argonne, Illinois 60439
(630) 252-5444
More information about the Kerberos
mailing list