[Discussion] Active Directory LDAP login - modified login

Discussion:

[Discussion] Active Directory LDAP login - modified login_ldap.php.

David Ramsden

2016-09-26 10:49:49 UTC

Hello.

Wanted to feedback a hacked login_ldap.php to the community.

The attached replacement for login_ldap.php may break (read: probably will!
:)) anyone using OpenLDAP (I have no OpenLDAP environment to test against)
but should help those who like us have multiple AD domains where users of
OpenDCIM may be within one of those domains.

Even if you have a single AD domain this will still work for you. This
removes any dependancy on users/groups/whatever being in certain OUs which
can be fairly restrictive for OpenDCIM as well.

The OpenDCIM security groups need to be created within the root domain
(e.g. domain.local) but users can be within any OU within any sub-domain
(e.g. eu.domain.local, am.domain.local).

First create AD universal security groups in the root domain to match the
OpenDCIM permissions. For example:

OpenDCIM-SiteAdmin
OpenDCIM-ContactAdmin
OpenDCIM-SiteAccess
OpenDCIM-WriteAccess
OpenDCIM-ReadAccess
OpenDCIM-DeleteAccess
OpenDCIM-RackRequest
OpenDCIM-RackAdmin
OpenDCIM-BulkOperations
OpenDCIM-AdminOwnDevices

Then populate the groups with either individual users or groups that users
are a member of. e.g. add the Network Ops group to OpenDCIM-SiteAccess,
OpenDCIM-ReadAccess and OpenDCIM-AdminOwnDevices groups.

Edit the OpenDCIM configuration via the web interface and change the LDAP
parameters.

LDAP Server URI: Needs to point to a Global Catalog server in the root
domain (e.g. dc1.domain.local:3268)
Base DN: Should be the base DN for the root domain (e.g. dc=domain,dc=local)
Bind DN: Should be set to %userid%
User Search: Should be set to (|(userPrincipalName=%userid%))

Note: Base Search is no longer used and can be ignored.

Set the DN for the groups, e.g.:

Site Access: CN=OpenDCIM-SiteAccess,OU=OpenDCIM,OU=Security
Groups,DC=domain,DC=local

(if the OpenDCIM-SiteAccess group lives in domain.local/Security
Groups/OpenDCIM)

Replace login_ldap.php with the attached.

Now users should be able to login with their UPN (user principle name),
e.g. ***@eu.domain.local or whatever their UPN is set to in AD.

This modified version of login_ldap.php:
1. Attempts to authenticate the user against AD. If the user
authenticated...
2. Gets the groups the user is a member of.
3. Checks if the groups the user is a member of is a member of the
appropriate OpenDCIM group OR if the user itself is a member of the
appropriate OpenDCIM group.

Tested against 4.3 and 4.3.1 only.

Hopefully this is useful and maybe some of this could find its way in to a
future release. I'd suggest possibly another authentication method called
"AD" so that it decouples AD from LDAP and would make maintaining and
testing code easier.

Regards,
David.

Scott Milliken

2016-09-26 11:30:02 UTC

Permalink

David,
openDCIM always starts with a lower case 'o'.

Yeah, just kidding. This is great stuff. We could certainly have
two options for the ldap logins - one for openLDAP, and one for Active
Directory, that the site admin simply has to link/rename upon
installation. The only issue is maintaining that second login - if I have
someone that will make sure it stays up to date, we can make it part of the
package. HINT HINT.

Thanks,
Scott

Post by David Ramsden
Hello.
Wanted to feedback a hacked login_ldap.php to the community.
The attached replacement for login_ldap.php may break (read: probably
will! :)) anyone using OpenLDAP (I have no OpenLDAP environment to test
against) but should help those who like us have multiple AD domains where
users of OpenDCIM may be within one of those domains.
Even if you have a single AD domain this will still work for you. This
removes any dependancy on users/groups/whatever being in certain OUs which
can be fairly restrictive for OpenDCIM as well.
The OpenDCIM security groups need to be created within the root domain
(e.g. domain.local) but users can be within any OU within any sub-domain
(e.g. eu.domain.local, am.domain.local).
First create AD universal security groups in the root domain to match the
OpenDCIM-SiteAdmin
OpenDCIM-ContactAdmin
OpenDCIM-SiteAccess
OpenDCIM-WriteAccess
OpenDCIM-ReadAccess
OpenDCIM-DeleteAccess
OpenDCIM-RackRequest
OpenDCIM-RackAdmin
OpenDCIM-BulkOperations
OpenDCIM-AdminOwnDevices
Then populate the groups with either individual users or groups that users
are a member of. e.g. add the Network Ops group to OpenDCIM-SiteAccess,
OpenDCIM-ReadAccess and OpenDCIM-AdminOwnDevices groups.
Edit the OpenDCIM configuration via the web interface and change the LDAP
parameters.
LDAP Server URI: Needs to point to a Global Catalog server in the root
domain (e.g. dc1.domain.local:3268)
Base DN: Should be the base DN for the root domain (e.g.
dc=domain,dc=local)
Bind DN: Should be set to %userid%
User Search: Should be set to (|(userPrincipalName=%userid%))
Note: Base Search is no longer used and can be ignored.
Site Access: CN=OpenDCIM-SiteAccess,OU=OpenDCIM,OU=Security
Groups,DC=domain,DC=local
(if the OpenDCIM-SiteAccess group lives in domain.local/Security
Groups/OpenDCIM)
Replace login_ldap.php with the attached.
Now users should be able to login with their UPN (user principle name),
1. Attempts to authenticate the user against AD. If the user
authenticated...
2. Gets the groups the user is a member of.
3. Checks if the groups the user is a member of is a member of the
appropriate OpenDCIM group OR if the user itself is a member of the
appropriate OpenDCIM group.
Tested against 4.3 and 4.3.1 only.
Hopefully this is useful and maybe some of this could find its way in to a
future release. I'd suggest possibly another authentication method called
"AD" so that it decouples AD from LDAP and would make maintaining and
testing code easier.
Regards,
David.
_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

David Ramsden

2016-09-27 10:07:13 UTC

Permalink

Thanks Scott.

I'm willing to take on maintaining Active Directory specific
authentication. I've forked openDCIM and have been working on the code.
Hopefully a pull request should be ready fairly soon.

Instead of hacking away at login_ldap.php and potentially breaking things
for people that use OpenLDAP (for example), I've decoupled LDAP and AD
authentication to make it easier to maintain, test, troubleshoot. There's a
new AUTHENTICATION definition and the AD authentication code is in a
seperate file. Active Directory is of course LDAP based so it shares the
LDAP configuration parameters (such as BaseDN, LDAPServer etc) rather than
having to make a load of (unnecessary) database changes. If AD
authentication is being used, I've hidden certain fields to the user in
ldap_bootstrap.php, install.php and configuration.php that aren't relevent
to Active Directory to make it less confusing to configure.

I'll re-write the LDAP/AD documentation too so the wiki can be updated too.

All of this is assuming my pull request is accepted, of course ;-)

Anyway, watch this space...

On Mon, Sep 26, 2016 at 12:30 PM, Scott Milliken <

Post by Scott Milliken
David,
openDCIM always starts with a lower case 'o'.
Yeah, just kidding. This is great stuff. We could certainly
have two options for the ldap logins - one for openLDAP, and one for Active
Directory, that the site admin simply has to link/rename upon
installation. The only issue is maintaining that second login - if I have
someone that will make sure it stays up to date, we can make it part of the
package. HINT HINT.
Thanks,
Scott

Post by David Ramsden
Hello.
Wanted to feedback a hacked login_ldap.php to the community.
The attached replacement for login_ldap.php may break (read: probably
will! :)) anyone using OpenLDAP (I have no OpenLDAP environment to test
against) but should help those who like us have multiple AD domains where
users of OpenDCIM may be within one of those domains.
Even if you have a single AD domain this will still work for you. This
removes any dependancy on users/groups/whatever being in certain OUs which
can be fairly restrictive for OpenDCIM as well.
The OpenDCIM security groups need to be created within the root domain
(e.g. domain.local) but users can be within any OU within any sub-domain
(e.g. eu.domain.local, am.domain.local).
First create AD universal security groups in the root domain to match the
OpenDCIM-SiteAdmin
OpenDCIM-ContactAdmin
OpenDCIM-SiteAccess
OpenDCIM-WriteAccess
OpenDCIM-ReadAccess
OpenDCIM-DeleteAccess
OpenDCIM-RackRequest
OpenDCIM-RackAdmin
OpenDCIM-BulkOperations
OpenDCIM-AdminOwnDevices
Then populate the groups with either individual users or groups that
users are a member of. e.g. add the Network Ops group to
OpenDCIM-SiteAccess, OpenDCIM-ReadAccess and OpenDCIM-AdminOwnDevices
groups.
Edit the OpenDCIM configuration via the web interface and change the LDAP
parameters.
LDAP Server URI: Needs to point to a Global Catalog server in the root
domain (e.g. dc1.domain.local:3268)
Base DN: Should be the base DN for the root domain (e.g.
dc=domain,dc=local)
Bind DN: Should be set to %userid%
User Search: Should be set to (|(userPrincipalName=%userid%))
Note: Base Search is no longer used and can be ignored.
Site Access: CN=OpenDCIM-SiteAccess,OU=OpenDCIM,OU=Security
Groups,DC=domain,DC=local
(if the OpenDCIM-SiteAccess group lives in domain.local/Security
Groups/OpenDCIM)
Replace login_ldap.php with the attached.
Now users should be able to login with their UPN (user principle name),
1. Attempts to authenticate the user against AD. If the user
authenticated...
2. Gets the groups the user is a member of.
3. Checks if the groups the user is a member of is a member of the
appropriate OpenDCIM group OR if the user itself is a member of the
appropriate OpenDCIM group.
Tested against 4.3 and 4.3.1 only.
Hopefully this is useful and maybe some of this could find its way in to
a future release. I'd suggest possibly another authentication method called
"AD" so that it decouples AD from LDAP and would make maintaining and
testing code easier.
Regards,
David.
_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

Joseph Snukis

2016-09-28 21:20:39 UTC

Permalink

David,

I've been trying to implement your change and am having an odd issue, I
still seem to be getting the popup for the Apache authentication and can't
get to the LDAP login page until I pass it credentials. At that point any
credentials I submit don't work and the initial set are in the access log.
Is there something specific I need to change in the http config to enable
this? A generic template would be appreciated. Thanks in advance.

Post by David Ramsden
Thanks Scott.
I'm willing to take on maintaining Active Directory specific
authentication. I've forked openDCIM and have been working on the code.
Hopefully a pull request should be ready fairly soon.
Instead of hacking away at login_ldap.php and potentially breaking things
for people that use OpenLDAP (for example), I've decoupled LDAP and AD
authentication to make it easier to maintain, test, troubleshoot. There's a
new AUTHENTICATION definition and the AD authentication code is in a
seperate file. Active Directory is of course LDAP based so it shares the
LDAP configuration parameters (such as BaseDN, LDAPServer etc) rather than
having to make a load of (unnecessary) database changes. If AD
authentication is being used, I've hidden certain fields to the user in
ldap_bootstrap.php, install.php and configuration.php that aren't relevent
to Active Directory to make it less confusing to configure.
I'll re-write the LDAP/AD documentation too so the wiki can be updated too.
All of this is assuming my pull request is accepted, of course ;-)
Anyway, watch this space...
On Mon, Sep 26, 2016 at 12:30 PM, Scott Milliken <

Post by David Ramsden
Hello.
Wanted to feedback a hacked login_ldap.php to the community.
The attached replacement for login_ldap.php may break (read: probably
will! :)) anyone using OpenLDAP (I have no OpenLDAP environment to test
against) but should help those who like us have multiple AD domains where
users of OpenDCIM may be within one of those domains.
Even if you have a single AD domain this will still work for you. This
removes any dependancy on users/groups/whatever being in certain OUs which
can be fairly restrictive for OpenDCIM as well.
The OpenDCIM security groups need to be created within the root domain
(e.g. domain.local) but users can be within any OU within any sub-domain
(e.g. eu.domain.local, am.domain.local).
First create AD universal security groups in the root domain to match
OpenDCIM-SiteAdmin
OpenDCIM-ContactAdmin
OpenDCIM-SiteAccess
OpenDCIM-WriteAccess
OpenDCIM-ReadAccess
OpenDCIM-DeleteAccess
OpenDCIM-RackRequest
OpenDCIM-RackAdmin
OpenDCIM-BulkOperations
OpenDCIM-AdminOwnDevices
Then populate the groups with either individual users or groups that
users are a member of. e.g. add the Network Ops group to
OpenDCIM-SiteAccess, OpenDCIM-ReadAccess and OpenDCIM-AdminOwnDevices
groups.
Edit the OpenDCIM configuration via the web interface and change the
LDAP parameters.
LDAP Server URI: Needs to point to a Global Catalog server in the root
domain (e.g. dc1.domain.local:3268)
Base DN: Should be the base DN for the root domain (e.g.
dc=domain,dc=local)
Bind DN: Should be set to %userid%
User Search: Should be set to (|(userPrincipalName=%userid%))
Note: Base Search is no longer used and can be ignored.
Site Access: CN=OpenDCIM-SiteAccess,OU=OpenDCIM,OU=Security
Groups,DC=domain,DC=local
(if the OpenDCIM-SiteAccess group lives in domain.local/Security
Groups/OpenDCIM)
Replace login_ldap.php with the attached.
Now users should be able to login with their UPN (user principle name),
1. Attempts to authenticate the user against AD. If the user
authenticated...
2. Gets the groups the user is a member of.
3. Checks if the groups the user is a member of is a member of the
appropriate OpenDCIM group OR if the user itself is a member of the
appropriate OpenDCIM group.
Tested against 4.3 and 4.3.1 only.
Hopefully this is useful and maybe some of this could find its way in to
a future release. I'd suggest possibly another authentication method called
"AD" so that it decouples AD from LDAP and would make maintaining and
testing code easier.
Regards,
David.
_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

Scott Milliken

2016-09-28 21:48:03 UTC

Permalink

Check your .htaccess file to make sure that you don't have authentication
set up in there, and if not, check your virtual host config file
(locations vary, but usually something like /etc/apache2/conf.d/dcim.conf)
to make sure there's not an authorization directive in there.

Scott

Post by Scott Milliken
David,
I've been trying to implement your change and am having an odd issue, I
still seem to be getting the popup for the Apache authentication and can't
get to the LDAP login page until I pass it credentials. At that point any
credentials I submit don't work and the initial set are in the access log.
Is there something specific I need to change in the http config to enable
this? A generic template would be appreciated. Thanks in advance.

Post by David Ramsden
Hello.
Wanted to feedback a hacked login_ldap.php to the community.
The attached replacement for login_ldap.php may break (read: probably
will! :)) anyone using OpenLDAP (I have no OpenLDAP environment to test
against) but should help those who like us have multiple AD domains where
users of OpenDCIM may be within one of those domains.
Even if you have a single AD domain this will still work for you. This
removes any dependancy on users/groups/whatever being in certain OUs which
can be fairly restrictive for OpenDCIM as well.
The OpenDCIM security groups need to be created within the root domain
(e.g. domain.local) but users can be within any OU within any sub-domain
(e.g. eu.domain.local, am.domain.local).
First create AD universal security groups in the root domain to match
OpenDCIM-SiteAdmin
OpenDCIM-ContactAdmin
OpenDCIM-SiteAccess
OpenDCIM-WriteAccess
OpenDCIM-ReadAccess
OpenDCIM-DeleteAccess
OpenDCIM-RackRequest
OpenDCIM-RackAdmin
OpenDCIM-BulkOperations
OpenDCIM-AdminOwnDevices
Then populate the groups with either individual users or groups that
users are a member of. e.g. add the Network Ops group to
OpenDCIM-SiteAccess, OpenDCIM-ReadAccess and OpenDCIM-AdminOwnDevices
groups.
Edit the OpenDCIM configuration via the web interface and change the
LDAP parameters.
LDAP Server URI: Needs to point to a Global Catalog server in the root
domain (e.g. dc1.domain.local:3268)
Base DN: Should be the base DN for the root domain (e.g.
dc=domain,dc=local)
Bind DN: Should be set to %userid%
User Search: Should be set to (|(userPrincipalName=%userid%))
Note: Base Search is no longer used and can be ignored.
Site Access: CN=OpenDCIM-SiteAccess,OU=OpenDCIM,OU=Security
Groups,DC=domain,DC=local
(if the OpenDCIM-SiteAccess group lives in domain.local/Security
Groups/OpenDCIM)
Replace login_ldap.php with the attached.
Now users should be able to login with their UPN (user principle name),
1. Attempts to authenticate the user against AD. If the user
authenticated...
2. Gets the groups the user is a member of.
3. Checks if the groups the user is a member of is a member of the
appropriate OpenDCIM group OR if the user itself is a member of the
appropriate OpenDCIM group.
Tested against 4.3 and 4.3.1 only.
Hopefully this is useful and maybe some of this could find its way in
to a future release. I'd suggest possibly another authentication method
called "AD" so that it decouples AD from LDAP and would make maintaining
and testing code easier.
Regards,
David.
_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

Joseph Snukis

2016-09-28 22:14:43 UTC

Permalink

Scott,
I'd made a copy and had already commented out the authentication section in
the conf file. Now if it had been the one that http was reading it might
have helped. Thanks for making me look again.

Post by Scott Milliken
Check your .htaccess file to make sure that you don't have authentication
set up in there, and if not, check your virtual host config file
(locations vary, but usually something like /etc/apache2/conf.d/dcim.conf)
to make sure there's not an authorization directive in there.
Scott

Post by David Ramsden
Thanks Scott.
I'm willing to take on maintaining Active Directory specific
authentication. I've forked openDCIM and have been working on the code.
Hopefully a pull request should be ready fairly soon.
Instead of hacking away at login_ldap.php and potentially breaking
things for people that use OpenLDAP (for example), I've decoupled LDAP and
AD authentication to make it easier to maintain, test, troubleshoot.
There's a new AUTHENTICATION definition and the AD authentication code is
in a seperate file. Active Directory is of course LDAP based so it shares
the LDAP configuration parameters (such as BaseDN, LDAPServer etc) rather
than having to make a load of (unnecessary) database changes. If AD
authentication is being used, I've hidden certain fields to the user in
ldap_bootstrap.php, install.php and configuration.php that aren't relevent
to Active Directory to make it less confusing to configure.
I'll re-write the LDAP/AD documentation too so the wiki can be updated too.
All of this is assuming my pull request is accepted, of course ;-)
Anyway, watch this space...
On Mon, Sep 26, 2016 at 12:30 PM, Scott Milliken <

Post by David Ramsden
Hello.
Wanted to feedback a hacked login_ldap.php to the community.
The attached replacement for login_ldap.php may break (read: probably
will! :)) anyone using OpenLDAP (I have no OpenLDAP environment to test
against) but should help those who like us have multiple AD domains where
users of OpenDCIM may be within one of those domains.
Even if you have a single AD domain this will still work for you. This
removes any dependancy on users/groups/whatever being in certain OUs which
can be fairly restrictive for OpenDCIM as well.
The OpenDCIM security groups need to be created within the root domain
(e.g. domain.local) but users can be within any OU within any sub-domain
(e.g. eu.domain.local, am.domain.local).
First create AD universal security groups in the root domain to match
OpenDCIM-SiteAdmin
OpenDCIM-ContactAdmin
OpenDCIM-SiteAccess
OpenDCIM-WriteAccess
OpenDCIM-ReadAccess
OpenDCIM-DeleteAccess
OpenDCIM-RackRequest
OpenDCIM-RackAdmin
OpenDCIM-BulkOperations
OpenDCIM-AdminOwnDevices
Then populate the groups with either individual users or groups that
users are a member of. e.g. add the Network Ops group to
OpenDCIM-SiteAccess, OpenDCIM-ReadAccess and OpenDCIM-AdminOwnDevices
groups.
Edit the OpenDCIM configuration via the web interface and change the
LDAP parameters.
LDAP Server URI: Needs to point to a Global Catalog server in the root
domain (e.g. dc1.domain.local:3268)
Base DN: Should be the base DN for the root domain (e.g.
dc=domain,dc=local)
Bind DN: Should be set to %userid%
User Search: Should be set to (|(userPrincipalName=%userid%))
Note: Base Search is no longer used and can be ignored.
Site Access: CN=OpenDCIM-SiteAccess,OU=OpenDCIM,OU=Security
Groups,DC=domain,DC=local
(if the OpenDCIM-SiteAccess group lives in domain.local/Security
Groups/OpenDCIM)
Replace login_ldap.php with the attached.
Now users should be able to login with their UPN (user principle
AD.
1. Attempts to authenticate the user against AD. If the user
authenticated...
2. Gets the groups the user is a member of.
3. Checks if the groups the user is a member of is a member of the
appropriate OpenDCIM group OR if the user itself is a member of the
appropriate OpenDCIM group.
Tested against 4.3 and 4.3.1 only.
Hopefully this is useful and maybe some of this could find its way in
to a future release. I'd suggest possibly another authentication method
called "AD" so that it decouples AD from LDAP and would make maintaining
and testing code easier.
Regards,
David.
_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

Roy Tischer

2016-09-28 23:19:51 UTC

Permalink

Thats Great David,

I haven't tried it yet, but if you could include that the code takes into
account

1) The Security Groups can be anywhere in the AD structure.
- Our organization has a pretty extensive OU design, it does not cater for
allowing security groups being placed at the root
- e.g. (ou structure) test.gov.au/testcompany security
groups/Application Security/

2) It may already do this but if it could also cater for nested security
groups. e.g.
We have a Security Group for our infrastructure Team called
SG-CSD-Team-Infrastructure Services all our members are in this group and
preferrably this would be placed in the opendcim
group CN=SG-OpenDCIM-SiteAccess,OU=Application Security,OU=Test Security
Groups,DC=test,DC=gov,DC=au

cheers,
Roy.

David Ramsden

2016-10-03 09:03:25 UTC

Permalink

Hi Roy.

The openDCIM (application) security groups can be anywhere but you have to
specify them in DN format. This won't change from how it is today. For
example:

Site Access: CN=SG-OpenDCIM-SiteAccess,OU=Application Security,OU=Test
Security Groups,DC=test,DC=gov,DC=au
Global Read: CN=SG-OpenDCIM-ReadAccess,OU=Application Security,OU=Test
Security Groups,DC=test,DC=gov,DC=au
etc.

As long as the AD user authenticating has read permissions on those
security group objects to read the memberOf attribute.

What you describe should work unless I'm reading it wrong. The following
scenario would work:

User "***@test.gov.au" is a member of "SG-CSD-Team-Infrastructure
Services".
"SG-CSD-Team-Infrastructure Services" is a member of
"SG-OpenDCIM-SiteAccess" (CN=SG-OpenDCIM-SiteAccess,OU=Application
Security,OU=Test Security Groups,DC=test,DC=gov,DC=au).

As would:

User "***@test.gov.au" is a member of "SG-OpenDCIM-SiteAccess"
(CN=SG-OpenDCIM-SiteAccess,OU=Application
Security,OU=Test Security Groups,DC=test,DC=gov,DC=au).

The following scenario would NOT work:

User "***@test.gov.au" is a member of "Test-Group".
"Test-Group" is a member of "SG-CSD-Team-Infrastructure Services".
"SG-CSD-Team-Infrastructure Services" is a member of
"SG-OpenDCIM-SiteAccess" (CN=SG-OpenDCIM-SiteAccess,OU=Application
Security,OU=Test Security Groups,DC=test,DC=gov,DC=au).

Regards,
David.

Post by Roy Tischer
Thats Great David,
I haven't tried it yet, but if you could include that the code takes into
account
1) The Security Groups can be anywhere in the AD structure.
- Our organization has a pretty extensive OU design, it does not cater for
allowing security groups being placed at the root
- e.g. (ou structure) test.gov.au/testcompany security
groups/Application Security/
2) It may already do this but if it could also cater for nested security
groups. e.g.
We have a Security Group for our infrastructure Team called
SG-CSD-Team-Infrastructure Services all our members are in this group and
preferrably this would be placed in the opendcim
group CN=SG-OpenDCIM-SiteAccess,OU=Application Security,OU=Test Security
Groups,DC=test,DC=gov,DC=au
cheers,
Roy.

Post by David Ramsden
Hello.
Wanted to feedback a hacked login_ldap.php to the community.
The attached replacement for login_ldap.php may break (read: probably
will! :)) anyone using OpenLDAP (I have no OpenLDAP environment to test
against) but should help those who like us have multiple AD domains where
users of OpenDCIM may be within one of those domains.
Even if you have a single AD domain this will still work for you. This
removes any dependancy on users/groups/whatever being in certain OUs which
can be fairly restrictive for OpenDCIM as well.
The OpenDCIM security groups need to be created within the root domain
(e.g. domain.local) but users can be within any OU within any sub-domain
(e.g. eu.domain.local, am.domain.local).
First create AD universal security groups in the root domain to match the
OpenDCIM-SiteAdmin
OpenDCIM-ContactAdmin
OpenDCIM-SiteAccess
OpenDCIM-WriteAccess
OpenDCIM-ReadAccess
OpenDCIM-DeleteAccess
OpenDCIM-RackRequest
OpenDCIM-RackAdmin
OpenDCIM-BulkOperations
OpenDCIM-AdminOwnDevices
Then populate the groups with either individual users or groups that
users are a member of. e.g. add the Network Ops group to
OpenDCIM-SiteAccess, OpenDCIM-ReadAccess and OpenDCIM-AdminOwnDevices
groups.
Edit the OpenDCIM configuration via the web interface and change the LDAP
parameters.
LDAP Server URI: Needs to point to a Global Catalog server in the root
domain (e.g. dc1.domain.local:3268)
Base DN: Should be the base DN for the root domain (e.g.
dc=domain,dc=local)
Bind DN: Should be set to %userid%
User Search: Should be set to (|(userPrincipalName=%userid%))
Note: Base Search is no longer used and can be ignored.
Site Access: CN=OpenDCIM-SiteAccess,OU=OpenDCIM,OU=Security
Groups,DC=domain,DC=local
(if the OpenDCIM-SiteAccess group lives in domain.local/Security
Groups/OpenDCIM)
Replace login_ldap.php with the attached.
Now users should be able to login with their UPN (user principle name),
1. Attempts to authenticate the user against AD. If the user
authenticated...
2. Gets the groups the user is a member of.
3. Checks if the groups the user is a member of is a member of the
appropriate OpenDCIM group OR if the user itself is a member of the
appropriate OpenDCIM group.
Tested against 4.3 and 4.3.1 only.
Hopefully this is useful and maybe some of this could find its way in to
a future release. I'd suggest possibly another authentication method called
"AD" so that it decouples AD from LDAP and would make maintaining and
testing code easier.
Regards,
David.
_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion

_______________________________________________
Discussion mailing list
http://list.cadmuslabs.net/listinfo/discussion