Hello, We have clients running Fedora 11. They are running samba and winbind version 3.4.2.0.42. samba-winbind-3.4.2-0.42.fc11.x86_64 samba-3.4.2-0.42.fc11.x86_64 samba-common-3.4.2-0.42.fc11.x86_64 Our problem is that the KVNO (Key Version Number) msDS-KeyVersionNumber keeps changing in the AD and is getting higher and higher. We are at 16 now and counting. 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 couple of days it seems. But the strange thing is that this is not for every computer object. There are also linux servers with AD computer objects that still have version 2 ? How is this possible ? This is a mystery for me. The other servers are using pam_winbind. Could that be the reason why the number will not increase in their case ? I hope to get some hints why this keeps happening. Greetings .. Richard
Richard Smits wrote:> Hello, > > We have clients running Fedora 11. They are running samba and winbind > version 3.4.2.0.42. > > samba-winbind-3.4.2-0.42.fc11.x86_64 > samba-3.4.2-0.42.fc11.x86_64 > samba-common-3.4.2-0.42.fc11.x86_64 > > Our problem is that the KVNO (Key Version Number) msDS-KeyVersionNumber > keeps changing in the AD and is getting higher and higher. We are at 16 > now and counting. > > 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 couple of days it seems. > > But the strange thing is that this is not for every computer object. > There are also linux servers with AD computer objects that still have > version 2 ? How is this possible ? This is a mystery for me. > > The other servers are using pam_winbind. Could that be the reason why > the number will not increase in their case ? > > I hope to get some hints why this keeps happening. > > Greetings .. RichardWell, I am still having this problem, but have captured it in a logfile. It was in the 2003 DC security log. I seems that the computer object password in the AD is changed. Why ? And why would winbind not negotiate in a normal manner so this could be avoided. See logfile below... Does anyone has a clue why this is happening ? Greetings ... ---------------------------------------------------------- 27-4-2010 12:49:56 Security Success Audit Account Management 646 NT AUTHORITY\ANONYMOUS LOGON SRVxxx "Computer Account Changed: - Target Account Name: linuxserver$ Target Domain: DASTUD Target Account ID: DOMAIN\linuxserver$ Caller User Name: SRVxxx$ 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 SRVxxx "Computer Account Changed: - Target Account Name: linuxserver$ Target Domain: DASTUD Target Account ID: DOMAIN\linuxserver$ Caller User Name: SRVxxx$ 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: -
Richard Smits wrote:> Richard Smits wrote: >> Hello, >> >> We have clients running Fedora 11. They are running samba and winbind >> version 3.4.2.0.42. >> >> samba-winbind-3.4.2-0.42.fc11.x86_64 >> samba-3.4.2-0.42.fc11.x86_64 >> samba-common-3.4.2-0.42.fc11.x86_64 >> >> Our problem is that the KVNO (Key Version Number) >> msDS-KeyVersionNumber keeps changing in the AD and is getting higher >> and higher. We are at 16 now and counting. >> >> 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 couple of days it seems. >> >> But the strange thing is that this is not for every computer object. >> There are also linux servers with AD computer objects that still have >> version 2 ? How is this possible ? This is a mystery for me. >> >> The other servers are using pam_winbind. Could that be the reason why >> the number will not increase in their case ? >> >> I hope to get some hints why this keeps happening. >> >> Greetings .. Richard > > Well, > > I am still having this problem, but have captured it in a logfile. It > was in the 2003 DC security log. > > I seems that the computer object password in the AD is changed. Why ? > And why would winbind not negotiate in a normal manner so this could be > avoided. > > See logfile below... Does anyone has a clue why this is happening ? > > Greetings ... > ---------------------------------------------------------- > > 27-4-2010 12:49:56 Security Success Audit Account > Management 646 NT AUTHORITY\ANONYMOUS LOGON SRVxxx > "Computer Account Changed: > - > Target Account Name: linuxserver$ > Target Domain: DASTUD > Target Account ID: DOMAIN\linuxserver$ > Caller User Name: SRVxxx$ > 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 SRVxxx > "Computer Account Changed: > - > Target Account Name: linuxserver$ > Target Domain: DASTUD > Target Account ID: DOMAIN\linuxserver$ > Caller User Name: SRVxxx$ > 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: -Well, I just want to say that this problem has been solved. It took a long time, but this is the solution : The new samba versions has a different syntax in the smb.conf file. In the old versions of samba, there was a line that said : use kerberos keytab = yes But in the newer versions, they changed the syntax of this line to : kerberos method = secrets and keytab This line says that the AD communication will use the keytab file, AND the sessions.tdb file. If you do not have this line, it only uses the session.tdb, and your keytab will be out of sync in a couple of days. Greetings .. Richard