dlietz Absent Member.
Absent Member.
1460 views

Integrating eDirectory with Freeradius v3 on SLES12sp1

Hello,

I have an existing radius server running OES11 and freeradius (version 2.x). At the time I installed it, which I believe was in 2013, I used existing documentation on how to edit the ldap module, etc. I want to build a new server running SLES12sp1 and freeradius (v3) without installing OES on the new box, but have the ldap module make calls to an existing eDirectory server.

What I'm finding in version 3 of freeradius on SLES12 though is that the documentation doesn't match up to the configuration of the files in version 3, particularly the ldap module. Below I have the ldap modules from both the working and non-working servers:

Working:
ldap {
[INDENT]server = "10.10.10.10"
port = 636
identity = "cn=freeRadius,o=ORG"
password = "helpme"
basedn = "o=ORG"
filter = "(cn=%{Stripped-User-Name:-%{User-Name}})"
base_filter = "(objectclass=radiusprofile)"
ldap_connections_number = 5
timeout = 4
timelimit = 3
net_timeout = 1
tls {
[INDENT]tls_mode = yes
cacertfile = /home/freeRadius/rootcert.pem
require_cert = "demand"[/INDENT]
}
access_attr = "dialupAccess"
dictionary_mapping = ${confdir}/ldap.attrmap
password_attribute = nspmPassword
edir_account_policy_check = yes[/INDENT]
}

Non-Working:
ldap {
[INDENT]server = "10.10.10.10"
base_filter = "(objectclass=radiusprofile)"
port = 636
identity = "cn=freeRadius,o=ORG"
password = "helpme"
base_dn = "o=ORG"
update {
[INDENT]control:Password-With-Header += 'userPassword'[/INDENT]
}
edir = yes
edir_autz = yes
user {
[INDENT]base_dn = "${..base_dn}"
filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
#filter = "(cn=%{%{Stripped-User-Name:-%{User-Name}})"
scope = 'sub'
access_positive = yes
access_attribute = "dialupAccess"
userAccessAllowed = true
password_attribute = "nspmPassword"[/INDENT]
}
group {
[INDENT]base_dn = "${..base_dn}"
filter = "(objectClass=posixGroup)"
membership_attribute = "memberOf"[/INDENT]
}
profile {
}
client {
[INDENT]base_dn = "${..base_dn}"
filter = '(objectClass=frClient)'
attribute {
[INDENT]identifier = 'radiusClientIdentifier'
secret = 'radiusClientSecret'[/INDENT]
}[/INDENT]
}
accounting {
[INDENT]reference = "%{tolower:type.%{Acct-Status-Type}}"
type {
[INDENT]start {
[INDENT]update {
[INDENT]description := "Online at %S"[/INDENT]
}[/INDENT]
}[/INDENT]
[INDENT]interim-update {
[INDENT]update {
[INDENT]description := "Last seen at %S"[/INDENT]
}[/INDENT]
}[/INDENT]
[INDENT]stop {
[INDENT]update {
[INDENT]description := "Offline at %S"[/INDENT]
}[/INDENT]
}[/INDENT]
}[/INDENT]
}
post-auth {
[INDENT]update {
[INDENT]description := "Authenticated at %S"
}[/INDENT]
}[/INDENT]
options {
[INDENT]#
# The following two configuration items are for Active Directory
# compatibility. If you set these to "no", then searches
# will likely return "operations error", instead of a
# useful result.
#
chase_referrals = yes
rebind = yes
timeout = 10
timelimit = 3
net_timeout = 1
idle = 60
probes = 3
interval = 3
ldap_debug = 0x0028[/INDENT]
}
tls {
[INDENT]tls_mode = yes
ca_file = ${certdir}/rootcert.pem
ca_path = ${certdir}
require_cert = "demand"[/INDENT]
}
pool {
[INDENT]start = 5
min = 4
max = ${thread[pool].max_servers}
spare = 3
uses = 0
lifetime = 0
idle_timeout = 60[/INDENT]
}[/INDENT]
}

There are a few things I'm unclear on.

  1. Placement of the item 'password_attribute = "nspmPassword"'. I've tried it inside the 'users' section and at the root of the ldap section, either way it doesn't seem to be having an affect. Perhaps I need to modify the 'control:Password-With-Header += 'userPassword'' under the ldap section?
  2. Placement of the item 'access_attribute = "dialupAccess"'. Similar to item 1, not sure where it needs to go.
  3. The filter line items are different. 'filter = "(cn=%{Stripped-User-Name:-%{User-Name}})"' compared to filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})". I tried to modify the filter line item so the 'cn=' would work, but it causes an error when loading the config, even when I modified the syntax to match the item in the new ldap file... '%{%' instead of just '%'. The UID item does seem to provide the user name correctly however.
  4. Where does the new ldap module get the attribute map from? I don't see an ldap.attrmap file on the server anywhere, so I'm not sure how it's doing check and reply items.



    Here is a log of the result when I run radtest:
    Running command: radtest <user1> <password1> localhost 10 <clientpassword>

    result:
    Received Access-Request Id 220 from 127.0.0.1:44037 to 127.0.0.1:1812 length 77
    User-Name = 'user1'
    User-Password = 'password1'
    NAS-IP-Address = 10.10.10.10
    NAS-Port = 10
    Message-Authenticator = 0x4d5d3e65e16034ce7ba28a224c7e3691
    (0) # Executing section authorize from file /etc/raddb/sites-enabled/default
    (0) authorize {
    (0) filter_username filter_username {
    (0) if (User-Name != "%{tolower:%{User-Name}}")
    (0) EXPAND %{tolower:%{User-Name}}
    (0) --> user1
    (0) if (User-Name != "%{tolower:%{User-Name}}") -> FALSE
    (0) if (User-Name =~ / /)
    (0) if (User-Name =~ / /) -> FALSE
    (0) if (User-Name =~ /@.*@/ )
    (0) if (User-Name =~ /@.*@/ ) -> FALSE
    (0) if (User-Name =~ /\\.\\./ )
    (0) if (User-Name =~ /\\.\\./ ) -> FALSE
    (0) if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/))
    (0) if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) -> FALSE
    (0) if (User-Name =~ /\\.$/)
    (0) if (User-Name =~ /\\.$/) -> FALSE
    (0) if (User-Name =~ /@\\./)
    (0) if (User-Name =~ /@\\./) -> FALSE
    (0) } # filter_username filter_username = notfound
    (0) [preprocess] = ok
    (0) [chap] = noop
    (0) [mschap] = noop
    (0) [digest] = noop
    (0) suffix : No '@' in User-Name = "user1", looking up realm NULL
    (0) suffix : No such realm "NULL"
    (0) [suffix] = noop
    (0) eap : No EAP-Message, not doing EAP
    (0) [eap] = noop
    (0) files : users: Matched entry DEFAULT at line 198
    (0) [files] = ok
    rlm_ldap (ldap): Reserved connection (4)
    (0) ldap : EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
    (0) ldap : --> (uid=user1)
    (0) ldap : EXPAND o=ORG
    (0) ldap : --> o=ORG
    (0) ldap : Performing search in 'o=ORG' with filter '(uid=user1)', scope 'sub'
    (0) ldap : Waiting for search result...
    (0) ldap : User object found at DN "cn=user1,ou=TECH,o=ORG"
    (0) ldap : Added eDirectory password
    (0) ldap : Processing user attributes
    rlm_ldap (ldap): Released connection (4)
    rlm_ldap (ldap): Closing connection (0), from 1 unused connections
    (0) [ldap] = ok
    (0) [expiration] = noop
    (0) [logintime] = noop
    (0) [pap] = updated
    (0) } # authorize = updated
    (0) Found Auth-Type = PAP
    (0) # Executing group from file /etc/raddb/sites-enabled/default
    (0) Auth-Type PAP {
    (0) pap : Login attempt with password
    (0) pap : User authenticated successfully
    (0) [pap] = ok
    (0) } # Auth-Type PAP = ok
    (0) # Executing section post-auth from file /etc/raddb/sites-enabled/default
    (0) post-auth {
    (0) ldap : EXPAND .
    (0) ldap : --> .
    (0) ldap : EXPAND Authenticated at %S
    (0) ldap : --> Authenticated at 2018-04-24 11:51:57
    rlm_ldap (ldap): Reserved connection (4)
    (0) ldap : Using user DN from request "cn=user1,ou=TECH,o=ORG"
    (0) ldap : Modifying object with DN "cn=user1,ou=TECH,o=ORG"
    (0) ldap : Waiting for modify result...
    (0) ERROR: ldap : Failed modifying object: Insufficient access. Check the identity and password configuration directives
    (0) ERROR: ldap : (null)
    rlm_ldap (ldap): Released connection (4)
    (0) [ldap] = fail
    (0) } # post-auth = fail
    (0) Using Post-Auth-Type Reject
    (0) # Executing group from file /etc/raddb/sites-enabled/default
    (0) Post-Auth-Type REJECT {
    (0) ldap : EXPAND .
    (0) ldap : --> .
    (0) ldap : EXPAND Authenticated at %S
    (0) ldap : --> Authenticated at 2018-04-24 11:51:57
    rlm_ldap (ldap): Reserved connection (4)
    (0) ldap : Using user DN from request "cn=user1,ou=TECH,o=ORG"
    (0) ldap : Modifying object with DN "cn=user1,ou=TECH,o=ORG"
    (0) ldap : Waiting for modify result...
    (0) ERROR: ldap : Failed modifying object: Insufficient access. Check the identity and password configuration directives
    (0) ERROR: ldap : (null)
    rlm_ldap (ldap): Released connection (4)
    (0) [ldap] = fail
    (0) } # Post-Auth-Type REJECT = fail
    (0) Delaying response for 1 seconds
    Waking up in 0.3 seconds.
    Waking up in 0.6 seconds.
    (0) Sending delayed response
    Sending Access-Reject Id 220 from 127.0.0.1:1812 to 127.0.0.1:44037
    Tunnel-Type:0 = VLAN
    Tunnel-Medium-Type:0 = IEEE-802
    Waking up in 3.9 seconds.


    Any assistance is appreciated.
Labels (1)
0 Likes
4 Replies
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Integrating eDirectory with Freeradius v3 on SLES12sp1

On 2018-04-24 21:54, dlietz wrote:
>
> Hello,
>
> I have an existing radius server running OES11 and freeradius (version
> 2.x). At the time I installed it, which I believe was in 2013, I used
> existing documentation on how to edit the ldap module, etc. I want to
> build a new server running SLES12sp1 and freeradius (v3) without
> installing OES on the new box, but have the ldap module make calls to an
> existing eDirectory server.
>
> What I'm finding in version 3 of freeradius on SLES12 though is that the
> documentation doesn't match up to the configuration of the files in
> version 3, particularly the ldap module. Below I have the ldap modules
> from both the working and non-working servers:
>
> *_Working:_*
> ldap {
>
> server = "10.10.10.10"
> port = 636
> identity = "cn=freeRadius,o=ORG"
> password = "helpme"
> basedn = "o=ORG"
> filter = "(cn=%{Stripped-User-Name:-%{User-Name}})"
> base_filter = "(objectclass=radiusprofile)"
> ldap_connections_number = 5
> timeout = 4
> timelimit = 3
> net_timeout = 1
> tls {
>
> tls_mode = yes
> cacertfile = /home/freeRadius/rootcert.pem
> require_cert = "demand"
> }
> access_attr = "dialupAccess"
> dictionary_mapping = ${confdir}/ldap.attrmap
> password_attribute = nspmPassword
> edir_account_policy_check = yes
> }
>
> *_Non-Working:_*
> ldap {
>
> server = "10.10.10.10"
> base_filter = "(objectclass=radiusprofile)"
> port = 636
> identity = "cn=freeRadius,o=ORG"
> password = "helpme"
> base_dn = "o=ORG"
> update {
>
> control:Password-With-Header += 'userPassword'
> }
> edir = yes
> edir_autz = yes
> user {
>
> base_dn = "${..base_dn}"
> filter = "(uid=%{%{Stripped-User-Name}:-%{User-Name}})"
> #filter = "(cn=%{%{Stripped-User-Name:-%{User-Name}})"
> scope = 'sub'
> access_positive = yes
> access_attribute = "dialupAccess"
> userAccessAllowed = true
> password_attribute = "nspmPassword"
> }
> group {
>
> base_dn = "${..base_dn}"
> filter = "(objectClass=posixGroup)"
> membership_attribute = "memberOf"
> }
> profile {
> }
> client {
>
> base_dn = "${..base_dn}"
> filter = '(objectClass=frClient)'
> attribute {
>
> identifier = 'radiusClientIdentifier'
> secret = 'radiusClientSecret'
> }
> }
> accounting {
>
> reference = "%{tolower:type.%{Acct-Status-Type}}"
> type {
>
> start {
>
> update {
>
> description := "Online at %S"
> }
> }
>
> interim-update {
>
> update {
>
> description := "Last seen at %S"
> }
> }
>
> stop {
>
> update {
>
> description := "Offline at %S"
> }
> }
> }
> }
> post-auth {
>
> update {
>
> description := "Authenticated at %S"
> }
> }
> options {
>
> #
> # The following two configuration items are for Active Directory
> # compatibility. If you set these to "no", then searches
> # will likely return "operations error", instead of a
> # useful result.
> #
> chase_referrals = yes
> rebind = yes
> timeout = 10
> timelimit = 3
> net_timeout = 1
> idle = 60
> probes = 3
> interval = 3
> ldap_debug = 0x0028
> }
> tls {
>
> tls_mode = yes
> ca_file = ${certdir}/rootcert.pem
> ca_path = ${certdir}
> require_cert = "demand"
> }
> pool {
>
> start = 5
> min = 4
> max = ${thread[pool].max_servers}
> spare = 3
> uses = 0
> lifetime = 0
> idle_timeout = 60
> }
> }
>
> There are a few things I'm unclear on.
>
> - Placement of the item 'password_attribute = "nspmPassword"'. I've
> tried it inside the 'users' section and at the root of the ldap
> section, either way it doesn't seem to be having an affect. Perhaps I
> need to modify the 'control:Password-With-Header += 'userPassword''
> under the ldap section?
> - Placement of the item 'access_attribute = "dialupAccess"'. Similar
> to item 1, not sure where it needs to go.
> - The filter line items are different. 'filter =
> "(cn=%{Stripped-User-Name:-%{User-Name}})"' compared to filter =
> "(uid=%{%{Stripped-User-Name}:-%{User-Name}})". I tried to modify the
> filter line item so the 'cn=' would work, but it causes an error when
> loading the config, even when I modified the syntax to match the item
> in the new ldap file... '%{%' instead of just '%'. The UID item does
> seem to provide the user name correctly however.
> - Where does the new ldap module get the attribute map from? I don't
> see an ldap.attrmap file on the server anywhere, so I'm not sure how
> it's doing check and reply items.
>
>
>
> Here is a log of the result when I run radtest:
> Running command: radtest <user1> <password1> localhost 10
> <clientpassword>
>
> result:
> Received Access-Request Id 220 from 127.0.0.1:44037 to 127.0.0.1:1812
> length 77
> User-Name = 'user1'
> User-Password = 'password1'
> NAS-IP-Address = 10.10.10.10
> NAS-Port = 10
> Message-Authenticator = 0x4d5d3e65e16034ce7ba28a224c7e3691
> (0) # Executing section authorize from file
> /etc/raddb/sites-enabled/default
> (0) authorize {
> (0) filter_username filter_username {
> (0) if (User-Name != "%{tolower:%{User-Name}}")
> (0) EXPAND %{tolower:%{User-Name}}
> (0) --> user1
> (0) if (User-Name != "%{tolower:%{User-Name}}") -> FALSE
> (0) if (User-Name =~ / /)
> (0) if (User-Name =~ / /) -> FALSE
> (0) if (User-Name =~ /@.*@/ )
> (0) if (User-Name =~ /@.*@/ ) -> FALSE
> (0) if (User-Name =~ /\\.\\./ )
> (0) if (User-Name =~ /\\.\\./ ) -> FALSE
> (0) if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/))
> (0) if ((User-Name =~ /@/) && (User-Name !~ /@(.+)\\.(.+)$/)) ->
> FALSE
> (0) if (User-Name =~ /\\.$/)
> (0) if (User-Name =~ /\\.$/) -> FALSE
> (0) if (User-Name =~ /@\\./)
> (0) if (User-Name =~ /@\\./) -> FALSE
> (0) } # filter_username filter_username = notfound
> (0) [preprocess] = ok
> (0) [chap] = noop
> (0) [mschap] = noop
> (0) [digest] = noop
> (0) suffix : No '@' in User-Name = "user1", looking up realm NULL
> (0) suffix : No such realm "NULL"
> (0) [suffix] = noop
> (0) eap : No EAP-Message, not doing EAP
> (0) [eap] = noop
> (0) files : users: Matched entry DEFAULT at line 198
> (0) [files] = ok
> rlm_ldap (ldap): Reserved connection (4)
> (0) ldap : EXPAND (uid=%{%{Stripped-User-Name}:-%{User-Name}})
> (0) ldap : --> (uid=user1)
> (0) ldap : EXPAND o=ORG
> (0) ldap : --> o=ORG
> (0) ldap : Performing search in 'o=ORG' with filter '(uid=user1)', scope
> 'sub'
> (0) ldap : Waiting for search result...
> (0) ldap : User object found at DN "cn=user1,ou=TECH,o=ORG"
> (0) ldap : Added eDirectory password
> (0) ldap : Processing user attributes
> rlm_ldap (ldap): Released connection (4)
> rlm_ldap (ldap): Closing connection (0), from 1 unused connections
> (0) [ldap] = ok
> (0) [expiration] = noop
> (0) [logintime] = noop
> (0) [pap] = updated
> (0) } # authorize = updated
> (0) Found Auth-Type = PAP
> (0) # Executing group from file /etc/raddb/sites-enabled/default
> (0) Auth-Type PAP {
> (0) pap : Login attempt with password
> (0) pap : User authenticated successfully
> (0) [pap] = ok
> (0) } # Auth-Type PAP = ok
> (0) # Executing section post-auth from file
> /etc/raddb/sites-enabled/default
> (0) post-auth {
> (0) ldap : EXPAND .
> (0) ldap : --> .
> (0) ldap : EXPAND Authenticated at %S
> (0) ldap : --> Authenticated at 2018-04-24 11:51:57
> rlm_ldap (ldap): Reserved connection (4)
> (0) ldap : Using user DN from request "cn=user1,ou=TECH,o=ORG"
> (0) ldap : Modifying object with DN "cn=user1,ou=TECH,o=ORG"
> (0) ldap : Waiting for modify result...
> (0) ERROR: ldap : Failed modifying object: Insufficient access. Check
> the identity and password configuration directives
> (0) ERROR: ldap : (null)
> rlm_ldap (ldap): Released connection (4)
> (0) [ldap] = fail
> (0) } # post-auth = fail
> (0) Using Post-Auth-Type Reject
> (0) # Executing group from file /etc/raddb/sites-enabled/default
> (0) Post-Auth-Type REJECT {
> (0) ldap : EXPAND .
> (0) ldap : --> .
> (0) ldap : EXPAND Authenticated at %S
> (0) ldap : --> Authenticated at 2018-04-24 11:51:57
> rlm_ldap (ldap): Reserved connection (4)
> (0) ldap : Using user DN from request "cn=user1,ou=TECH,o=ORG"
> (0) ldap : Modifying object with DN "cn=user1,ou=TECH,o=ORG"
> (0) ldap : Waiting for modify result...
> (0) ERROR: ldap : Failed modifying object: Insufficient access. Check
> the identity and password configuration directives
> (0) ERROR: ldap : (null)
> rlm_ldap (ldap): Released connection (4)
> (0) [ldap] = fail
> (0) } # Post-Auth-Type REJECT = fail
> (0) Delaying response for 1 seconds
> Waking up in 0.3 seconds.
> Waking up in 0.6 seconds.
> (0) Sending delayed response
> Sending Access-Reject Id 220 from 127.0.0.1:1812 to 127.0.0.1:44037
> Tunnel-Type:0 = VLAN
> Tunnel-Medium-Type:0 = IEEE-802
> Waking up in 3.9 seconds.
>
>
> Any assistance is appreciated.
>
>

I see this in your logs:
(0) ldap : Modifying object with DN "cn=user1,ou=TECH,o=ORG"
(0) ldap : Waiting for modify result...
(0) ERROR: ldap : Failed modifying object: Insufficient access. Check
the identity and password configuration directives
(0) ERROR: ldap : (null)

Does the identity = "cn=freeRadius,o=ORG" user have permissions to
"modify" the cn=user1 user?

This is the update section from my working config file for ldap from
/etc/raddb/mods-enabled/myldap

update {
control:Password-With-Header += 'nspmPassword'
# control:Password-With-Header += 'userPassword'
# control:NT-Password := 'ntPassword'
# reply:Reply-Message := 'radiusReplyMessage'
# reply:Tunnel-Type := 'radiusTunnelType'
# reply:Tunnel-Medium-Type := 'radiusTunnelMediumType'
# reply:Tunnel-Private-Group-ID :=
'radiusTunnelPrivategroupId'

# Where only a list is specified as the RADIUS attribute,
# the value of the LDAP attribute is parsed as a valuepair
# in the same format as the 'valuepair_attribute' (above).
control: += 'radiusControlAttribute'
request: += 'radiusRequestAttribute'
reply: += 'radiusReplyAttribute'
}

I also have:
edir = yes
edir_autz = yes


A key rule with FreeRADIUS is that the out-of-the-box configuration
"works" and that you should make as few changes as possible.
You should try to run FreeRADIUS in debug mode:
radiusd -X
0 Likes
Highlighted
dlietz Absent Member.
Absent Member.

Re: Integrating eDirectory with Freeradius v3 on SLES12sp1

Hi,

Thanks for the reply. I will look at adding the lines in the update section, thanks. Since I have a working system, I was only trying to change the items to match what I have on the first server, but what is difficult is how much is changed in the new config files - makes it harder to duplicate.

As far as the 'freeradius' user goes, it's the same user for the functioning system, so it has the permissions necessary as outlined in the documentation for password reads. I don't recall giving it any 'modify' permissions though and I'm not sure why it would need them. The process I used was to grant the RADIUS Administrator (the 'freeradius' user for me) admin rights to retrieve passwords:

Granting Rights to RADIUS Administrator to Retrieve Password
By default, the administrator does not have the right to read the Universal Password. The eDirectory
administrator needs to modify the password policy to enable the RADIUS Administrator to read The
Universal Password.
Use the following procedureto grant rights to the RADIUS administrator in order to retrieve the
Universal Password:
1 In iManager, click the Roles and Tasks button .
2 Click Passwords > Password Policies and select the password policy being used.
3 Click Universal Password > Configuration Options.
4 Select Allow admin to retrieve passwords from the Universal Password Retrieval section.
5 Click Apply, then click OK.

Again, this works just fine on the existing Radius server so I believe it should work with the new unless something has changed that I'm not aware of.

I ran radiusd -X to get the log that I posted in the OP. Can you tell me how your control items are used? What I have now, and what I'm trying to reproduce is authorize user based on 'dialupacccess' attribute then retrieve 'radiusTunnelPrivategroupId' for the vlan ID to place the user on. How are you using the radiusControlAttribute, radiusRequestAttribute and radiusReplyAttribes? I'll have to experiment on where to add those items to get it to work.

DAn
0 Likes
Knowledge Partner Knowledge Partner
Knowledge Partner

Re: Integrating eDirectory with Freeradius v3 on SLES12sp1

On 2018-04-25 16:24, dlietz wrote:
>
> Hi,
>
> Thanks for the reply. I will look at adding the lines in the update
> section, thanks. Since I have a working system, I was only trying to
> change the items to match what I have on the first server, but what is
> difficult is how much is changed in the new config files - makes it
> harder to duplicate.
>
> As far as the 'freeradius' user goes, it's the same user for the
> functioning system, so it has the permissions necessary as outlined in
> the documentation for password reads. I don't recall giving it any
> 'modify' permissions though and I'm not sure why it would need them. The
> process I used was to grant the RADIUS Administrator (the 'freeradius'
> user for me) admin rights to retrieve passwords:
>
> Granting Rights to RADIUS Administrator to Retrieve Password
> By default, the administrator does not have the right to read the
> Universal Password. The eDirectory
> administrator needs to modify the password policy to enable the RADIUS
> Administrator to read The
> Universal Password.
> Use the following procedureto grant rights to the RADIUS administrator
> in order to retrieve the
> Universal Password:
> 1 In iManager, click the Roles and Tasks button .
> 2 Click Passwords > Password Policies and select the password policy
> being used.
> 3 Click Universal Password > Configuration Options.
> 4 Select Allow admin to retrieve passwords from the Universal Password
> Retrieval section.
> 5 Click Apply, then click OK.
>
> Again, this works just fine on the existing Radius server so I believe
> it should work with the new unless something has changed that I'm not
> aware of.
>
> I ran radiusd -X to get the log that I posted in the OP. Can you tell me
> how your control items are used? What I have now, and what I'm trying to
> reproduce is authorize user based on 'dialupacccess' attribute then
> retrieve 'radiusTunnelPrivategroupId' for the vlan ID to place the user
> on. How are you using the radiusControlAttribute, radiusRequestAttribute
> and radiusReplyAttribes? I'll have to experiment on where to add those
> items to get it to work.
>
> DAn
>
>

Hello

I'm no FreeRADIUS expert 🙂

I see that FreeRADIUS is trying to write to the description attribute of
the user that is authenticating and it's failing:

(0) post-auth {
(0) ldap : EXPAND .
(0) ldap : --> .
(0) ldap : EXPAND Authenticated at %S
(0) ldap : --> Authenticated at 2018-04-24 11:51:57
rlm_ldap (ldap): Reserved connection (4)
(0) ldap : Using user DN from request "cn=user1,ou=TECH,o=ORG"
(0) ldap : Modifying object with DN "cn=user1,ou=TECH,o=ORG"
(0) ldap : Waiting for modify result...
(0) ERROR: ldap : Failed modifying object: Insufficient access. Check
the identity and password configuration directives

Trying commenting out the update directives such as:
update {

description := "Authenticated at %S"
}
}

My setup is much simpler than yours.
I just use FreeRADIUS for WPA2 Enterprise authentication primarily using
certificates and in rare cases using eDirectory username/passwords.
0 Likes
dlietz Absent Member.
Absent Member.

Re: Integrating eDirectory with Freeradius v3 on SLES12sp1

commenting out the 'description := "Authenticated at %S" from the post-auth update section seemed to do the trick. I also uncommented out the "reply:Tunnel-Private-Group-ID :=
'radiusTunnelPrivategroupId'" to get my vlan tag value. I'll do more testing next week.

Thanks for the help!
0 Likes
The opinions expressed above are the personal opinions of the authors, not of Micro Focus. By using this site, you accept the Terms of Use and Rules of Participation. Certain versions of content ("Material") accessible here may contain branding from Hewlett-Packard Company (now HP Inc.) and Hewlett Packard Enterprise Company. As of September 1, 2017, the Material is now offered by Micro Focus, a separately owned and operated company. Any reference to the HP and Hewlett Packard Enterprise/HPE marks is historical in nature, and the HP and Hewlett Packard Enterprise/HPE marks are the property of their respective owners.