AD+SAmba+Linux

[andysys]

Hi Guys

I have Active directory+ Samba integrated with Linux.

Setup -

Activie directory Windows 2003
Samba version - samba-3.0.14a-1
OS - Red Hat Linux release 9

Windows Services for unix are installed on domain controller.AD users are able to login on this linux machine which is configured as LDAP client.

Thro.Samba AD users are able to access their home directories which resides on linux system but can not write
into it.
Getting error like Access denied.
Unix permissions are 755 & if I set it to 777 these users are able to write which is not recommended way.
Previously this setup use to work.

Under samba log getting error as follow---


[2006/02/20 14:27:39, 1] nsswitch/winbindd_sid.c:winbindd_gid_to_sid(474)
Could not convert gid 11000 to sid



[2006/02/19 04:10:06, 0] libsmb/cliconnect.c:cli_session_setup_spnego(759)
Kinit failed: Clock skew too great


Any help would be greatly appreciated.

Thanks! in advance.

Andy

 

[andysys]

One more updates -

I am able to list AD users using wbinfo & getent passwd

Only problem is while accessing samba shares from windows clients.

Thanks
Andy

 

[IRudebwoy]

Try setting permissions to 775.

 

[andysys]

Hi

Thanks for your quick response!

Even 775 doesn't wotrk.It works only with 777.

Andy

 

[andysys]

Hi UNix Experts!

I am on top of a gun.Any help would be greatly appreciated.

Thanks
Andy

 

[zeland]

If 777 works, then I suspect it's because your users are not authenticating right. They must be connecting as a guest user. Run smbstatus to see what service* are your users connecting as.

* service = username


--== Anything can go wrong. It's just a matter of how far wrong it will go till people think its right. ==--

 

[jgiacobbe]

I am not knowladgable in linux other than I have installed fedora on a desktop pc. (yes I used GNOME. I to use my mouse.) I have some interest in learning how to do a setup ike you have described though. I think the clock skew might be the reason for your problems. AD has a feature where it won't authenticate if the clock on the two computer is too far off timewise. The idea is that it will reduce replay attacks. For somereason it is stuck in my head that the default max clock skew is 90 seconds.

Just a shot in the dark but I know AD likes system times to be close to each other. Good luck.

Seeing that the last post to this thread was a week ago this might be a little late.

Jeremy Giacobbe
MCSE, CCNA

 

[TECHMAN007]

If you are getting the clock skew error that is usually because the linux file server and the AD server are to far off on clocks .. ntp sync them to the same time server and that should remove the clock skew error and may fix the other one in the process.