Hi Rowland et al,> > The reason I thought sssd would be best is because I want to use the > > /etc/passwd file for user existence and was easy to set up. > > You cannot have the same user in /etc/passwd and AD i.e. user 'foo' in > /etc/passwd could, and probably would, be seen as the the AD user 'foo'.The way the system is set up, username existance and UID is determined by /etc/passwd . Then sssd checks whether username/password are correct or not with the kerberos servers and retrieves nothing else (from them). This works fine as I can log in with ssh using username/password from either kerberos realms.> > If sssd is not going to work for the overall goal of being able to use > > credentials from either Kerberos realm to authenticate, then I'm happy to > > ditch it! > > I am not saying that sssd won't work for what you are trying to do, you > are just asking this in the wrong place, try the sssd-users mailing list.It seems to me that samba is the sticking point. If REALM=AD.WISC.EDU I can gain access to samba shares with seys at AD.WISC.EDU, but not cwseys at PHYSICS.WISC.EDU. If REALM=PHYSICS.WISC.EDU, cwseys at PHYSICS.WISC.EDU can gain access, but seys at AD.WISC.EDU can not. I change nothing else besides REALM= in smb.conf . My guess is that Samba is using REALM=BLAH to check only principals in the keytab whose realm is BLAH. So, it seems as though if Samba could be taught to understand a realm list REALM=BLAH,FOO,BAR and check principals from all of them in the keytab, then my problem would be solved.> Just adding 'server role' to a machine you have joined to a domain isn't > going to make it a standalone server. The definition of a 'standalone > server' is a server that is not connected to a domain and holds it own > database of users, groups etc.I hope to use /etc/passwd /etc/groups as the database of user and groups, not get them from active directory. So I guess I'm hoping for semi-joined. :)> To be honest, I have never needed to do this, but I don't think you > actually authenticate to both kerberos realms, you just setup a trust > between the two realms, try a search on the internet using 'active > directory' and 'trusts'.I think this would work, so long as the active directory admins agree to add the krbtgt to their database! Crossing my fingers. Thanks again! Chad.
On 02/03/16 20:12, Chad William Seys wrote:> Hi Rowland et al, > >>> The reason I thought sssd would be best is because I want to use the >>> /etc/passwd file for user existence and was easy to set up. >> You cannot have the same user in /etc/passwd and AD i.e. user 'foo' in >> /etc/passwd could, and probably would, be seen as the the AD user 'foo'. > The way the system is set up, username existance and UID is determined by > /etc/passwd . Then sssd checks whether username/password are correct or not > with the kerberos servers and retrieves nothing else (from them).If your users are in /etc/passwd, they are *local* users, if they are also in AD, then the *local* user 'foo' is not the same user as 'foo' in AD.> > This works fine as I can log in with ssh using username/password from either > kerberos realms. > >>> If sssd is not going to work for the overall goal of being able to use >>> credentials from either Kerberos realm to authenticate, then I'm happy to >>> ditch it! >> I am not saying that sssd won't work for what you are trying to do, you >> are just asking this in the wrong place, try the sssd-users mailing list. > It seems to me that samba is the sticking point.No it isn't, you are> > If REALM=AD.WISC.EDU I can gain access to samba shares with seys at AD.WISC.EDU, > but not cwseys at PHYSICS.WISC.EDU. > > If REALM=PHYSICS.WISC.EDU, cwseys at PHYSICS.WISC.EDU can gain access, but > seys at AD.WISC.EDU can not. > > I change nothing else besides REALM= in smb.conf . > > My guess is that Samba is using REALM=BLAH to check only principals in the > keytab whose realm is BLAH. > > So, it seems as though if Samba could be taught to understand a realm list > REALM=BLAH,FOO,BAR and check principals from all of them in the keytab, then > my problem would be solved.Yes, that is how it is supposed to work.>> Just adding 'server role' to a machine you have joined to a domain isn't >> going to make it a standalone server. The definition of a 'standalone >> server' is a server that is not connected to a domain and holds it own >> database of users, groups etc. > I hope to use /etc/passwd /etc/groups as the database of user and groups, not > get them from active directory.Then setup up the server as a 'standalone server' and give it a different workgroup name, it well then be a separate WORKGROUP and you will then have all the problems that entails including having to keep users and passwords in sync with your machines.> > So I guess I'm hoping for semi-joined. :)No such animal.> >> To be honest, I have never needed to do this, but I don't think you >> actually authenticate to both kerberos realms, you just setup a trust >> between the two realms, try a search on the internet using 'active >> directory' and 'trusts'. > I think this would work, so long as the active directory admins agree to add > the krbtgt to their database! Crossing my fingers. > > Thanks again! > Chad. >I do not think what you are trying do will work, try talking to your active directory admins about *TRUSTS* Rowland
> If your users are in /etc/passwd, they are *local* users, if they are > also in AD, then the *local* user 'foo' is not the same user as 'foo' in AD.All that matters for authentication on a kerberos KDC is that the correct password is given for the username. Mapping username to UID/GIDs/etc is done by the local computer and access to files is allowed or disallowed based on the ACLs in the filesystem. This is working just fine.> > This works fine as I can log in with ssh using username/password from > > either kerberos realms. > > > >>> If sssd is not going to work for the overall goal of being able to use > >>> credentials from either Kerberos realm to authenticate, then I'm happy > >>> to > >>> ditch it! > >> > >> I am not saying that sssd won't work for what you are trying to do, you > >> are just asking this in the wrong place, try the sssd-users mailing list. > > > > It seems to me that samba is the sticking point. > > No it isn't, you areHmm, I agree if by that you mean I am not submitting a patch so that Samba can understand a list after REALM= . :)> > I hope to use /etc/passwd /etc/groups as the database of user and groups, > > not get them from active directory. > > Then setup up the server as a 'standalone server' and give it a > different workgroup name, it well then be a separate WORKGROUP and you > will then have all the problems that entails including having to keep > users and passwords in sync with your machines.Right, that method would be silly b/c we already have everyones' credentials in kerberos servers. Though there is CTDB or other ways of synchronizing tdbs as an option. Sadly, the feature of using two or more Kerberos realms for authentication appears not to be implemented by Samba.> >> To be honest, I have never needed to do this, but I don't think you > >> actually authenticate to both kerberos realms, you just setup a trust > >> between the two realms, try a search on the internet using 'active > >> directory' and 'trusts'. > > > > I think this would work, so long as the active directory admins agree to > > add the krbtgt to their database! Crossing my fingers. > > I do not think what you are trying do will work, try talking to your > active directory admins about *TRUSTS*Yep, as long as they are agreeable, this appears to be the workaround. Thanks again! Chad.