[SSSD-users] Login with Enterprise Principal Name with AD backend
steve at steve-ss.com
Mon May 26 10:17:03 UTC 2014
On Mon, 2014-05-26 at 09:46 +0000, Longina Przybyszewska wrote:
> -----Original Message-----
> From: sssd-users-bounces at lists.fedorahosted.org [mailto:sssd-users-bounces at lists.fedorahosted.org] On Behalf Of Vinícius Ferrão
> Sent: 26. maj 2014 00:57
> To: End-user discussions about the System Security Services Daemon
> Subject: Re: [SSSD-users] Login with Enterprise Principal Name with AD backend
> On May 25, 2014, at 19:51, steve <steve at steve-ss.com> wrote:
> > On Sun, 2014-05-25 at 22:31 +0000, Vinícius Ferrão wrote:
> >> Hello guys,
> >> I’m running sssd version 1.11 in Ubuntu 14.04 LTS (1.11.5-1ubuntu3) to authenticate users from Active Directory from WIndows Server 2012 R2, and I’m trying to achieve logins with the User Principal Name for all users of the domain. But the UPN are always Enterprise Principal Names.
> >> Let-me illustrate the problem with my user account:
> >> Domain: local.example.com
> >> sAMAccountName: ferrao
> >> UPN: ferrao at example.com (there’s no local in the UPN)
> >> I can successfully login with the sAMAccount atribute, which is fine, but I can’t login with ferrao at example.com which is my UPN. The optimum solution for me is to allow logins from sAMAccount and the UPN. If’s not possible, the UPN should be the right way instead of the sAMAccountName.
> >> Another annoyance is the homedir pattern with those options in sssd.conf:
> >> default_shell = /bin/bash
> >> fallback_homedir = /home/%d/%u
> >> What I would like to achieve is separated home directories from the EPN. For example:
> >> /home/example.com/user
> >> /home/whatever.example.com/user
> >> But with this pattern I can’t map the way I would like to do.
> >> I’ve looked through man pages and was unable to find any answers for this issues.
> >> Thanks in advance,
> >> Vinícius.
> > Hi
> > Not sure about the accountname bit but the 2012 schema has full
> > support for rfc2307 out of the box. Store whatever home directory you
> > like on a per user basis under their DN as:
> > uinixHomeDirectory
> > Likewise:
> > loginShell
> > with whatever shell they need.
> > The 1.11.5 ad backend will automatically grab them with no further
> > configuration needed.
> > Steve
> Hello Steve, thank you for the fast reply. I was aware of the AD ldap schema.
> I’m avoiding to mess with Unix specific atributes inside AD because Microsoft started the decommissioning of Unix Services. Today still exists hacks to enable the UNIX Attributes tab in the User Preferences, but they can only be enabled activating Services for NIS from the Powershell.
> I know it’s an option, but the whole point of using SSSD is to avoid messing with AD. If it’s impossible to achieve in the SSSD side, that will be the solution for the second issue.
> Thank you,
> Hi there,
> So what is the scenario for minimal possible AD mess - do not use at all Posix Attributes?
> If we don't plan to use Nis services, but need Posix schema and Posix attributes for searching uid/gid /autofs maps- are we not safe?
> It is important decision for our project, as we are just about to ask for "messing AD" by attaching gid number for existing AD groups and keep gid number assigning for all groups created in the future.
> It seems to be the rightest way to achieve unique uid/gid on the Linux clients, as we have different kind of storage (Sun storage) often with own algorithm of resolving Uids&group id from SID in AD forest with trusted domains.
> I even don't know how much mess is it with assigning gid number to all AD groups - is it just a piece of cake which MS admins would love? ;(
> What could be the safe concept (not IPA yet ) for AD Linux integration with sssd to be on the safe side against MS decommissioning of Unix Services ?
You do not need sfu to use posix attributes in AD.
More information about the sssd-users